[rust-dev] A plea for removing context-free ambiguity / context-required parsing

Nathan nejucomo at gmail.com
Fri Aug 17 12:56:42 PDT 2012

On Fri, Aug 17, 2012 at 12:15 PM, Graydon Hoare <graydon at mozilla.com> wrote:

[Snipped everything except what I respond to...]

> So, with all this in mind, we went with the SML rule: having the compiler
> restrict names introduced-by-a-pattern to not-collide with any in-scope
> nullary ctors and constants. It _seems_ to be working pretty well in
> practice.

Thanks for describing the design trade-offs very well.  I'll try to be
less vocal, especially if what we have works in practice.

One other thought, however:  The case where ctors and variable
references may both appear in expressions is unambiguous, because in
each case the identifier represents a value.  Here I'm thinking a ctor
named "foo" is indistinguishable from a reference named "foo" that
happens to refer to an enum value.

I started to wonder if there could be a symmetric consistency in
pattern matching.  Something with the semantics: "If the
value-to-be-matched is equal/identical to the value referred to by
identifier "foo", then the match proceeds successfully."  In that
case, whatever syntax has those semantics could be used both with
ctors and with variables.

I'll try yet another mangling of the grammar: let's suppose
EQUALITY_PATTERN ::= '=' IDENTIFIER in patterns, so:

match myfoo {
  =bar => /* match on equality */
  quz => /* bind "quz" to anything */

Yes, that syntax is horrible.  The point is: it doesn't matter if
"bar" refers to a nullary enum ctor *or* a reference, the semantics
are the same.

I suppose explicitly marking binding patterns and un-marked
identifiers always mean "match by equality without binding", then
there would be the same expression versus pattern symmetry for nullary
ctors and any other reference.

This was what the abandoned '?' sigil accomplished, right?  It was for
creating a new binding on match?

I'm starting to like that abandoned approach.

Ok, I'm going to bite my tongue until I have a lot more context, such
as experience writing a bunch of rust code, and a better understanding
of the community and direction.  I hope I haven't stepped on any toes.

> -Graydon


> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

More information about the Rust-dev mailing list