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

[Michael Homer]

On Sat, May 19, 2012 at 10:37 AM, Andrew P. Black <black at cs.pdx.edu> wrote:
> I would argue that
>
>        print ("hello".reversed) on (output.mainStream)
>
> is no better than
>
>        print "hello".reversed on output.mainStream
>
> since the grouping implied by the parens is already implied by the dots, which "visually" bind more tightly than the spaces.
But reversed could take arguments, which could be either "on" or
"on(output.mainStream)" there. Any sort of reference to a method can't
work in mixfix position without ambiguous parsing either for the
computer, or for the person, or both. Here you're resolving it based
on how you understand the words, but the parser doesn't know what they
mean. A different sentence structure will appear to break up
differently, but it has to mean the same thing when the syntax is the
same.

A very similar problem occurs with operators (my original problem):
  if x<y then
is syntactically identical to:
  sin x < cos y
and which way you interpret it depends on what you think the terms
mean. It gets worse with method requests in there as well:
  if x<y.sin then
has two distinct, entirely valid interpretations.

The other example has the same issue without even involving mixfix:
  print "hello" ++ world
seems obvious in that context, but in:
  length "hello" + total
or:
  upcase "hello" ++ "WORLD"
it seems to mean the opposite. Both have to parse the same way.
Whichever way you do it, it should be possible to give a sensible
error message when it goes wrong (although there won't necessarily be
an error to report).

In many cases you can resolve it with arbitrary lookahead, but "f g h
i" can still be either "f(g(h(i)))" or "f(g)h(i)", without much to
pick between them.

Arguments that might be method requests need to be parenthesised or be
potentially ambiguous. For literals there is an option either to
require it or not. The last decision I heard about allowed single
literals to appear but not anything else, and that is what I've got
implemented currently. Method application also binds tighter than
operator application for both mixfix and non-mixfix methods.
-Michael