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

[James Noble]

> I believe that this is the discussion we are having.  I don't think that the parenthesis
> should mean adding arguments to a method request.   You do.

So do I - and the reason is that this convention goes back 
via Java, C++, C, and BCPL to Fortran. The other "mainstream"
convention is I guess the scripting language convention which
comes  from the shell originally, and has no parens but
typically uses various delimiters - single and double quotes etc 

> Yes, I agree with that.  I was trying to think of this as a single argument that's a tuple, but
> right now we don't have tuples.  

so this is a choice we could make - I swing in and out of it.
(If anyone would like another take, I've another OOPSLA submission
they could co-review :-)

> 
>> One of the major problems is that you don't know you're in a mixfix
>> name until after the argument is parsed, but you will need to know it
>> in order to parse the argument.
> 
> Is that really true?  If so, we need to fix our method request syntax.

I hope it's not true - but let me think.

Under the "delimited argument rule"

given foo.a "b" c (d, e)

once you've parsed the receiver and the dot
you parse the identifier: this could be 
 1- a zeroary request
 2- a "traditional" f(x) request with a single argument list
 3- a "mixfix" f(x) f(y) request with multiple words and argument lists

the next character is a delimiter - so this can't be case 1 (the options there
are basically a dot or an operator that will be taken as infix)

both case 2 & 3 now have a delimited argument list - in this case "b"
once we've parsed the b we have the same choice again - is this the end
or is it another part of a mixfix multiple part request?

we can't make that choice until we've parsed the argument request.
If there's juxtaposition - if what comes next is an identifier, we take 
it as a multi-part method request.   

The catch is, with any of the syntaxes we're describing, I can't seen how
we could choose earlier without parsing the first part of the request.  

> Yes, that's requesting print()a() using my "as far right as possible" rule

we still have that rule - although because we don't have to distinguish 
between juxtaposition for requests and juxtaposition for subsequent parts
I don't think we need an explicit rule

> However, this example does help to convince me that we need an explicit way of saying "here comes and argument". 
> Kim has suggested colon, and I have suggested square brackets.  Neither is as elegant as juxtaposition,
> but both are easier to explain to students, which is perhaps more important.

there's a reason why we didn't go with Smalltalk's syntax.
I think both of these options have the same problem: they take the language
too far away from Java and C (ok and FORTRAN).

I'm also not convinced that they help much.

  p.a: b c: d   looks OK if you like smalltalk, but weird otherwise.
 
  p.a b :c d    looks OK if you like Lisp, but weird otherwise

  p.a[b] c[d]   is unambiguous, but I think will still look weirder than what the spec says now,
      
  p.a(b)  c(d)   - and with variations, especially  p.a {b}  c {d}  

James