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

[Tijs van der Storm]

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

Ok... I presume (hope) you're referring to pattern matching here... ;-)


> > 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.
>

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.

Does this mean Lineups can't be nested? What about:

x.set[[y]]

Seems ambiguous to me, unless there's still whitespace sensitivity here.
Disallowing nested line ups would also mean one more exception in the
manual...



>
> 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.
>

Yes. The nice thing about varargs is that you avoid the nesting opportunity
(unless you have a splat operator a la Ruby). 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).
It is then still possible to state that the vararg formal will be bound to
some unspecified object that supports iteration, but nothing else (although
personally I think it should just be a standard library list/array
object...).

T


>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20160727/caa915ce/attachment-0001.html>