4 ms·

<> are the worst characters for generics, except for all the others that have been tried. () leads to the type syntax being difficult to distinguish from value

<> are the worst characters for generics, except for all the others that have been tried. () leads to the type syntax being difficult to distinguish from value syntax, which is great in dependently-typed languages but bad elsewhere. [] is already used for slices, albeit in a different way; and C should be objection enough if you want to make types look like values. {} is a nonstarter because it leads to ambiguity between return type and function body, and in an everything-is-an-expression language, once again we are back at types-look-like-values. There are no more matched pairs left on an ANSI keyboard. Personally, while I hear you that :: is ugly, I do really like being able to distinguish module paths from value paths at a glance. And when looking for an alternative, we once again run into other characters already having far more familiar conflicting uses, or just being too weird. (E.g., # or @ could have been used, but that's probably worse than ::.)

zozbot234 4y ago
To be fair, arrays and slices are probably uncommon enough in current code that they shouldn't get exclusive use of the [] brackets. They could just be a generic type like any other.
- cutemonster 4y ago
  Scala uses [ ] for generics, works well. I think you're right that array access is a rare case, definitely doesn't deserve its own reserved characters. And [ ] tends to mean "crash if out of bounds", crazy to have gotten its own reserved characters :-)
nneonneo 4y ago
And that's why we have Unicode! Vec⟪u8⟫ Vec｢u8｣ Vec⟦u8⟧ Vec༼u8༽ I'm sure this could open up a whole new frontier of exciting, untypeable language designs. If it works for APL, it should work for any language!
- lifthrasiir 4y ago
  Or that's why we have digraphs. `Vec[\u8\]` or `Vec[.u8.]` may have worked (these examples are from Fortress [1] and Nim [2]). [1] https://homes.luddy.indiana.edu/samth/fortress-spec.pdf#page=104 https://homes.luddy.indiana.edu/samth/fortress-spec.pdf#page... [2] https://nim-lang.org/docs/manual.html#lexical-analysis-other-tokens https://nim-lang.org/docs/manual.html#lexical-analysis-other...
Ferret7446 4y ago
Nah, <> are much worse, because they are syntactically binary operators.
estebank 4y ago
[] are already taken by the slicing syntax, but if that wasn't the case you could have something like vec@2 and vec@{end - start} for that, which would open them up for generics. I'm pretty sure the main reason to choose <> was familiarity above all else.
edflsafoiewq 4y ago
<> are obviously already used for less than/greater than, so they're disqualified too by this logic. If you broaden your viewpoint, [] is the same thing for arrays and generics. A generic function is a family of functions parameterized by types; an array is a family of values parameterized by 0..n; [] selects one member of the family. In fact in math subscripting is already a common notation for the parameter of a generic. Same for paths using dot, it's just member access on a module object. In languages like JS or Python it's literally just normal runtime member access. In Zig it's also just normal member access on a comptime object.

zozbot234 4y ago

To be fair, arrays and slices are probably uncommon enough in current code that they shouldn't get exclusive use of the [] brackets. They could just be a generic type like any other.

cutemonster 4y ago
Scala uses [ ] for generics, works well. I think you're right that array access is a rare case, definitely doesn't deserve its own reserved characters. And [ ] tends to mean "crash if out of bounds", crazy to have gotten its own reserved characters :-)

nneonneo 4y ago

And that's why we have Unicode! Vec⟪u8⟫ Vec｢u8｣ Vec⟦u8⟧ Vec༼u8༽ I'm sure this could open up a whole new frontier of exciting, untypeable language designs. If it works for APL, it should work for any language!

lifthrasiir 4y ago
Or that's why we have digraphs. `Vec[\u8\]` or `Vec[.u8.]` may have worked (these examples are from Fortress [1] and Nim [2]). [1] https://homes.luddy.indiana.edu/samth/fortress-spec.pdf#page=104 https://homes.luddy.indiana.edu/samth/fortress-spec.pdf#page... [2] https://nim-lang.org/docs/manual.html#lexical-analysis-other-tokens https://nim-lang.org/docs/manual.html#lexical-analysis-other...

Ferret7446 4y ago

Nah, <> are much worse, because they are syntactically binary operators.

estebank 4y ago

[] are already taken by the slicing syntax, but if that wasn't the case you could have something like vec@2 and vec@{end - start} for that, which would open them up for generics. I'm pretty sure the main reason to choose <> was familiarity above all else.

edflsafoiewq 4y ago

<> are obviously already used for less than/greater than, so they're disqualified too by this logic. If you broaden your viewpoint, [] is the same thing for arrays and generics. A generic function is a family of functions parameterized by types; an array is a family of values parameterized by 0..n; [] selects one member of the family. In fact in math subscripting is already a common notation for the parameter of a generic. Same for paths using dot, it's just member access on a module object. In languages like JS or Python it's literally just normal runtime member access. In Zig it's also just normal member access on a comptime object.