[Grace-core] minor language issues

[Kim Bruce]

I also suggested the fairly simple solution to the null var args problem as
having a varargs parameter mean one or more rather than zero or more
occurrences.  It just means you have to define a new method for the null
case if needed.

E.g., the following two methods give you the null and non-null cases for
printing values.
method print(*a) {...}
method printNewLine {...}

In my opinion, varargs are sufficiently rare (particularly for students
writing code) that this extra definition is not a major pain.  In fact, I
believe Andrew used this for the constructors for the collection classes.
 (I believe he has also argued that one should write the version of the
methods taking the list/sequence before writing the vararg version.  Hence
there is only a tiny amount of extra work here.)

To me, it seems like a fairly simple and straightforward solution to the
varargs problem.

On Mon, May 25, 2015 at 10:29 PM James Noble <kjx at ecs.vuw.ac.nz> wrote:

> Hi Andrew
>
> we did talk about this a bit in the teleconference. We confirmed we’ll
> permit “()” for null varargs lists,
> which addresses the immediate problem.
>
> > The thing that you refer to as “built in sequence” is not part of the
> Grace language.
>
> right. but we could put it or something like it back in.
>
> >  You may be confused because minigrace still accepts it;
> > that’s because the minigrace compiler still uses it, and when I took it
> out, the compiler slowed down unacceptably.
>
> there is also the “what *varargs” get bound to “sequence” or whatever.
>
> > Removing it altogether is still on my list, but not a really high
> priority.
>
> I wouldn’t have it has a high priority.
>
> > If we make various kinds of brackets user-definable methods, then we
> could have uniform syntax and use [ ] for sequences.   But that would mean
> using more brackets, which you don’t like doing … although there are lots
> of them.
>
> right, or combinations of operator brackets [+ +] or [- -] or something.
>
> talking briefly after the telecon, basically the issues are (as we known)
>  - ambiguity between < > as “operators" and as generic parameters
>        requiring space around binary operators, and delimited arguments
> resolves this...
>
>  - ambiguity between [ ] (or other brackets) as “indexing” vs as
> “collection constructors” (matchfix / circumfix operators)
>        IF those brackets can count as delimited then there is a real
> ambiguity
>        we could resolve with spaces (as I think minigrace did)   a[x] ->
> indexing, a [x] -> pass collection of [x] to a
>         but as Michael (I think) pointed out that’s to subtle a distinction
>
>        we could give up on indexing (which many of you have reached
> already) which resolves this...
>
>  - we’d still have to have some basic varargs functionality anyway,
>     to gather up the contents of the collection constructors / matchfix
> operators
>     although it could be restricted to just those operators.
>
>   I still fantasize about occasionally simplifying things.
>
> James
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20150526/1d4b5155/attachment.html>