3 ms·

Ian's talk about generics at gophercon 2019: https://www.youtube.com/watch?v=WzgLqE-3IhY https://www.youtube.com/watch?v=WzgLqE-3IhY The proposal seems so simp

Ian's talk about generics at gophercon 2019: https://www.youtube.com/watch?v=WzgLqE-3IhY https://www.youtube.com/watch?v=WzgLqE-3IhY The proposal seems so simple, I want to use it already! It would be a nice idea to have a translator from generic go to stable go, so that users of go can start using these generics. Edit: an implementation was linked in the talk as a changelist to try it out: https://go-review.googlesource.com/c/go/+/187317/ https://go-review.googlesource.com/c/go/+/187317/

kristianp 7y ago
Anyone know why they didn't go with angle brackets? People familiar with C++ and Java would find it familiar. I wonder if its too unpythonic, or makes the parsing too hard. e.g. Instead of func Reverse (type Element) (s []Element) { why not do: func Reverse<Element> (s []Element) {
- pjmlp 7y ago
  Ian mentions it would make the parser contex aware, which isn't needed currently.
  - mseepgood 7y ago
    Also related: https://github.com/golang/go/issues/36177#issuecomment-567679298 https://github.com/golang/go/issues/36177#issuecomment-56767...
  - norswap 7y ago
    That at least isn't true in terms of the Chomsky grammar hierarchy. You can have both angle brackets operators and delimiters in a CFG (context-free grammar). It might be a limitation of their parsing tech (e.g. LL(1) would have that issue, probably LR too). No problem for general CFG parsers though (if you can write a BNF grammar for it, that's the CFG grammar for it).
    - pjmlp 7y ago
      Most likely, just repeating his answer on the podcast.
- mhh__ 7y ago
  Parenthesis are not binary operators so the parser doesn't need to know whether LHS and RHS are identifiers or expressions. This is the same reason why D uses a bang (!) for template instantiation (as well as this exact syntax for declaration) - I think D is the benchmark for generics in 2020, especially alias arguments, of the C++ like languages anyway (so no Haskell!) I also think the contract system this design and C++ have gone for is overly complicated compared to the highly extensible and extremely simple system D uses (just write if(ContractCondition!Type) between the template declaration and it's body
- sacado2 7y ago
  l := list<int>(lst) vs l := x < y When it reads the "<" sign, the parser doesn't know whether it is in the first situation (an instantiation of a generic type) or the second one (a comparison). It makes parsing harder. It's even worse when the actual type is also a generic one, as in list<list<int>>. That's the reason why you had to write `list<list<int> >` (note the space) rather than `list<list<int>>` in C++ until C++11.
- tapirl 7y ago
  > ... using angle brackets, but we couldn’t figure out how to make that work in Go… Because Go has the ability that you can parse the syntax without knowing the types of the names ... This is not the first time I heard that keeping the parser simple is more important than others in Go design from Go core team. This might be good sometimes, but I think this will hurt user experience more often.
  - Gibbon1 7y ago
    You could argue that the trade offs are worth it. Compilers can be faster, auto format works, autocomplete, code snippets, merging etc.

kristianp 7y ago

Anyone know why they didn't go with angle brackets? People familiar with C++ and Java would find it familiar. I wonder if its too unpythonic, or makes the parsing too hard. e.g. Instead of func Reverse (type Element) (s []Element) { why not do: func Reverse<Element> (s []Element) {

pjmlp 7y ago
Ian mentions it would make the parser contex aware, which isn't needed currently.
- mseepgood 7y ago
  Also related: https://github.com/golang/go/issues/36177#issuecomment-567679298 https://github.com/golang/go/issues/36177#issuecomment-56767...
- norswap 7y ago
  That at least isn't true in terms of the Chomsky grammar hierarchy. You can have both angle brackets operators and delimiters in a CFG (context-free grammar). It might be a limitation of their parsing tech (e.g. LL(1) would have that issue, probably LR too). No problem for general CFG parsers though (if you can write a BNF grammar for it, that's the CFG grammar for it).
  - pjmlp 7y ago
    Most likely, just repeating his answer on the podcast.
mhh__ 7y ago
Parenthesis are not binary operators so the parser doesn't need to know whether LHS and RHS are identifiers or expressions. This is the same reason why D uses a bang (!) for template instantiation (as well as this exact syntax for declaration) - I think D is the benchmark for generics in 2020, especially alias arguments, of the C++ like languages anyway (so no Haskell!) I also think the contract system this design and C++ have gone for is overly complicated compared to the highly extensible and extremely simple system D uses (just write if(ContractCondition!Type) between the template declaration and it's body
sacado2 7y ago
l := list<int>(lst) vs l := x < y When it reads the "<" sign, the parser doesn't know whether it is in the first situation (an instantiation of a generic type) or the second one (a comparison). It makes parsing harder. It's even worse when the actual type is also a generic one, as in list<list<int>>. That's the reason why you had to write `list<list<int> >` (note the space) rather than `list<list<int>>` in C++ until C++11.
tapirl 7y ago
> ... using angle brackets, but we couldn’t figure out how to make that work in Go… Because Go has the ability that you can parse the syntax without knowing the types of the names ... This is not the first time I heard that keeping the parser simple is more important than others in Go design from Go core team. This might be good sometimes, but I think this will hurt user experience more often.
- Gibbon1 7y ago
  You could argue that the trade offs are worth it. Compilers can be faster, auto format works, autocomplete, code snippets, merging etc.