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

[Kim Bruce]

If I'm understanding this correctly, the problem occurs only (primarily?) with mixfix parameters.  I'm happy to treat mixfix parameters as being equivalent to other cases with multiple parameters, thus requiring parentheses.  Thus only methods with a single parameter can be applied without parameters (I would treat curly brackets as having implicit parentheses around them).   Thus o.m arg is fine, o.m arg restOfm args would not be fine (if restOfm is part of the parameter name).  

If I remember correctly, Smalltalk requires ":"s after each part of the mixfix name.  I suspect that was necessary to disambiguate cases like those in your e-mail.  Perhaps someone else has solved this problem.  If not, then we might have a serious problem.  As I understand it, the main reason we need mixfix is to be able to define and use control structures that look like built-in control structures of other languages.  While it is desirable, I don't see it as a necessity.  Does anyone know a language that uses "unmarked" mixfix notation successfully?

Kim



On May 27, 2011, at 3:43 PM, Michael Homer wrote:

> 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
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core