The actual reason why let … in syntax tends to not use C-style “type var” like syntax is because it’s derived from the syntax type theory uses, and type theorists know about parameterised types. Generics, in C++ parlance, excuse my Haskell:
let foo :: MapIntString = mempty
We have an empty map, and it maps integers to Strings. We call it foo. Compare:
MapIntString foo = mempty
If nothing else, that’s just awkward to read and while it may be grammatically unambiguous (a token is a name if it sits directly in front of =) parser error messages are going to suck. Map<Int,String> is also awkward but alas that’s what we’re stuck with in Rust because they reasoned that it would be cruel to put folks coming from C++ on angle bracket withdrawal. Also Rust has ML ancestry don’t get me started on their type syntax.
How do you do nested parameterized types without it becoming ambiguous though? That’s IMO the biggest advantage of the bracket syntax. For example: Map<Tuple<Int, Int, Int> Int>
Map (Int, Int) Int. Kind of a bad example because tuples have special-case infix syntax, the general case would be Map Int (Either Int Bool). Follows the same exact syntax as function application just that types (by enforced convention) start upper case. Modulo technical wibbles to ensure that type inference is possible you can consider type constructors to be functions from types to types.
…function application syntax is a story in itself in Haskell because foo ab c gets desugared to (((foo a) b) c): There’s only one-argument functions. If you want to have more arguments, accept an argument and return a function that accepts yet another argument. Then hide all that under syntactic sugar so that it looks innocent. And, of course, optimise it away when compiling. Thus you can write stuff like map (+5) xs in Haskell while other languages need the equivalent of map (\x -> x + 5) xs (imagine the \ is a lambda symbol).
The actual reason why let … in syntax tends to not use C-style “type var” like syntax is because it’s derived from the syntax type theory uses, and type theorists know about parameterised types. Generics, in C++ parlance, excuse my Haskell:
let foo :: Map Int String = memptyWe have an empty map, and it maps integers to Strings. We call it foo. Compare:
Map Int String foo = memptyIf nothing else, that’s just awkward to read and while it may be grammatically unambiguous (a token is a name if it sits directly in front of
=) parser error messages are going to suck.Map<Int,String>is also awkward but alas that’s what we’re stuck with in Rust because they reasoned that it would be cruel to put folks coming from C++ on angle bracket withdrawal. Also Rust has ML ancestry don’t get me started on their type syntax.How do you do nested parameterized types without it becoming ambiguous though? That’s IMO the biggest advantage of the bracket syntax. For example:
Map<Tuple<Int, Int, Int> Int>Map (Int, Int) Int. Kind of a bad example because tuples have special-case infix syntax, the general case would beMap Int (Either Int Bool). Follows the same exact syntax as function application just that types (by enforced convention) start upper case. Modulo technical wibbles to ensure that type inference is possible you can consider type constructors to be functions from types to types.…function application syntax is a story in itself in Haskell because
foo a b cgets desugared to(((foo a) b) c): There’s only one-argument functions. If you want to have more arguments, accept an argument and return a function that accepts yet another argument. Then hide all that under syntactic sugar so that it looks innocent. And, of course, optimise it away when compiling. Thus you can write stuff likemap (+5) xsin Haskell while other languages need the equivalent ofmap (\x -> x + 5) xs(imagine the\is a lambda symbol).Interesting. Thanks!
There is also the thing where the compiler might mistake your c++ style variable declaration for a function, e.g.
Until now, I looked at
letand thought, “maybe they just felt like doing it that way”.Makes a lot more sense now.