4 ms·
Honest question; why use a comparatively exotic syntax for generics? Most other similar languages — Java, C# — and perhaps most notably C++ since its the closes
by verandaguy 6y ago
Honest question; why use a comparatively exotic syntax for generics? Most other similar languages — Java, C# — and perhaps most notably C++ since its the closest analogue in terms of paradigm and domain, all use angle brackets (without getting into the semantic differences between "classic" generics and the STL).
AFAIK, Golang assigns no special syntactic meaning to angle brackets beyond comparison operators (correct me if I'm wrong though, I don't write much Go), and using a familiar syntax would make it easier to work with coming from other languages.
- ogogmad 6y agoIt complicates parsing and creates ambiguity. It also makes it harder to create tooling. > AFAIK, Golang assigns no special syntactic meaning to angle brackets beyond comparison operators Go has also got bit-shift operators << and >>, which wouldn't interact well with angle-bracket notation.
- Arainach 6y ago>Also, Go has bit-shift operators << and >>, which wouldn't interact well with angle-bracket notation. So do Java and C++. This is a solved problem in parsing. The overall point that angle brackets make parsing more complex stands, but bit-shift arguments are irrelevant.
- pjmlp 6y agoWith the little detail that their lexer makes use of type information, while Go one doesn't.
- imtringued 6y ago"Solved" is the wrong goal. It would be much better if the problem did not exist in the first place.
- remus 6y agoFrom the post: > Angle brackets require unbounded parser look-ahead or type information in certain situations So they want to avoid angle brackets so they can efficiently parse source code.
- verandaguy 6y agoThanks! I'll have to look into this some more but if anyone can volunteer the information, these questions come to mind: - What situations could cause the look-ahead to be unbounded? - How does the Go parser's implementation differ from those of the languages I'd previously listed which all also have angle brackets for comparison (and bit shifts, as another commenter pointed out) while apparently avoiding unbounded look-ahead? - What challenges does the Go parser present when trying to adapt it to follow patterns more like those from the other languages' parsers? - I'm assuming "unbounded" here doesn't mean "it could take unlimited time" but rather "it could incur non-negligible compile-time penalties;" do the benefits of a slightly-quicker compilation (which has nominally no impact on runtime performance) outweigh improved readability?
- ogogmad 6y agoUnlimited lookahead parsers are not necessarily inefficient in terms of time. PEGs for instance run in linear time, but use up linear memory, which is the problem: https://en.wikipedia.org/wiki/Parsing_expression_grammar https://en.wikipedia.org/wiki/Parsing_expression_grammar > - How does the Go parser's implementation differ from those of the languages I'd previously listed which all also have angle brackets for comparison (and bit shifts, as another commenter pointed out) while apparently avoiding unbounded look-ahead? I think parsing Java or C++ requires unlimited lookahead.
- echlebek 6y agohttps://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html https://blog.reverberate.org/2013/08/parsing-c-is-literally-...
- pjmlp 6y agoIt not exotic at all, plenty of languages outside C++ family branch use [] for type parameters. In fact, I think D is the only one using () as well.
- ainar-g 6y agoD uses "()" for type declaration and "!()" for instantiation: template TCopy(T) { void copy(out T to, T from) { to = from; } } /* … */ int i; TCopy!(int).copy(i, 3); The parens can also be omitted in some cases.