[Grace-core] Some comments from Tijs on parsing Grace

[James Noble]

>> even if the answer is: execution "mostly" doesn't depend on types...
> 
> Ok... I presume (hope) you're referring to pattern matching here... ;-)

pattern matching, plus if it is possible to catch a failed type check exception
(the spec doesn't talk about that either)

> I agree that layout sensitivity should be a last resort (except for things like longest match of identifiers etc.). If it perfectly matches default style of writing however, I think it would be ok. 

yep...

> Does this mean Lineups can't be nested? What about:
> 
> x.set[[y]]

so my answer here is that the "longest match of identifiers" rule is extended to operators and brackets. Just as "aa" is space sensitive vs "a a" so "++" is space sensitive vs "+ +" and "[[" is space sensitive vs "[ [".     The current exceptions to this rule - there is always - are only for () and {} brackets, but they're pretty special. 

> Yes. The nice thing about varargs is that you avoid the nesting opportunity 

yep. 

> (unless you have a splat operator a la Ruby).

we've thought of that 

> You can make it simple in Grace, by only allowing selector component to be *either* a list of params, *or* a single varargs (so, no "x, y, *z", rest argument patterns). 

yep. I quite like that option.
I wonder how much  code there is that uses multiple parameters in the second or subsequent parts?

Here's a request: could people run this over their code:

egrep "^(.*)method(.*))(.*),"   `find . -name \*.grace` |grep -v \} | grep -vi test

(it won't find method decnls where the , is on a second line. but...)

> It is then still possible to state that the vararg formal will be bound to some unspecified object that supports iteration, but nothing else

which is how variadic parameters worked before, or originally.

> (although personally I think it should just be a standard library list/array object...).

it should be a (shallow read-only) sequence 

I like handling things on the receiver side: give that we already do something special for if & case, doing something similarly special for a few collection operators seems fine to me. After all we want to say people can rewrite "if"
and "while" --- why not other things.

J


THINKS: another option would be a doesnotunderstand check on the dialect and handling things there somehow.
THINGS AGAIN; that way likes Macros. Macros lead to Lisp. Lisp leads to the Dark Side.