For ambiguities with angle brackets consider the assignment
a, b = w < x, y > (z)
Without type information, it is impossible to decide whether the right-hand side of the assignment is a pair of expressions:
(w < x), (y > (z))
or whether it is a generic function invocation that returns two result values:
(w<x, y>)(z)
In Go, type information is not available at compile time. For instance, in this case, any of the identifiers may be declared in another file that has not even been parsed yet.
> also Julia at least is prior art
Julia doesn't use curly braces for blocks and structs.
ᐸ & ᐳ
They thought about generics for 12 years. It's unlikely that someone who thought about it for 3 minutes on Hacker News has some epiphany that wasn't taken into consideration.
Also, I think it is fair to challenge the decisions here seeing as how there have been a few things chosen in Go's history that ignores prior art from other programming languages.
Not a compiler expert, but I got confused when reading this, when is it available?
There is a longer and more precise description of the problem as part of this FAQ of the generics proposal:
https://go.googlesource.com/proposal/+/refs/heads/master/des...
…which includes an example and the statement “It is a key design decision of Go that parsing be possible without type information”.
In Go, you can do this fairly easily with the go/ast package.
Then you take the AST and do something with it. That something can be compiling the code, but also writing some sort of tooling like a linter, or identifier rename tool, or generate documentation from it, or whatnot. When compiling the code you need the type information, for a lot of other purposes you don't really care.
It's pretty valuable to keep the parsing as simple as possible; it makes it easier to detect errors, improves the quality of the error messages, and makes it easier to write tooling. It also keeps the code a lot simpler, easier to understand and modify, etc.
Lexing/tokenization doesn't produce an AST; it produces a token stream. Parsing (which may or may not be preceded by lexing) produces an AST.
Yes: https://go.googlesource.com/proposal/+/refs/heads/master/des...
let (a,b) = w::<x,y>(z);So for C# it's resolved "by examining the token after the closing >: If it is one of (, ), ], :, ;, ,, ., ?, == or !=, the expression is parsed as a generic method call."
I assume this works reasonably well; however, it's not hard to see how this might be a problem in some cases where the parser gets it wrong.