[Grace-core] Collection naming

[James Noble]

> It occurred to me that it would be more graceful to just let students write
> 
> 	set(2, 4, 6, 8)

I like this, and this is (close to) Scala
(actually scala involves calling a set.apply(2,4,6,8) by magic...

> or
> 	set()

() in Grace is a syntax error, although minigrace accepts it.

> rather than  aSet.with(2, 4, 6, 8), or aSet.empty, and that if we did that, then perhaps James would stop threatening to add some special syntax for collection literals.  So I set out to do it.
> 
> And that's when I realized the problem with the lack of a mechanism for "exploding" an argument list.   We can get rid of .with and .empty and replace them by direct requests on the class, but we really must have .withall.

so the issue here is passing in a collection, and making a new set with the instances of that collection.

I think this is the python?  ruby?  "splat" operator: *foo assumes foo is some kind of collection (or tuple)?
and pastes it in to the argument list.   I can see how this works dynamically, not so sure how it can be checked statically
(although I guess you could follow scala, which has a splat that *only* works to call varargs.
(Scala's syntax is ":_*" (apparently repeated type ascription)   which I don't suggest for Grace.


> This doesn't stop me defining a method set(...) as a synonym for aSet.with(...).  But it does stop me from getting rid of the factory methods completely.

there are probably some evil, evil, options:

      set // returns an emptyset
      set(1,2,4) // set of 1,2,4 

being varags methods.  Note that you'd need to give a type explicitly if you wanted it  

        set<Number>(1,2,4) 

as Grace can't infer the type

set.addAll(c) - adds all collection into the empty set:  a **mutating** operation, but it could be special cased.
  Not as efficient as sizing the set from the beginning, but hopefully not too bad.

If set was immutable, presumably you couldn't call "addAll" - but you'd have a "set +" operation or something.
potentially set ++ c, which again could be special cased.

or for even more evilness:
  set[1,2,3] // could overload indexing operations on the _class_ to act as a literal
  set[] // Not permitted syntatically
  set<Number>[1,2,3] // Dynamic types cannot be inferred
  set.empty  // can have other methods on the _class_
  set.withAll( collection )   //like this one too

I hate to say it, but I actually quite like this, even though it is more than a bit evil. 
It's probably just too late at night.   But it does argue strongly against special literal syntax
(unless that special syntax infers types or something  (yes Tim, I can say HLIST) 


> I'm getting more and more unhappy with the asymmetry of variable arity methods.

well, sure, but this isn't close to the top of my list of unhappinesses.

such as: only now did I realise we use "++" in a completely different way to other C-family languages.  Oops. 739 times in minigrace. 

James