<div dir="ltr">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.<br><div><br></div><div>E.g., the following two methods give you the null and non-null cases for printing values.</div><div>method print(*a) {...}</div><div>method printNewLine {...}</div><div><br></div><div>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.)  </div><div><br></div><div>To me, it seems like a fairly simple and straightforward solution to the varargs problem.</div></div><br><div class="gmail_quote">On Mon, May 25, 2015 at 10:29 PM James Noble <<a href="mailto:kjx@ecs.vuw.ac.nz">kjx@ecs.vuw.ac.nz</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andrew<br>
<br>
we did talk about this a bit in the teleconference. We confirmed we’ll permit “()” for null varargs lists,<br>
which addresses the immediate problem.<br>
<br>
> The thing that you refer to as “built in sequence” is not part of the Grace language.<br>
<br>
right. but we could put it or something like it back in.<br>
<br>
>  You may be confused because minigrace still accepts it;<br>
> that’s because the minigrace compiler still uses it, and when I took it out, the compiler slowed down unacceptably.<br>
<br>
there is also the “what *varargs” get bound to “sequence” or whatever.<br>
<br>
> Removing it altogether is still on my list, but not a really high priority.<br>
<br>
I wouldn’t have it has a high priority.<br>
<br>
> 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.<br>
<br>
right, or combinations of operator brackets [+ +] or [- -] or something.<br>
<br>
talking briefly after the telecon, basically the issues are (as we known)<br>
 - ambiguity between < > as “operators" and as generic parameters<br>
       requiring space around binary operators, and delimited arguments resolves this...<br>
<br>
 - ambiguity between [ ] (or other brackets) as “indexing” vs as “collection constructors” (matchfix / circumfix operators)<br>
       IF those brackets can count as delimited then there is a real ambiguity<br>
       we could resolve with spaces (as I think minigrace did)   a[x] -> indexing, a [x] -> pass collection of [x] to a<br>
        but as Michael (I think) pointed out that’s to subtle a distinction<br>
<br>
       we could give up on indexing (which many of you have reached already) which resolves this...<br>
<br>
 - we’d still have to have some basic varargs functionality anyway,<br>
    to gather up the contents of the collection constructors / matchfix operators<br>
    although it could be restricted to just those operators.<br>
<br>
  I still fantasize about occasionally simplifying things.<br>
<br>
James<br>
_______________________________________________<br>
Grace-core mailing list<br>
<a href="mailto:Grace-core@cecs.pdx.edu" target="_blank">Grace-core@cecs.pdx.edu</a><br>
<a href="https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core" target="_blank">https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core</a><br>
</blockquote></div>