4 ms·

First the acknowledgement: to produce this amount of work single handedly - the guy is undisputed genius. do not want to go through the whole article but have

• gpderetta 4y ago
  I think the author is simply showing that Circle can implement Carbon syntax using its metaprogramming capabilities on top of C++. It is not making a statement that the syntax itself is desirable.
  • seanbax 4y ago
    That's right. I'm fine with normal C++ syntax. But other people have other opinions. And there is an allure of getting to a CFG so that non-compiler tooling could build a parse tree and do useful transformations. That's a good a goal. I'm basically looking to evolve on multiple fronts at once. If there's an interest in new syntax, put resources. If there's interest in a borrow checker (I'm sure there is), put resources there. Just move up the field however you can.
• tdiff 4y ago
  Guess it simplifies parsing, e.g. infamous "most vexing parse" etc.
  • FpUser 4y ago
    Convenience should be for users of a tool not creator. And if it is fn than why not function instead. This single / double character constructs / modifiers in my opinion reduce readability. When reading Rust code apostrophe modifier for example is hard to see.
    • int_19h 4y ago
      Tools are themselves "users" of syntax, and if you design a language without regard for their convenience at all, you end up in situations where e.g. code completion doesn't work because the syntax forces a forward reference (think of stuff like SELECT .. FROM ..), performance issues etc. And to the end users, the convenience should be considered as an aggregate metric: it's not just about writing code, but also about reading code, compiling code, debugging code etc. You have to optimize for UX across the board, which sometimes necessitates compromises in some of those areas. And the declaration syntax for C++ is so bad that, in the most general case, you can't even reliably tell if it's a declaration or not without knowing the compiler that'll process it! Consider: template<size_t N = sizeof(void*)> struct a { template<int> struct b {}; }; template<> struct a<sizeof(int)> { enum { b }; }; enum { c, d }; struct test : a<> { friend int main() { b<c>d; // declaration or expression? &d; // error or ok? } }; The first commented line above parses either as: b<c> d; // local variable or as: ((b < c) > d); // expression depending on whether sizeof(int)==sizeof(void*) on that particular implementation. Consequently, the following &d is either legal or not, depending on whether it's trying to take the address of a local or of an enum constant. That alone is, to me, sufficient reason to believe that changing it to Pascal-style "name: type" declarations, which are unambiguous, benefits both tools and humans, even if it's slightly more verbose.
      • FpUser 4y ago
        >"That alone is, to me, sufficient reason to believe that changing it to Pascal-style "name: type" declarations, which are unambiguous, benefits both tools and humans, even if it's slightly more verbose." I am not against it. It is a different language altogether though. We were talking about "fixing" C++ while it is still being C++.
        • int_19h 4y ago
          As it happens, C++ has already adopted "auto f() -> T" function declaration syntax many years ago in addition to "T f()", so this is arguably just a more streamlined take on that. I don't see how it makes it less C++, since conceptually everything is the same.
• deleted 4y ago
  [deleted]