[Grace-core] Collection naming

[James Noble]

On 3/07/2014, at 16:32 pm, Andrew P. Black <black at cs.pdx.edu> wrote:

> If the list has two arguments, the varargs parameter is bound to a list containing the values of those two arguments.  If the list is empty, the varargs  parameter is bound to an empty list.   I would argue that it should be an error to fail to provide an argument list in the request.

well that's the question (or at least part of it).
I think, if you have to supply an empty list explicitly, you can get almost the same effect with a tuple/list/hlist/whatever literal syntax
rather than varags (which seems to me to be both more complex and less general the a collection/sequence/whatever literal)

> We could do something Pythin-like and make , a tupling operator, so that (1,2) is a single object, viz, a tuple containing 1 and 2.   I actually had this in my grammar in 2011, but we decided that variable arity methods was a better choice.  I’m happy to revisit that at some point, but probably after the end of Kim’s course.

right. As I recall, the problems with that design were:
 - being able to distinguish between a call of single argument "a"   and a single argument in a tuple "(a,) in python i think"
 - you could say a single argument is automatically (implicitly) tupled at the call site 
    - that's a bit evil, a bit like what we've got now, and at least makes the definition side semantics consistent
 - to look like C, you'd need tuple destructing in function definitions
    - or we could go more like Smalltalk, basically make  foo(x) bar(y) methods easier to write then foobar(x,y)
 
> But it is entirely reasonable to use the identity of a mutable object as a key. 

perhaps - but it could equally be misleading / surprising - because the behaviour of equals
will now be different depending upon collection mutability - so arguably bad practice.
not making mutable collections "hashable" or whatever avoids that surprise
(but now not every object is hashable. duh).

J