5 ms·

Does anyone know the impetus for using [] in generics? I know Nim opted for the same syntax and I assume it has some parsing/tokenizing benefit like the switch

Does anyone know the impetus for using [] in generics? I know Nim opted for the same syntax and I assume it has some parsing/tokenizing benefit like the switch to using “fn” a la Zig or Rust. However, the syntax seems needlessly ambiguous with array notation sharing the same operator. I know I’m not alone because I’ve seen others mirror my concerns on Nim forums [0]. [0] https://github.com/nim-lang/Nim/issues/3502 https://github.com/nim-lang/Nim/issues/3502

mseepgood 5y ago
> Does anyone know the impetus for using [] in generics? Yes: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#why-not-use-the-syntax-like-c_and-java https://go.googlesource.com/proposal/+/refs/heads/master/des...
- blondin 5y ago
  is it really the case that parsers can't tell the greater than sign in "a, b = w < x, y > (z)" without type information? or is it simply difficult to parse for some parsers?
  - nemothekid 5y ago
    The doc says it's actually impossible, and I'm inclined to believe so. Rust has a similar problem in their case they adopted the "turbo fish" operator, where the generic function call would take the following form: let (a,b) = w::<x,y>(z);
  - mseepgood 5y ago
    Can you as a human? If you can't do it a parser can't do it either.
  - arp242 5y ago
    It's a problem all languages with <..> need to solve one way or the other; see e.g. https://blog.dyvil.org/syntax/2016/04/19/angle-bracket-generics.html https://blog.dyvil.org/syntax/2016/04/19/angle-bracket-gener... 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.
    - blondin 5y ago
      thanks for explaining :)
ebruchez 5y ago
I don't know the answer to that but Scala is also a precedent for using square brackets for generics (AKA type parameters). However in Scala arrays don't use square brackets so that confusion is avoided.
- mseepgood 5y ago
  And Python and CLU, Barbara Liskov's OG generics language.
arp242 5y ago
The original implementation used ( .. ), which I found an unreadable mess of parentheses soup, but luckily that was changed. The problem with < .. > is that it's ambiguous with the greater-than and lesser-than operators. From [1] (among many other discussions on this): 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. [1]: https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8 https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8
- deleted 5y ago
  [deleted]
- adgjlsfhk1 5y ago
  Why not {} That should be pretty easily parsable, and seems less ambiguous than [] (also Julia at least is prior art)
  - mseepgood 5y ago
    You can't get more ambiguous to parse than {} in the context of Go. > also Julia at least is prior art Julia doesn't use curly braces for blocks and structs.
    - ethbr0 5y ago
      Why not use characters from the Canadian Aboriginal Syllabics block? ᐸ & ᐳ
      - mseepgood 5y ago
        Are we going to ask this for every Unicode character pair? They have answered all these questions in the design document: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#why-not-use https://go.googlesource.com/proposal/+/refs/heads/master/des... 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.
saurik 5y ago
Maybe it would feel better if you thought of List as the set of all types that are List, and List[Thing] as extracting a single item from that set?
steveklabnik 5y ago
Rust used [] for generics a very, very long time ago. A lot of people wish we still did. I personally am glad we do not, but that's only in the context of Rust. I think the choice the Go folks made is very reasonable.
Splizard 5y ago
It makes sense, you are indexing the function with concrete types to select your implementation. This is consistent with slices and maps.
edflsafoiewq 5y ago
Eiffel is the first language I know of to use [] for generics. It's consistent with the interpretation of [] as "subscripting"; the generic is a family parameterized by types, and the subscript selects one element of the family.
- thewakalix 5y ago
  What’s even more consistent is using juxtaposition to represent all parameterization, on the value and type levels. Haskell does this!
  - edflsafoiewq 5y ago
    That errs to the side of too much consistency for me. I'd like a nice balance; a small amount of syntax... but not too small. After all, morally x.a, x[a], and x(a) are all the same thing.

mseepgood 5y ago

> Does anyone know the impetus for using [] in generics? Yes: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#why-not-use-the-syntax-like-c_and-java https://go.googlesource.com/proposal/+/refs/heads/master/des...

blondin 5y ago
is it really the case that parsers can't tell the greater than sign in "a, b = w < x, y > (z)" without type information? or is it simply difficult to parse for some parsers?
- nemothekid 5y ago
  The doc says it's actually impossible, and I'm inclined to believe so. Rust has a similar problem in their case they adopted the "turbo fish" operator, where the generic function call would take the following form: let (a,b) = w::<x,y>(z);
- mseepgood 5y ago
  Can you as a human? If you can't do it a parser can't do it either.
- arp242 5y ago
  It's a problem all languages with <..> need to solve one way or the other; see e.g. https://blog.dyvil.org/syntax/2016/04/19/angle-bracket-generics.html https://blog.dyvil.org/syntax/2016/04/19/angle-bracket-gener... 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.
  - blondin 5y ago
    thanks for explaining :)

ebruchez 5y ago

I don't know the answer to that but Scala is also a precedent for using square brackets for generics (AKA type parameters). However in Scala arrays don't use square brackets so that confusion is avoided.

mseepgood 5y ago
And Python and CLU, Barbara Liskov's OG generics language.

arp242 5y ago

The original implementation used ( .. ), which I found an unreadable mess of parentheses soup, but luckily that was changed. The problem with < .. > is that it's ambiguous with the greater-than and lesser-than operators. From [1] (among many other discussions on this): 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. [1]: https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8 https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8

deleted 5y ago
[deleted]
adgjlsfhk1 5y ago
Why not {} That should be pretty easily parsable, and seems less ambiguous than [] (also Julia at least is prior art)
- mseepgood 5y ago
  You can't get more ambiguous to parse than {} in the context of Go. > also Julia at least is prior art Julia doesn't use curly braces for blocks and structs.
  - ethbr0 5y ago
    Why not use characters from the Canadian Aboriginal Syllabics block? ᐸ & ᐳ
    - mseepgood 5y ago
      Are we going to ask this for every Unicode character pair? They have answered all these questions in the design document: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#why-not-use https://go.googlesource.com/proposal/+/refs/heads/master/des... 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.

saurik 5y ago

Maybe it would feel better if you thought of List as the set of all types that are List, and List[Thing] as extracting a single item from that set?

steveklabnik 5y ago

Rust used [] for generics a very, very long time ago. A lot of people wish we still did. I personally am glad we do not, but that's only in the context of Rust. I think the choice the Go folks made is very reasonable.

Splizard 5y ago

It makes sense, you are indexing the function with concrete types to select your implementation. This is consistent with slices and maps.

edflsafoiewq 5y ago

Eiffel is the first language I know of to use [] for generics. It's consistent with the interpretation of [] as "subscripting"; the generic is a family parameterized by types, and the subscript selects one element of the family.

thewakalix 5y ago
What’s even more consistent is using juxtaposition to represent all parameterization, on the value and type levels. Haskell does this!
- edflsafoiewq 5y ago
  That errs to the side of too much consistency for me. I'd like a nice balance; a small amount of syntax... but not too small. After all, morally x.a, x[a], and x(a) are all the same thing.