4 ms·
It is solved by doing unbounded parser look-ahead (if you need that) or by requiring that all tools have full type information to understand programs (if you ne
by rsc 6y ago
It is solved by doing unbounded parser look-ahead (if you need that) or by requiring that all tools have full type information to understand programs (if you need that).
It is definitely better for tooling not to need either, both for human readers and mechanical tools
The example in the mail shows that using angle brackets with Go would require full type information, making simple tools like gofmt impossible.
- deanCommie 6y ago> making simple tools like gofmt impossible. So now we're making language design decisions based on the limitations of the bonus linter? My opinion of Golang drops more and more with every new detail I learn about it...
- monocasa 6y agoGo has a lot of problems, but continung to support gofmt's quest including the simplicity it desires isn't one of them.
- doctor_eval 6y agoOne of the benefits of Go is super fast compilation time. Unlimited look ahead is likely to make the compiler slower. Ergo, it’s not a great idea.
- estebank 6y agoParser speed is negligible contributor to slowness in any compiler. rustc has a couple of places were it performs bounded lookahead to supply suggestions for incorrect code, but the grammar of the language is regular. 3rd party tools don't have to worry about it, and users get accurate suggestions. The cost is 1) you have to implement a more complex parser while 2) making people go "you already know what I meant, just take it without me using the 'ugly' turbofish". It think this is the correct approach for language design.
- deleted 6y ago[deleted]
- ckok 6y agoNote that C#, Pascal don't "know" about known types during parsing like parsing C/C++ requires, it knows how a type is formatted, what it's looking for is: '<' ValidType (',' ValidType)+ '>' If that's there, it's a generic, else it's an identifier, and somewhere up the parsing chain will take that up as LessThan.