On Jul 30, 2013, at 19:05 , Graydon Hoare <gray...@mozilla.com> 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 Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev