[Grace-core] [Minigrace] In praise of consistency

[Michael Homer]

On Sat, May 19, 2012 at 1:05 PM, Andrew P. Black <black at cs.pdx.edu> wrote:
> Hence, I propose simple rules that say things like
>
>        (0) expressions within parenthesis association most tightly
>        (1) message requests with . bind next most highly
>        (2) Binary operator symbols come next
>        (3) juxtaposition for parameterization binds more loosely
>        (4) mix-fix method names extend as far to the right as possible
>        (5) within a precedence level, association is left to right.
>
> Under such rules, both of the above would mean
>
>        print ("hello" ++ world)
>        length ("hello" + total)
>
> and if the programmer wanted the other thing, she would have to write
>
>        (print "hello") ++ world
>        (length "hello") + total
>
> Putting "hello" in parens is quite valid, but does nothing to disambiguate or change the interpretation from one to another — UNLESS
> we give parens two entirely different meanings.
They already have two entirely different meanings: one is precedence
grouping and one is application, and that isn't avoidable unless
application uses something else. As soon as something has more than
one argument you're going to have to parenthesise them. Or lose the
commas and switch to Haskell-style juxtaposition everywhere, but then
you can't have mixfix.

> Again, we can put parens around x and y all we want, but since x and y are already atomic expressions, that will have no effect on the parse  — UNLESS we give parens two entirely different meanings.
>
> I would be open to simplifying the above rules even further, perhaps eliminating the distinction between binary operators and juxtaposition.   I willingly admit that I do find it hard to see all of the consequences.

One of the major problems is that you don't know you're in a mixfix
name until after the argument is parsed, but you will need to know it
in order to parse the argument. It's not unsolvable, since you will (I
think) always hit an error eventually, but you will need to backtrack
and the parsing rules become very complicated to explain. Certainly
people will misinterpret them even if the parser doesn't.

Something like:
  print x.y(z) a b
could be:
  print (x.y(z))a(b)
or:
  print (x.y(z)a(b))
and it's not clear which it should be. I think your rules make it the
latter, which I think means that:
  print x.y a b
is a syntax error "missing argument to part b of y()b()". It could
also be "missing argument to part b of print()b()" or:
  print(x.y)a(b)
or even:
  print(x.y(a(b)))
. I'm not entirely sure that it isn't, but the rules aren't as simple
as you'd want.
-Michael