On Jul 30, 2013, at 19:05 , Graydon Hoare <[email protected]> wrote:
> It reminds me somewhat of the asymmetry between (T,U,V) tuple expressions and
> their type (T*U*V) in the MLs. An asymmetry I feel ... is a bit of a wart?
> We've tried to keep the expression, pattern and type grammars looking as
> similar as possible.
Ah, actually, this asymmetry, as you call it, is also standard, and quite
relevant. It's rather Haskell's pun on using the same syntax for tuples and
their classifier that is an outlier (and arguably a wart). The problem with it
is that it is essentially a category error: (T,U) is the natural notation for a
tuple of types, not for the type of a tuple of values. This becomes an issue if
you consider richer languages: having constructs like lambdas or tuples on the
type level itself (or even higher universes) is common in higher-order type
systems. And then you need to be able to express both (T,U) and T*U, which are
completely different beasts. (ML specifically does use type tuples for n-ary
type constructors: "(int, string) map" has quite a different meaning from "(int
* string) list" .)
So overloading the syntax of introduction forms with their classifiers is one
of these things that looks neat at first but turns out not to scale well (and
to lead to confusion).
> Trickier call. We don't allow type ascription inside patterns, only at the
> outermost level. I think we found that our grammars were sufficiently similar
> that intermixing them inside one another produced ambiguities, though I don't
> remember off hand which one. Possibly the ambiguity between
> "{<field_name>:<pat>}" and "{<field_name>:<ty>}".
Of course, the former one is conventionally written "{<field_name> = <pat>}"
for this reason, and the ones mentioned above. :)
/Andreas
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
