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

[James Noble]

short answer - yes, Kim is right, this needs to be like Smalltalk (Self, Newspeak) etc.

argument lists have to be in parens (or curly brackets, or *perhaps* square brackets - although that's tbd)

so it has to be if (x) then {foo} - 

I think this is what the CollectedBNF on the web page says;
not sure what Andrew's PEG does - things have go confused with the idea of saying
we always pass a single argument (that may be a tuple), and wanting to be able to
write things like print "Hello" without arguments... 

perhaps I'm confused by thinking I'm reading Smalltalk, but (with Michael Kölling's words ringing in my ears)
we should be really careful about how complex we make this!

I could see a rule that says arguments must be 
 - quoted strings
 - in parens
 - in curlys

so 
 print "Hello"
is OK, but  
 print foo 
is would have to be 
 print (foo) 

argh.    how come something that is supposed to be so simple 
turns out to be so crazily complex

J

On 28/05/2011, at 11:19 AM, Kim Bruce wrote:

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