[Grace-core] Precedence of multi-part method names

Michael Homer mwh at ecs.vuw.ac.nz
Fri May 27 15:43:14 PDT 2011


Hi,
I've been running into some precedence problems parsing multi-part
method names. The major problem is that without parentheses to
disambiguate it's hard to tell where one ends and another begins or
continues. Are parentheses required on arguments to these methods?
Required only when it would be ambiguous? Currently the specification
and the wiki are mixed on that.

To put the question into a concrete perspective, which of the
following should be expected to parse in the obvious way?
1) if x then { ...
2) if f x then { ...
3) if x.not then { ...
4) if x.at(1) then { ...
5) for course.students each { ...
6) canvas.drawLineFrom shape.vertex(i) to shape.vertex(i+1)
7) if x.isBetween 5 and 10 then { ...

The most interesting of those is (4). My implementation originally
gave a runtime error there, "no such method at()then in Object", which
makes perfect sense but was not at all what I expected. I'm now
avoiding that for these exact cases by special-casing "then", "each",
and "do", but that obviously isn't the right approach. (3) and (5) may
also be ambiguous, given the syntax for unary method requests,
although that case will often be catchable as a syntax error.

What's the rule on this? If it's the "sometimes required" case, I'm
also interested in how to give a sensible error message to somebody
who isn't conversant with the complexities of the method syntax, or
perhaps doesn't yet know that if ... then ... is a method request at
all.
-Michael


More information about the Grace-core mailing list