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

[James Noble]

> Interesting discussion! I'm not much of types person, but I guess (/would propose) that in any case runtime execution should never depend on types. I'm pretty sure you're aiming for this (seeing the discussion above), but (if it's actually the case) it would be good to make this *very* explicit in the spec. 

ha! 
yes that's a good point - even if the answer is: execution "mostly" doesn't depend on types... 

> Regarding the "syntactic vinegar", I wonder why this syntax was chosen in the first place. Is it really unparseable with single [], or even <>?

no, it's parseable with either, and we mostly used <> until relatively recently 
(ok til Wadlerfest) when I somehow talked Andrew & Kim into switching.

partly this was because the rules with <> were that <> meant brackets
*unless surrounded by spaces* when they meant comparison operations.
on the other hand, for all other operators  (except "<<" and ">>" etc  I guess)
spaces were *not* required.  That inconsistency was horrid. 

Kernan requires spaces around all operators, which I now like: 
adopting that rule would easily disambiguate e.g. [ ] or generics.
<> not so much because we want them as operators characters
in a way we don't want []

> For instance, as far as I can see, the only place where [] are used are lineups.

that's right. we got each bracket pretty much used in only one place
(except { } which are used in lots of places, notably for lambdas but
also for grouping).    At one point I did look at going semi-Python:
{} for lambdas/blocks but just layout for classes/methods/objects...

> You could require at least 1 space to occur before a lineup, and disallow a space before the [] actual generic type arg.

right, yes that would work.  But people seemed to be against that kind of space-sensitivity, or actively like being post-ascii. 

Alternatively we could get rid of lineups :-)
Lineups came in when we removed varargs: overriding by arity
(which I don't particularly like) came in at the same time,
but with an injunction not to use it.

Given that we have if/then/elseif/then,  match/case/case/case... and friends
nominally implemented by a whole bunch of methods (since we don't have 
Michael's nice generalised methods, or even a simpler version of it) 
I don't see why list or set or seq couldn't be "implemented" the same way.


> I assume type args on call sites will always be after the selector name (or the first keyword component). This would work with both prefix ops -[Int] 3, infix ops 1 +[Int,Int] 2, and keyword messages if[Bool,Block,Block] () then {} else {}.

yep. currently you have to have once space between ops and generic params. 


> James and I  also had some discussion of the offside rule. I have an implementation of it, that seems to make sense. Below you'll find an excerpt of my test suite; perhaps they can be added to a/the central grace test suite?

currently the only test suites are per-implementation.
we should sort that out.  sometime. 

> You can find Rascal's grace grammar here: https://github.com/cwi-swat/grace-grammar/blob/offside2/src/DynGrace.rsc

OK cool!

James