6 ms·

While I would prefer brackets, that would not be enought to solve all the problems since, there would be conflict with array syntax too.

by Uther 6y ago

twic 6y ago
But the square brackets used in array access nest, so the parsing is never ambiguous. The reason > needs braces is that without them, if you're parsing and so far you've seen these characters: let y: RectangularArray<i32, X, 2> You don't know if that final > is ending the argument list, or is a greater-than operator, with the rest of an expression coming after it. But if it was square brackets, then a closing square bracket on its own can only ever be the end of the list: let y: RectangularArray[i32, X, 2] Because if it was closing an array access, there would have to have been an opening square bracket: let y: RectangularArray[i32, X, a[1]
- twic 6y ago
  In case anyone ever stumbles across this thread, a couple of posts about this: https://keleshev.com/parsing-ambiguity-type-argument-v-less-than https://keleshev.com/parsing-ambiguity-type-argument-v-less-... https://soc.me/languages/stop-using-for-generics https://soc.me/languages/stop-using-for-generics
masklinn 6y ago
That's what I originally thought about, but the thing is `]` in and of itself is not an operator while `>` is, so foo<bar, qux>corge> "is" valid syntax while foo[bar, qux]corge] is not. The former requires some sort of disambiguation, while the latter is not. Put an other way, in terms of syntax `[]` always parses the same way (with `[` is infix and `]` terminates it), there can be ambiguity between indexing and generics but it doesn't really matter for the original parsing. For `<>` however, the parsing itself can be ambiguous as `>` could either be the terminator of an earlier `<` or it could be the infix `>` operator. That is where the issue lies, you can't know how to build the AST without either explicit disambiguation, or infinite lookaheads.

While I would prefer brackets, that would not be enought to solve all the problems since, there would be conflict with array syntax too.

by Uther 6y ago

While I would prefer brackets, that would not be enought to solve all the problems since, there would be conflict with array syntax too.

twic 6y ago

But the square brackets used in array access nest, so the parsing is never ambiguous. The reason > needs braces is that without them, if you're parsing and so far you've seen these characters: let y: RectangularArray<i32, X, 2> You don't know if that final > is ending the argument list, or is a greater-than operator, with the rest of an expression coming after it. But if it was square brackets, then a closing square bracket on its own can only ever be the end of the list: let y: RectangularArray[i32, X, 2] Because if it was closing an array access, there would have to have been an opening square bracket: let y: RectangularArray[i32, X, a[1]

twic 6y ago
In case anyone ever stumbles across this thread, a couple of posts about this: https://keleshev.com/parsing-ambiguity-type-argument-v-less-than https://keleshev.com/parsing-ambiguity-type-argument-v-less-... https://soc.me/languages/stop-using-for-generics https://soc.me/languages/stop-using-for-generics

masklinn 6y ago

That's what I originally thought about, but the thing is `]` in and of itself is not an operator while `>` is, so foo<bar, qux>corge> "is" valid syntax while foo[bar, qux]corge] is not. The former requires some sort of disambiguation, while the latter is not. Put an other way, in terms of syntax `[]` always parses the same way (with `[` is infix and `]` terminates it), there can be ambiguity between indexing and generics but it doesn't really matter for the original parsing. For `<>` however, the parsing itself can be ambiguous as `>` could either be the terminator of an earlier `<` or it could be the infix `>` operator. That is where the issue lies, you can't know how to build the AST without either explicit disambiguation, or infinite lookaheads.