[Grace-core] Collection naming

[James Noble]

> 
> This clearly requires a conversation, not more email.   But, a few comments:

indeed!  

> (1)  For variable arity methods only, I think that it makes sense to use empty parens to indicate an emply argument list — which is not the same as a method with no arguments.  I agree with Kim that allowing set to mean set() is probably a bad idea. 

I don't think we want different syntax for requesting a "variable arity method with no arguments"  versus a "fixed arity method with no arguments".


> (2) James, you are using the word class to mean "class object".  But we agreed a month ago that class means factory method.  This doesn't stop us having objects with factory methods, but we need  a name for them that's not "class".   Factory (or maybefactory object) is a good name, and is used in the GoF patterns book in that sense.

sure; mea culpa; we have to if not finally convince Kim, 
at least get him to agree to update his book / labs (ideally by monday next week which *isn't* going to happen).
but we should be able to fix it with the testers, and just tell them to write class foo'new say, instead of foo.new :-)

> (3) James wrote:  I lean towards point as the class, Point as the type,  aPoint as a variable of type Point...   I thick that I agree with this.   Using indefinite articles for classes seemed like a good idea for a while, but I think that it's hard to justify.  Remember Sean's very negative reaction at WG2.16.

yep. 

and that's the other lesson I learned from 2.16 - 
even though "classes" may be logically unnecessary, 
if we don't have a class keyword, Lua and JavaScript sho that people will invent the,

> (4) We can't keep [] as a list constructor, because we don't have it, in spite of it working in minigrace.  I prefer to keep it as an operator.

yes, I know, mea culpa again. 

mg has both but it is very confusing. 
I'd be slightly more willing to allow a call like set[]  rather than set()!  (currently my grammar doesn't allow []) 

> (5) Kim wrote:  adding [exploding collections into argument lists] seems intuitively as something that couldn't be done in the language, so I'm reluctant to add it to the language without stronger motivation.  I don't follow this argument.  Yes, exploding a collection into a variable arity argument list is something that can't be done in the language.  If it could be done, then I wouldn't be suggesting an extension.   Here is a principle: we should add language extensions only when there is no good alternative.  

but that's where the real fun comes in, isn't it. 

we could get rid of varags lists, and only pass (nominally-homogeneous) collections;

we could have the lightest possible syntax for an empty Collection , lifting a single element to such a collection
(Tim still hasn't said "Hlists") 

> The motivation is: suppose a library gives you a variable-arity method.  You want to request it.   You have a variable number of arguments that you want to pass to this method.  But you don't have them as a small number of literals: you have them as a collection.  How do you request the variable arity method with the objects in your collection as the arguments?
> 
> Right now, our only answer is to not do that, and to tell all library designers not to do that.  Instead, they should write a fixed-arity method that takes a collection, and to define the variable-arity method as an alternative interface to the fixed-arity method.   This seems like telling students to write a non-obvious program to get around a language deficiency.

yes, that is indeed the problem. 	

> (6) I think that the best names for immutable set and immutable vector are imutableSet and imutableVector.   The best names for mutable set and mutable vector are  mutableSet and mutableVector.  They don't require explanation, and promote readability by those who are not experts on the libraries.  Yes, there is more to type — but didn't we agree to the principle that readability is more important than writeability?   Dictionaries are a bit trickier: the mutable case is much more common, I think, and mutableDictionary is a bit long winded, even for me.  But if we start using Dictionary and Function for the mutable and immutable cases, then we might as well use array and list for the mutable and immutable cases of sequence.  

I don't think there are any "best" names.  Some are better than others, or agree with our prejudices and backgrounds better than others.
We also agreed that "good" things would be shorter (or not longer than "not so good" things).
the thing about dictionaries is a) how big do they get, and b) do you remove or overwrite bindings?
(Lurching back to method arguments, we haven't got optional keywords, but there is the ruby (python?) Lua?)
idiom of passing a dictionary in instead; if that catches on, there'll be lots of small immutable hash tables...

Given that other languages have done it, I think we could just pick names from the soup that's already out there
Grace has tables like Lua (aka python Dictionaries, Java HashTables), Sets like Python, etc
(except bunches, which Python has but calls "frozenset"s) 

What's we need to remember  is that class names are much less important in Grace than type names;
and that both are much, much less important than the API.
Andrew - is there something that we can look at about your collection API? 


again, I'm thinking of a spec (<50 pages) + appendices ( :-) that we take to Eelco & co.  

> (7) Sets should use the == operation on their elements, and Dictionaries should use the == operation on their keys.  If those elements or keys are mutable, then == should be object identity, because it doesn't make sense to use a mutable property as a key or a set element.   Hash for these things should be identityHash, or course. 

I think I agree with this- and that's more-or-less where we got to in our teleconference.
Value/immutable objects should be able to get a different version of == & has, but not other objects.

> (So we may also need a "has same elements" method on mutableSets, since that can't be ==).  

or convert to immutable and == that?  (yeah, slower) 
I'm wary of "has same elements". 
Python has a nice take on things that I didn't realise: mutable objects, especially collections 
aren't hashable, so can't be in sets or as keys in a dictionary. 
In Java, almost the only use of redefining equals are collections.
with some support for value objects, and some immutable collections,
you should never really need to do that in Grace.

> We probably need plugable set and plugable dictionary to handle the more unusual cases.

let's walk before we run...

J