[Grace-core] collections interface for new classes

[Andrew P Black]

On 12 Dec 2015, at 3:41, James Noble <kjx at ecs.vuw.ac.nz> wrote:

> Doing due diligence through Andrew’s & Kim’s code for varargs methods:
> 
> * collections has a bunch, mostly around add & remove (they’re in parallel)
> I think the full suite is:
> 
>> add(*x) 
>> addAll(elements) 
>> addAllFirst(l) 
>> addFirst(*l) 
>> addLast(*x)
> 
> there seem to be two options here: 

These varargs methods are a case of “because it was there”.  We should just remove them.

Because Grace had variable arity methods, it seemed easy to extend add and remove to take multiple arguments.  But there is hardly a use case for them.

If you have two or three specific elements to add or remove, then two or three separate add or remove requests are quite logical, simple, and clear.

If you have a whole collection of things to remove, then addAll and removeAll will do the job.   The variable arity methods are of no help. Moreover, their existence imposes an implementation cost that is quite unnecessary in the normal case of wanting to add or remove a single element: first building the (singleton) collection, and then iterating through it.

In hindsight, this was a case of optimizing for the uncommon case. In my defense, I will claim that I was led astray by the temptation posed by varargs.  So now we have got rid of varargs, we can get rid of these methods.

> 
> 1. take the varargs versions back to single elements,
> leave the “All” versions taking collections
> 
>> c.add “x”
>> c.addFirst “x” 
>> c.addLast “x” 
>> 
>> c.addAll [ “x”, “y” ] 
>> c.addAllFirst [ “x”, “y” ] 

Yes, this is what we should do.

> 2. dump the single element versions, do everything with collections,
> everyone has to lift objects into collections
> 
>> c.add [ “x” ] 
>> c.addFirst [ “x” ]
>> c.addLast [ “x” ]
> 
> “contains” would term into “subset” I guess;
> 
> * there are also a couple of other methods in the prelude
> 
>> StandardPrelude.grace:method max(a, b, *xs) {
>> StandardPrelude.grace:method min(a, b, *xs) {
> 
> I presume these just lose the varargs argument;
> If it’s a big problem, we could put min & max into the collections interfaces.

I was wondering about these.  For collections, having min and max as methods makes sense.   Again, most use cases of min and max as top level functions take two arguments.  We could have min3 and max3 for those rare cases where three arguments are used.  For four or more arguments, creating a sequence and taking its .min seems appropriate.  
> 
> * objectdraw has precisely two varargs methods for creating selection boxes
> 
>> objectdraw.grace:  factory method options (*options: String) labeled (label': String) -> Choice {
>> objectdraw.grace:  factory method options(*optStrings: String) -> Choice {
> 
> * Kim’s book doesn’t declare varargs methods at all and has two mentions in the text
> (one for creating selection boxes, one for lists)
> 
> ch10-gui/GUI.tex:three options, but we could just as easily had 6 or more.\footnote{We say that this method has \lstinline{varargs}.
> ch13-arrays/create.tex:This is our first example of the use of ``varargs'' in Grace.  It simply means that
> 
> * amg (Andrew’s minigrace) has a few methods in the AST and parser
> 
> ast.grace:    method new(*values) scope(s) {
> ast.grace:    factory method new(*values) {
> ast.grace:    factory method new(*values) {
> parser.grace:method findNextValidToken(*validFollowTokens) {

I inherited two of these from Michael.  They should be removed and replaced by methods with meaningful names.  I added method new(*values) scope(s)  so that I could initialize the scope argument and then forward to one t=of the others; this was me being lazy.

> PS andrew - which is the best current version of collections to work on? 

I just checked-in a new version to apblack/minigrace, and have just this minute push it to gracelang/minigrace ( I was waiting for the Travis tests to run green.)

> PPS if we’re allowed “min” and “max” surely we are allowed “seq” as well?
> 
> PPPS if we add “min” and “max” into collections, there’s average, and sum, and … 
>  although here I think I’d be very happy to have a trait that mixed this in to the collections library elsewhere

The problem with min and max is that these work only for total orders, and not all collections have total orders.   Smalltalk leaves this up to the programmer.  Is there a stringily-typed solution that is as convenient, but more foolproof?   Sum and Product require that we can find the zeros for the + and * operations, and indeed, know what the appropriate operations are called. (Addition on strings is spelled ++, while addition on numbers is spelled +.  Multiplication on Strings doesn’t exist, although multiplication between strings and integers does …  So maybe we should leave them all out, and ask the programmer to write a fold.  

	aCollection.fold{ acc, each -> min(acc, each) } startingWith (aCollection.first)

where she gets to choose the combining operation and the starting value?

	Andrew