[Grace-core] collections interface for new classes

[James Noble]

Hi all

so I’ve started looking at moving libraries and updating the spec
for the “new” class design etc.  I’m starting with collections
because I’ve already done an initial port to kernan. The question
is: what interface should the collection library offer.

the current library, done by Andrew, has sequence,  list, set, dictionary.
there is a factory object for each implementation, and each factory
has three methods:  withAll(_:Collection<T>), with(*a:T), and empty. 

so after importing the library

> import “collections” as col 


you can create instances of the collections e.g with

def e = col.list<Car>.empty
def l = col.list<Car>.with( datsun, honda, mini )
def ll  = col.list<Car>.withAll( l  )


so there are at least two issues here. One is where the generic parameter goes:

| col.list<Car>.with( datsun, honda, mini )

versus 

| col.list.with<Car>( datsun, honda, mini )



the second is what level the constructor methods should be e.g. 

| col.list.with<Car>( datsun, honda, mini ) 

versus something like 

| col.list<Car>( datsun, honda, mini )

as we’ve already got a receiver - the module object “col”. 



and then there is the issue of what & how many constructor methods we need.

> col.emptyList<Car> 

is subsumed by 

> col.list<Car>   //aka   col.list<Car>()


we also need a way to create a collection from another collection (the withAll method) 
this could also be at the top level 

> col.listFrom<Car>( l ) 


A slightly evil alternative could be to combine both these methods into one,
e.g. by an “all” wrapper around a collection, so that 

> col.list<Car>( audi, l, holden ) 

would create a list something like “audi, list(datsun, honda, mini), holden”   
(or rather, hopefully give 

> col.list<Car>( audi, all(l), holden ) 

would create a flattened list “audi, datsun, honda, mini, holden”

unfortunately, the obvious design for this requires another method on all objects
(which could be quick in a jit)   or otherwise pattern-matching against every argument
to see if it is an “all” which must be unpacked...


the question of whether we have varargs or some kind of 
built-in collection literals, probably affects the API design too.