7 ms·

On the <> syntax, why not improve the parser? Every language that uses <> for generics has a parser that is able to distinguish between generics and the "less t

• 8192kjshad09- 6y ago
  Go developers like to claim that the reason the Go compiler is fast is because it's "simple to parse". Unfortunately this doesn't make a lot of sense as parsing is typically only 1-5% of the total compile time.
  • sacado2 6y ago
    It's not only about the main compiler. Go has tons of third-party tools (linters mainly) that can parse go code, because it's so easy to write one. Most of them wouldn't exist if parsing was a PITA.
    • Groxx 6y ago
      Those almost universally use the "ast" package provided by the stdlib.
• monkeyfacebag 6y ago
  In my opinion, the new design doc clearly characterizes this as a design goal of the parser, rather than a hard constraint that cannot be resolved. "Resolving that requires effectively unbounded lookahead. In general we strive to keep the Go parser simple." It's totally fair to question the tradeoff - should having a simple parser outweigh the potential ergonomic benefit of <>? I don't know. The forum for this is probably the golang-nuts group.
  • mpoteat 6y ago
    It's all a matter of where you accept the complexity - in the compiler, in the language, or in the downstream applications. In my view it's an obvious choice to choose a more complicated compiler on exchange for simpler downstream applications...
  • nemetroid 6y ago
    The design doc doesn't say "simple", it says "efficient". I think "simpler" would have been a stronger argument. While using <> would make the parser more complex, I have a hard time seeing that making a meaningful performance difference in a compilation context. Maybe if you're parsing a lot of Go without actually compiling it, but that doesn't seem like a use case to optimize for.
• Sharlin 6y ago
  C++ and Rust require extra disambiguating syntax in some contexts (C++ the `foo.template bar<T>()` syntax, Rust the "superfish operator" `foo.bar::<T>()`. Java works around the problem by awkwardly putting the generic argument list in front of the method name (`foo.<T>bar()`). I don't know about C#.
  • steveklabnik 6y ago
    (teeny tiny note: turbofish, not superfish)
    • Sharlin 6y ago
      Oops :D
  • DougBTX 6y ago
    C# is `foo.bar<T>()`, I’m not sure what compromises that had to make for that to work but from an end-user perspective it works well.
    • oxnrtr 6y ago
      They parse it one way, and if they figure out the other parse option was right, they go back and fix the parse tree. Basically, unlimited look-ahead.
      • lostmsu 6y ago
        Is it somehow a problem?
  • oxnrtr 6y ago
    Using [] is the optimal choice for languages in general, but they can't even use that because they blew away that syntax for indexing.
    • Sharlin 6y ago
• qtplatypus 6y ago
  It is not a question of "Improve" but a question of dealing with tradeoffs. The Go parser is built so that at every stage it is totally unambiguous what the parser has to do. This reduces the amount of state that the parser has to carry around and makes the error messages for syntax errors easier to generate. Languages that use <>'s for generics have to look at a larger amount of the code when parsing to work out what to do.
• apta 6y ago
  The golang approach has been to dumb down the parser, at the expense of making it more complex for users.
  • jatone 6y ago
    there is no complexity tradeoff for users here.
    • apta 6y ago
      Angle brackets are easier to parse for humans.
• teleforce 6y ago
  The main reason is probably that by omitting <> for generics makes the symbol table unnecessary as part of the compilation stage. Go and D are the two modern languages that are avoiding symbol table like a plague for faster compilation time, i.e. the code should be parseabled without having to look things up in a symbol table .