<div dir="ltr">This clearly requires a conversation, not more email.   But, a few comments:<div><br></div><div>(1)  For <i>variable arity methods only</i>, 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 <i>set</i> to mean <i>set</i>() is probably a bad idea. </div>
<div><br></div><div>(2) James, you are using the word <i>class</i> to mean "class object".  But we agreed a month ago that <i>class</i> means factory method.  This doesn't stop us having objects with factory methods, but we need  a name for them that's <i>not</i> "class".   <i>Factory</i> (or maybe <i>factory object</i>) is a good name, and is used in the GoF patterns book in that sense.</div>
<div><br></div><div>(3) James wrote:  <font face="arial, sans-serif"><font color="#0000ff">I lean towards point as the class, Point as the type,  aPoint as a variable of type Point...</font>   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.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">(4) We can't <i>keep</i> [] 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.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">(5) Kim wrote:  </font><font face="arial, sans-serif" color="#0000ff">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.  </font><font face="arial, sans-serif">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 <i>only</i> when there is no good alternative.  </font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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 </font><span style="font-family:arial,sans-serif">variable arity method with the objects in your collection as the arguments?</span></div>
<div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">Right now, our only answer is to not do that, and to tell all library designers not to do </span><font face="arial, sans-serif">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.</font></div>
<div><br></div><div>(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.  </div>
<div><br></div><div>(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.</div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Enough for now.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">    Andrew</font></div>
<div><br></div></div>