Naming collection operations

[Rob Dickens-2]

but plus/minus will only be available in the immutable case, right?

2009/5/12 David MacIver <david.maciver@...>

2009/5/12 Rob Dickens <arctic.bob@...>:

> I thought + and plus WERE supposed to do the same thing. Ditto - and minus.
> Please could everyone make sure they've read (and fully understand) Martin's
> initial post.

You mean the bit where he said:

> To help users migrate, + and - will stay side-effecting on mutable collections for the time being but will be deprecated there.

and

> We need a good letter-based name for the purely functional version of these methods.

for example?

--
Rob, Lafros.com

[Rob Dickens-2]

> So the heart of the question is: are we interested in deprecating and replacing + and - ...

I agree: only go with plus/minus if we're going to keep +/-.

2009/5/12 Justin du coeur <jducoeur@...>

On Tue, May 12, 2009 at 5:54 AM, David MacIver <david.maciver@...> wrote:

Further, using + (or, equivalently, plus) for non commutative
operators is a horrible convention.

I can see that argument.  Mostly, I care about intuitive consistency here: my understanding was that we were looking for non-symbolic equivalents of + and -, but were leaving the symbolic versions *as well*.  (Am I correct here?)  That being the case, I strongly prefer "plus" and "minus", as the obvious verbal equivalents -- it matches the general Scala approach that guessing the answer tends to be right.  If we're willing to deprecate the symbols, though, that argument goes away.

So the heart of the question is: are we interested in deprecating and replacing + and - in cases where they don't match the mathematical formalisms?  If so, then choosing something entirely different for the verbal name makes sense.

We should keep in mind that this appears to matter a lot more to the mathematicians and formalists in the audience than to the down-and-dirty engineers -- honestly, it hadn't even occurred to me to care.  (I suspect that there's a strong correlation between this and whether folks come from functional vs. OO backgrounds, but that's just a guess.)  But given that the functional side of the audience does seem to care passionately, and I certainly don't, I'm willing to recant my opinion so long as we come up with some intuitively consistent approach...

--
Rob, Lafros.com

[Walter Chang]

+1 for incl/excl

On Tue, May 12, 2009 at 7:32 PM, Landei <Daniel.Gronau@...> wrote:

I'd vote for incl(uding)/excl(uding)

--
View this message in context: http://www.nabble.com/Naming-collection-operations-tp23478942p23500844.html

Sent from the Scala - Debate mailing list archive at Nabble.com.

--
.......__o
.......\<,
....( )/ ( )...

[Meredith Gregory]

All,

Fascinating discussion. It seriously reminds me of the raging debates i have hosted in the confines of my puny skull over similar naming options. So many trade-offs to explore. So little time.

Stepping back, i believe the conversation at hand suggests "names with structure" is a concept that has some weight and bearing on the issue. It really doesn't have to be left entirely to convention. There are good explorations of algebras for names that make sense, such as Milner's "naming" monoids or Carbone's paper on polyadic synchronization, or even Meredith and Radestock's paper on namespace logics ;-).

Less abstractly, take a look at the periodic table of the elements. The names for the elements are not the symbols. The names are the positions in the table. From these structured names one can predict types of interactions. Furthermore, the invention of the periodic table really marks the transition from alchemy to chemistry. When will programming language design make a similar transition?

Best wishes,

--greg

On Tue, May 12, 2009 at 8:03 AM, Walter Chang <weihsiu@...> wrote:

+1 for incl/excl

On Tue, May 12, 2009 at 7:32 PM, Landei <Daniel.Gronau@...> wrote:

I'd vote for incl(uding)/excl(uding)

--
View this message in context: http://www.nabble.com/Naming-collection-operations-tp23478942p23500844.html

Sent from the Scala - Debate mailing list archive at Nabble.com.

--
.......__o
.......\<,
....( )/ ( )...

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

[Seth Tisue]

>>>>> "Meredith" == Meredith Gregory <lgreg.meredith@...> writes:

 Meredith> Furthermore, the invention of the periodic table really marks
 Meredith> the transition from alchemy to chemistry. When will
 Meredith> programming language design make a similar transition?

Probably around the same time we all start speaking Esperanto.

--
Seth Tisue / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[mighdoll]

And if we need commutative replacements for +/-, perhaps:
    :->, makes a set fat and happy
and
    :-<, makes a set empty and bereft
jokes are not commutative, so the symbol works.

Weak humor aside, naming is important.  I like with/without. 

What's 'with' reserved for and can we unreserve it?

Lee

[Martin Odersky]

Oh my, what a heated reaction...

I see two strands in the discussion:

1) David McIver and others objecting to both + and plus
    as an operation meaning adding an element to a collection .
    I believe it's to late to change that. Virtually all Scala
    collection code uses +=, -=, +, -, ++, --, ++=, --=.
    In particular += and friends have much going for then,
    because they work for both mutable and immutable collections:

     var m: immutable.Set[String]
     m += "hi"

vs

     val m: mutable.Set[String]
     m += "hi"

 2) People objecting to plus/minus, because it's too close to +/-.
     Well, in my mind, that's the point. We do not want to invent
     a selection of different update names. We need the alternative
     only for callability from Java and as a way of transitioning
     to the new immutable semantcis of +/-.

So I still believe plus/minus is the most consistent choice, given the
circumstances.

Cheers

 -- Martin

[Erkki Lindpere-2]

n case this question is still open, my suggestion is

having/lacking

Erkki

martin odersky wrote:

> I have a question concerning an alternative naming for the + and -
> methods on sets and maps.
> We need a good letter-based name for the purely functional version of
> these methods. `with` and `withOut` would have worked except that
> `with` is a reserved word.
>
> There are basically two reasons why we need the alternate names. One
> is callability from Java. The other is that we are moving away from a
> design where + and - mean different things for different collections.
> Currently, they are side-effecting for mutable collections and create
> new ones for immutable collections. The idea is to use +=, -= for the
> side-effecting versions of + and -, and to reserve + and - for
> operations that always create a new collection. To help users migrate,
> + and - will stay side-effecting on mutable collections for the time
> being but will be deprecated there. The deprecation comment will say,
> if you want to keep the same meaning in the future, use +=,
> respectively -=, but if you really want a new collection, then use
> <insert name> here to make the deprecation warning go away.
>
> Therefore, one desiderata for the letter-based names is that they make
> it clear that a new collection is created and the old collection is
> left as it is. That's why I hesitate to use `add`, `remove`, for
> example.
>
> So, if you have a proposal, I'm interested!
>
> Thanks
>
>  -- Martin
>
>  

[David MacIver]

2009/5/12 martin odersky <martin.odersky@...>:
>  2) People objecting to plus/minus, because it's too close to +/-.
>     Well, in my mind, that's the point. We do not want to invent
>     a selection of different update names. We need the alternative
>     only for callability from Java and as a way of transitioning
>     to the new immutable semantcis of +/-.

In which case I wish to amend my stance to "Why bother having the
alphanumeric version at all?". Given the choice, I would never invoke
a method called plus instead of one called +. It doesn't make sense to
do so. When there's a valid mnemonic, it should be used.

If callability from Java is a reason, then surely this is a generic
problem and not specific to the collections API, which has a *lot* of
functionality that will be at best a pain to call from Java already
(certainly more of a pain than calling a method called plus$) - why in
particular is this one thing something we want to support?.

If the goal is to ease transitioning, I hardly think having "plus" and
"+" do markedly different things on mutable collections and requiring
ugly javaesque code (any API which requires me to write "plus" instead
of "+" gives me horrific java.math.BigInteger flashbacks) when you
want to abstract between mutable and immutable collections safely is
the right way to go about it. Scala's popularity is ever escalating:
There's going to be a lot of code written between 2.8 and 2.9. I'd
rather see the behaviour of existing code broken in a way that is easy
to fix than force all of that code to be written to a broken API.

If you want to make it an easy API breakage to catch, one option would
be to have something like a @warnUnused method annotation which causes
the compiler to warn if you don't use the result. These could be added
to the + methods on collections, causing existing mutable.collection
code to warn until it's fixed.

[Martin Odersky]

On Tue, May 12, 2009 at 8:28 PM, David MacIver <david.maciver@...> wrote:

> 2009/5/12 martin odersky <martin.odersky@...>:
>>  2) People objecting to plus/minus, because it's too close to +/-.
>>     Well, in my mind, that's the point. We do not want to invent
>>     a selection of different update names. We need the alternative
>>     only for callability from Java and as a way of transitioning
>>     to the new immutable semantcis of +/-.
>
> In which case I wish to amend my stance to "Why bother having the
> alphanumeric version at all?". Given the choice, I would never invoke
> a method called plus instead of one called +. It doesn't make sense to
> do so. When there's a valid mnemonic, it should be used.
>
> If callability from Java is a reason, then surely this is a generic
> problem and not specific to the collections API, which has a *lot* of
> functionality that will be at best a pain to call from Java already
> (certainly more of a pain than calling a method called plus$) - why in
> particular is this one thing something we want to support?.
>
> If the goal is to ease transitioning, I hardly think having "plus" and
> "+" do markedly different things on mutable collections and requiring
> ugly javaesque code (any API which requires me to write "plus" instead
> of "+" gives me horrific java.math.BigInteger flashbacks) when you
> want to abstract between mutable and immutable collections safely is
> the right way to go about it. Scala's popularity is ever escalating:
> There's going to be a lot of code written between 2.8 and 2.9. I'd
> rather see the behaviour of existing code broken in a way that is easy
> to fix than force all of that code to be written to a broken API.
>

I think that's all good points, David. In particular since the default
implementation of plus would be:

  def plus(elem: A) = clone() += elem

I think one could propose the clone() += scheme directly as a
replacement if users want to extend mutable collections with +, and do
not want a @deprecated warning.
So that means we would be better off with just +. If a mutable
collection can implement
a better version of persistent +, they could do that directly. For the moment,
the only likely candidate for this are bitsets, but since these have
changed anyway we do not have a backwards compatibility problem.

So, I'll drop any alternate names for +/-. Sorry to have taken
everyone on a wild gose chase!

 -- Martin

[David MacIver]

2009/5/13 martin odersky <martin.odersky@...>:

> On Tue, May 12, 2009 at 8:28 PM, David MacIver <david.maciver@...> wrote:
>> 2009/5/12 martin odersky <martin.odersky@...>:
>>>  2) People objecting to plus/minus, because it's too close to +/-.
>>>     Well, in my mind, that's the point. We do not want to invent
>>>     a selection of different update names. We need the alternative
>>>     only for callability from Java and as a way of transitioning
>>>     to the new immutable semantcis of +/-.
>>
>> In which case I wish to amend my stance to "Why bother having the
>> alphanumeric version at all?". Given the choice, I would never invoke
>> a method called plus instead of one called +. It doesn't make sense to
>> do so. When there's a valid mnemonic, it should be used.
>>
>> If callability from Java is a reason, then surely this is a generic
>> problem and not specific to the collections API, which has a *lot* of
>> functionality that will be at best a pain to call from Java already
>> (certainly more of a pain than calling a method called plus$) - why in
>> particular is this one thing something we want to support?.
>>
>> If the goal is to ease transitioning, I hardly think having "plus" and
>> "+" do markedly different things on mutable collections and requiring
>> ugly javaesque code (any API which requires me to write "plus" instead
>> of "+" gives me horrific java.math.BigInteger flashbacks) when you
>> want to abstract between mutable and immutable collections safely is
>> the right way to go about it. Scala's popularity is ever escalating:
>> There's going to be a lot of code written between 2.8 and 2.9. I'd
>> rather see the behaviour of existing code broken in a way that is easy
>> to fix than force all of that code to be written to a broken API.
>>
> I think that's all good points, David. In particular since the default
> implementation of plus would be:
>
>  def plus(elem: A) = clone() += elem
>
> I think one could propose the clone() += scheme directly as a
> replacement if users want to extend mutable collections with +, and do
> not want a @deprecated warning.
> So that means we would be better off with just +. If a mutable
> collection can implement
> a better version of persistent +, they could do that directly. For the moment,
> the only likely candidate for this are bitsets, but since these have
> changed anyway we do not have a backwards compatibility problem.
>
> So, I'll drop any alternate names for +/-. Sorry to have taken
> everyone on a wild gose chase!

Thanks, Martin. That sounds eminently reasonable. I'm still not super
happy with +/-, but I'll stop complaining. :-)

[Grey]

car and cdr of course.

coll car elem
coll cdr elem