[Grace-core] In praise of consistency

[James Noble]

On 19/05/2012, at 13:05 PM, Andrew P. Black wrote:

> I am arguing that the way to do disambiguation this is with a few, simple, consistent rules....
> 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.

so we do have these rules, or at least most of 'em, mentioned in passing in the spec,
and encoded into the grammar in the appendix. Looking at page 34-35 of the 0.353 spec,
I think the priority rules are (lowest to highest, i.e. weakest to strongest) 

1) assignment operator :=  as a suffix to a keyword message
2) "other" operators; no priority for different operators, associate left to right
3) add operators + and -
4) multi operators * and / 
5) prefix operators
6) dotted request (with or without arguments); or square brackets
7) literals, parenthesized expressions

in the grammar, the rule about arguments / juxtaposition requires a "delimitedArgument".
Delimited arguments are currently defined as comma-separated argument list in parentheses, or block or string literals.   

I think this is clear, teachable, and unambiguous. The point is that - x.sin  parses as - (x.sin)
not (-x).sin.  That's fine, although it makes certainly horrible things - using prefix operators
as if they were sigils - uglier.  In a scripting dialect, you could have $1 being the first
word of the argument ($ prefix operator on Number)  but writing $1.toUpperCase won't do 
what you want as it parses as $(1.toUpperCase)  not ($1).toUpperCase. 

But one of the things I like about Grace is that there aren't lots of horrible sigil-based globals flying around.

> I willingly admit that I do find it hard to see all of the consequences.

so do we all!

James

Yes there is clearly scope for tweaking here, e.g. considering numeric literals to be "delimited"
as minigrace currently allows.  But there are other tweaks too that we could consider -
  * allowing request to terminate with a name, so you could do "if()then()else()fi" - with that trailing "fi"
     or for ruby/ada style, if()the()else()do()end"
 * allowing multiple delimited arguments without separating words.  For example
      repeat (5) { print "Hello" } 
           rather than 
      repeat (5) times { print "Hello" }
 * hmm yes this does look better as just  
      repeat 5 times { print "Hello" } doesn't it?
 * things like optional/repeated/defaulted/paired multipart names,
     - e.g. match (subj : Any)  *case(*block : Block)   // handles multiple cases! 
     - especially useful for object creation / builders
           class Button.named(name : String) ?backround(bg : Colour = Colour.grey) ?margin(margin : Number = 3)  
          defines methods named()  named()background() named()margin() named()backround()margin() and presumably named()margin()background()

note that all of this fits within the current client-side request syntax and priorities.

James