[Grace-core] collections interface for new classes

[Andrew P Black]

On 9 Dec 2015, at 0:48, James Noble <kjx at ecs.vuw.ac.nz> wrote:

>>> the question of whether we have varargs or some kind of 
>>> built-in collection literals, probably affects the API design too.
>> 
>> Absolutely it does.  We agreed in Claremont, I think, that we were going to replace varargs with a notation for sequences.  This would make sewunces "special", but then they are special now, anyway, because a * argument is made on by magic.
> 
> OK yep I remember that - In fact it’s on the todo list.
> 
>> We also agreed, long ago, that collections should be "built-in", so that novices can just use list, set and sequence without having to import them.  Are you suggest ing that we revisit that?
> 
> I don’t want to “build in” the whole collections library to *everything*.
> those definitions should come in a student or standard dialect.

You are right; I should not have said “built-in”, even with the quotes.  I should have said: included in the dialect “standardGrace”.
I think that “beginningGrace” should actually have a simpler set of objects, for example, the map and filter operations should be eager and should produce 
objects of the same ilk as the receiver.  So that, for example, filtering a list will generate a list.  The lazy iterables are nice, but maybe not for novices.

But my point was that the typical user won’t write collections.list[a, b, c] or collections.list.with[a, b, c].  They will write list[a, b, c] or list.with[a, b, c].
That may influence how we choose to name stuff.

Of course, not every possible kind of collection will be in a dialect.  If Matrices are not, then we should consider what classes the the matrix module defines.

>> One advantage of sequence.empty over sequence [] is that the former can return a constant.  But maybe this is not a problem if sequence literals are built-in.
> 
> if “sequence” is the built in sequence then we’d probably just write [] anyway…

That’s what I meanest when I said maybe this is not a problem.  The compiler could generate a different code sequence for empty collections.  But there still needs to be an objet for the generated code to request.

>> I don't understand what your `all` wrapper would do.
>>  When we had varargs, I was arguing for something like `all`, so that a client with a collection could use it to request a varargs method.  (And I thought that you argued against it ;-)  But now we have got rid of them, what do you want `all` to do?
> 
> that’s what I want it to do (and we could indeed use a prefix asterix if we wanted.

I’m asking: what is “that” ?

> I’m willing to consider it now because
> - it would be implemented in library code (probably by testing the arguments
> - it does simplify the collections interface
> - it doesn’t overcomplicate every request everywhere
>    (splat in varargs is that it can be used in non-variadic calls too)
> 
> This does simplify things though:
> list [] - empty list
> list [a,b,c] - literal list
> list(foo) - build list from a collection foo 

We have those three forms.  The idea is that list iterates through its argument (which is always utterable) and adds these elements to the list that’s being created  
But you don’t use `all` here.  I have no idea what `all` does, in your mind.

What I hope that it doesn’t do is make it impossible to decide statically how many arguments a request has.  That would be a very bad idea, in my view.

> collection constructors now feel like wrappers over the builtin sequences
> 
> the other question is: do [] collections have a minimal or a maximal interface:
> do we have to write “seq [1,2,3]” or will just "[1,2,3]" do?

Obviously, I’m invested in the current set of interfaces.  I’ve redesigned them three times.  They are not perfect, I’m sure, but they have suffered through two ten week teaching sequences, and many mutations due to feedback from students.  

So, I suggest that […] support the `Iterable` interface.  This is smaller than Sequence, in that it does not support indexing or tests for containment.  It doesn’t even support `size`!  This is perhaps going too far, since the size of a […] literal will always be known.   Maybe we need a slightly larger type FiniteIterable that has a size method. 

We could also use the `Collection` interface:

type Collection<T> = Iterable<T> & type {
    asList -> List<T>
    asSequence -> Sequence<T>
    asSet -> Set<T>
} 

> 
>> Finally, the place for this discussion is in the gracelang/languages issue tracker.
> 
> well I was hoping for a slightly wider discussion than I’d get there. 

?

	Andrew