[Grace-core] Collection naming

[Andrew P. Black]

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

(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.

(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 maybe *factory object*) is a good name, and
is used in the GoF patterns book in that sense.

(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.

(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.

(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.


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.

(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.

(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.  (So we may also need a "has same
elements" method on mutableSets, since that can't be ==).  We probably need
plugable set and plugable dictionary to handle the more unusual cases.

Enough for now.

    Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20140630/818c1bad/attachment-0001.html>