Inconsistency of operators

On Sat, Dec 3, 2011 at 7:59 AM, Cay Horstmann wrote:
> 3) Is it really worth worrying about the difference between + and :+?

// This was List("a", "b") in 2.7, when List still had a + operator.
scala> List("a") + "b"
res0: java.lang.String = List(a)b

scala> List("a") :+ "b"
res1: List[java.lang.String] = List(a, b)

scala> Set("a") + "b"
res2: scala.collection.immutable.Set[java.lang.String] = Set(a, b)

scala> Set(1) + "b"
res3: java.lang.String = Set(1)b

There is more you can probably google up; + should be a last resort as
long as any2stringadd is with us.

See also https://issues.scala-lang.org/browse/SI-4059

> I realize it would be painful to eliminate :: for lists. So, I'd give
> up on :+, and I'd give up on the distinction between + and +:. What's
> left is
>
> + ++ :: ::: - -- += ++= =:: =::: -= --=
>
> That's 12 operators, one for each choice of
> - add/prepend/remove
> - one or many
> - mutate or not
>

That is a nice concise set

My gripe is with the operators to add and remove items. They are 17
operators + ++ :+ +: ++: :: ::: (for lists) | (for sets) += ++= +=:
++=: (for buffers) - -- &~ (for sets) -= --=

These are painful and do not contribute to readable code. I would suggest the following conventions.
+, -  -- obvious++, --  --takes a bit of learning, but obvious once one realizes they generalize + and - so that the rhs is a collection, not a single element.+=, -=, ++-, --=  --obvious generalizations of previous four operators.
...and anything else should be a named method ('cause it's not even _close_ to obvious).
Ken 

Yes, sorry, intended to mention :: as a special case.
Ken

Given Paul's observations on +, and your own on ::, I believe the only redundant operators here are | & for sets and ::: for lists. I think | and & are kind of obvious, at least for bitsets. Would be a shame to have them on single words treated as bitsets but not arbitrary ones. So, the only operator that I think we can easily do without is :::. And I'm happy to see it go (after a deprecation period).
Cheers
 -- Martin

On Sat, Dec 3, 2011 at 4:59 PM, Cay Horstmann <cay [dot] horstmann [at] gmail [dot] com> wrote:

On Fri, Dec 2, 2011 at 11:08 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
>
>
> Cay, thanks for the thoughtful suggestions!
>
> On Fri, Dec 2, 2011 at 7:55 PM, Cay Horstmann <cay [dot] horstmann [at] gmail [dot] com> wrote:
>>

>> And yes, the operators have gotten a bit out of hand in the collections library. I put them all into a table, and the result wasn't pretty. (The problem isn't the operators, but their inconsistency.) There is a lot to like about the collections library, but it's not perfect. Perhaps it needs to get redone one more time, or perhaps Scaladoc needs to be smarter about giving a more user-centric view.
>>
> Do you have suggestions regarding inconsistency of operators? Given a long enough deprecation cycle we could do changes if they are necessary. One other thing I thought of was merging the Traversable and Iterable layers if collections, because this would get rid of about 20% of the supertraits of standard collection classes.

My gripe is with the operators to add and remove items. They are 17
operators + ++ :+ +: ++: :: ::: (for lists) | (for sets) += ++= +=:
++=: (for buffers) - -- &~ (for sets) -= --=

1) Why have ::? You can use +:, of course, but not always--in
particular, not in pattern matching.
2) Why the set operators? Just use ++, --
3) Is it really worth worrying about the difference between + and :+?
I understand that + is supposed to be used for unordered collections,
and :+ for ordered collections. But then shouldn't we also use ++ for
unordered and :++ for ordered? And shouldn't we use :+= instead of +=
for buffers? I think it would be simpler to say "+ and ++ add, and the
addition is at the end for ordered collections".
4) The +: and = don't work well together. += means "add/mutate". :+=
means "prepend/mutate". +:= should mean "append/mutate", but we need
the colon to the right, so it must be +=:. Or =+:? The choice seems
arbitrary. With :: for prepend, there is only one natural choice, =::

I realize it would be painful to eliminate :: for lists. So, I'd give
up on :+, and I'd give up on the distinction between + and +:. What's
left is

+ ++ :: ::: - -- += ++= =:: =::: -= --=

That's 12 operators, one for each choice of
- add/prepend/remove
- one or many
- mutate or not

But if you love + vs :+ vs. +:, then the following 16 operators are a
consistent set:

+ ++ :+ :++ +: ++: - -- += ++= :+= :++= +=: ++=: -= --=

Cheers,

Cay

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

Hi,

I think ::: is actually quite nice and intuitive, and in place with :: and the general intuition of +/++, -/--.

What about removing /:, :\, /:\ instead? :-)

They are redundant, heavily criticized and not intuitive, compared to ::/:::.

A compromise would be to keep those three as @bridge methods, so nothing breaks while they can "slowly" disappear.

Bye,


Simon

Equally substantiated counter-argument: I like them ;-) (and several people I know, too)

One bit of support, though: the order of their “arguments” nicely matches the order of the arguments in the closure to be passed, which makes them really fast to parse visually if the closure is small. And that is where they shine, I tend to use the long names with multi-line closures.

Regards,

Roland

Am Samstag, 3. Dezember 2011 23:50:42 UTC+1 schrieb Simon Ochsenreither:

Hi,

I think ::: is actually quite nice and intuitive, and in place with :: and the general intuition of +/++, -/--.

What about removing /:, :\, /:\ instead? :-)

They are redundant, heavily criticized and not intuitive, compared to ::/:::.

A compromise would be to keep those three as @bridge methods, so nothing breaks while they can "slowly" disappear.

Bye,


Simon

On Sun, Dec 4, 2011 at 12:12 AM, rkuhn <google [at] rkuhn [dot] info> wrote:

Equally substantiated counter-argument: I like them ;-) (and several people I know, too)

One bit of support, though: the order of their “arguments” nicely matches the order of the arguments in the closure to be passed, which makes them really fast to parse visually if the closure is small. And that is where they shine, I tend to use the long names with multi-line closures.

Yes, except maybe /:\ takes a good thing too far. I see no advantage over fold here, except consistency with /: and :\ which are themselves tenuous. So I would have no problem seeing /:\ go.
Cheers
 -- Martin

Am Sonntag, 4. Dezember 2011 00:21:01 UTC+1 schrieb martin odersky:

On Sun, Dec 4, 2011 at 12:12 AM, rkuhn <goo [dot] [dot] [dot] [at] rkuhn [dot] info> wrote:

Equally substantiated counter-argument: I like them ;-) (and several people I know, too)

One bit of support, though: the order of their “arguments” nicely matches the order of the arguments in the closure to be passed, which makes them really fast to parse visually if the closure is small. And that is where they shine, I tend to use the long names with multi-line closures.

Yes, except maybe /:\ takes a good thing too far. I see no advantage over fold here, except consistency with /: and :\ which are themselves tenuous. So I would have no problem seeing /:\ go.

Yes, I always forget about /:\ since I have never used it.

Regards,

Roland

Le 03/12/2011 20:46, Kenneth McDonald a écrit :
{...}
>
> +, - -- obvious
> ++, -- --takes a bit of learning, but obvious once one realizes they
> generalize + and - so that the rhs is a collection, not a single element.
> +=, -=, ++-, --= --obvious generalizations of previous four operators.
>
> ...and anything else should be a named method ('cause it's not even
> _close_ to obvious).

Depend of your background. "::" (cons) is obvious for lots of people,
and for my personal use case, pattern matching on lists with anything
else but "::" would seem alien.

And as said by Paul, on the JVM, "+" is a string concatenation, even at
unexpected times.

Thanks,

Here's a possible scaladoc trick: Maybe we should list symbolic
operators at the end of the method table rather than at the beginning?
That way newcomers to Scala do not see a welcome screen of what must
look like gobbledygook to them when they go to the scaladoc of, say,
List.

Cheers

Am Sonntag, 4. Dezember 2011, 09:22:19 schrieb martin odersky:
> Here's a possible scaladoc trick: Maybe we should list symbolic
> operators at the end of the method table rather than at the beginning?
> That way newcomers to Scala do not see a welcome screen of what must
> look like gobbledygook to them when they go to the scaladoc of, say,
> List.
>
> Cheers
>

Am Sonntag, 4. Dezember 2011 09:22:19 UTC+1 schrieb martin odersky:

Here's a possible scaladoc trick: Maybe we should list symbolic
operators at the end of the method table rather than at the beginning?
That way newcomers to Scala do not see a welcome screen of what must
look like gobbledygook to them when they go to the scaladoc of, say,
List.

Cheers

Yes, that sounds like a very good idea to me. That way, they would appear directly above those methods only available via implicits (i.e. those which are in scope by default from Predef or companions), once that feature is implemented ;-)

BTW: is there a flag or something for listing abstract methods together with concrete ones? If a user API is an abstract class which has both, it currently looks a bit confusing.

Regards,

Roland
 

One could also attempt to incorporate http://scalex.org/ into docs / learning resources. 
I was already planning integrating it into the search on docs.scala-lang.org. 
With something like that more public, a newcomer could just "scoogle" for the symbolic operator.
Cheers, Heather


On Dec 4, 2011, at 10:41 AM, Bernd Johannes wrote:

Am Sonntag, 4. Dezember 2011, 09:22:19 schrieb martin odersky:

Here's a possible scaladoc trick: Maybe we should list symbolic

operators at the end of the method table rather than at the beginning?

That way newcomers to Scala do not see a welcome screen of what must

look like gobbledygook to them when they go to the scaladoc of, say,

List.

Cheers

-- Martin

When done consistently this could certainly delay the eeeek-effect of scaladoc
pages.

But newcomers will hit the symbolic names anyway because of other resources
(examples, blogs and so on). So I still think it would be a good thing to
provide a mechanism which can carry readable/explanatory names for symbolic
names that an IDE (Eclipse) could pick up and display as bubble help.

I would even go as far as to recommend that those explanatory aliases should
be included in the binary form (annotations?) so that this IDE trick would
even work for jars without documentation.

Maybe I'm wrong but I think this could ease the "scala looks just like perl
line noise" argument.

Just my 2 cents
Bernd

Good trick. 
Like /: and foldLeft -- symbolic operators with non-symbolic aliases -- is there transitional value for newer and previously non-functional Scala users having non-symbolic aliases for all symbolic operators? If so, even more obvious cross referencing in the scaladoc would be helpful.
Thanks,Jon

On Sun, Dec 4, 2011 at 3:22 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

Here's a possible scaladoc trick: Maybe we should list symbolic
operators at the end of the method table rather than at the beginning?
That way newcomers to Scala do not see a welcome screen of what must
look like gobbledygook to them when they go to the scaladoc of, say,
List.

Cheers

Oh great, another inconsistency.

List("a") + "b" // + is concatenation
Set("a") + "b" // + is insertion

You convinced me that it was a mistake to overload + for insertion
into a collection.

So, a better way would be to use ++ for adding one element, +++ for
adding in bulk. It's actually nicely consistent with :: and :::

That gives a list of the following twelve:

++ +++ :: ::: -- --- ++= +++= =:: =::: --= ---=

No, I do not know a way from where we are to this Utopian ideal.

On Sat, Dec 3, 2011 at 11:37 AM, Paul Phillips wrote:
> On Sat, Dec 3, 2011 at 7:59 AM, Cay Horstmann wrote:
>> 3) Is it really worth worrying about the difference between + and :+?
>
> // This was List("a", "b") in 2.7, when List still had a + operator.
> scala> List("a") + "b"
> res0: java.lang.String = List(a)b
>
> scala> List("a") :+ "b"
> res1: List[java.lang.String] = List(a, b)
>
> scala> Set("a") + "b"
> res2: scala.collection.immutable.Set[java.lang.String] = Set(a, b)
>
> scala> Set(1) + "b"
> res3: java.lang.String = Set(1)b
>
> There is more you can probably google up; + should be a last resort as
> long as any2stringadd is with us.
>
> See also https://issues.scala-lang.org/browse/SI-4059

Might be redundant and confusing.

On 4 dec, 17:12, Cay Horstmann wrote:
> Oh great, another inconsistency.
>
> List("a") + "b" // + is concatenation
> Set("a") + "b" // + is insertion
>
> You convinced me that it was a mistake to overload + for insertion
> into a collection.
>
> So, a better way would be to use ++ for adding one element, +++ for
> adding in bulk. It's actually nicely consistent with :: and :::
>
> That gives a list of the following twelve:
>
> ++ +++ :: ::: -- --- ++= +++= =:: =::: --= ---=
>
> No, I do not know a way from where we are to this Utopian ideal.
>
>
>
> On Sat, Dec 3, 2011 at 11:37 AM, Paul Phillips wrote:
> > On Sat, Dec 3, 2011 at 7:59 AM, Cay Horstmann wrote:
> >> 3) Is it really worth worrying about the difference between + and :+?
>
> > // This was List("a", "b") in 2.7, when List still had a + operator.
> > scala> List("a") + "b"
> > res0: java.lang.String = List(a)b
>
> > scala> List("a") :+ "b"
> > res1: List[java.lang.String] = List(a, b)
>
> > scala> Set("a") + "b"
> > res2: scala.collection.immutable.Set[java.lang.String] = Set(a, b)
>
> > scala> Set(1) + "b"
> > res3: java.lang.String = Set(1)b
>
> > There is more you can probably google up; + should be a last resort as
> > long as any2stringadd is with us.
>
> > See alsohttps://issues.scala-lang.org/browse/SI-4059- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

Huh?  They're wrappers for Stream.cons.
  --Rex

On Sun, Dec 4, 2011 at 11:48 AM, Dave <dave [dot] mahabiersing [at] hotmail [dot] com> wrote:

#:: and #::: for streams are only wrappers for :: and :::
Might be redundant and confusing.

On Sun, Dec 4, 2011 at 9:12 AM, Cay Horstmann <cay [dot] horstmann [at] gmail [dot] com> wrote:

Oh great, another inconsistency.

List("a") + "b" // + is concatenation
Set("a") + "b" // + is insertion

You convinced me that it was a mistake to overload + for insertion
into a collection.

So, a better way would be to use ++ for adding one element, +++ for
adding in bulk. It's actually nicely consistent with :: and :::

Why not :+ and :++? Then for symmetry you can have +: and ++: to prepend. Oh wait, that's looking almost kinda familiar ;)
--
Derek Williams

As one who spends time educating new Scala users, I would emphatically say yes to your question. Based on my experiences I think the incredible array of operators is serious barrier to Scala adoption. Its very frustrating to watch people trying to learn all of Scala's wonderful new tools unnecessarily struggle with the alien syntax. I struggle to see the benefit of *many* of the operator forms of Scala functionality outweighing the goal of larger-scale Scala adoption.

If this were all up to me I'd use only the most basic +, -, = operators (and their combinations) and save all the other forms until Scala 3 or 4, sometime *after* Scala is the clearer winner of the JVM language wars (in terms of replacing Java).

ARKBAN

On 12/04/2011 11:08 AM, Jon Steelman wrote:

rOWP5dQdY_8v-3zeJRP+yLQymg [at] mail [dot] gmail [dot] com" type="cite">Good trick. 
Like /: and foldLeft -- symbolic operators with non-symbolic aliases -- is there transitional value for newer and previously non-functional Scala users having non-symbolic aliases for all symbolic operators? If so, even more obvious cross referencing in the scaladoc would be helpful.
Thanks, Jon

On Sun, Dec 4, 2011 at 3:22 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch" rel="nofollow">martin [dot] odersky [at] epfl [dot] ch> wrote:

Here's a possible scaladoc trick: Maybe we should list symbolic
operators at the end of the method table rather than at the beginning?
That way newcomers to Scala do not see a welcome screen of what must
look like gobbledygook to them when they go to the scaladoc of, say,
List.

Cheers

 -- Martin

I didn't say "redundant". I said "inconsistent".

If you want to make the set of operators consistent, you have to work
harder than just deprecating :::.

Again, I am only talking about the operators for adding and removing
from a collection. I have no beef with /: and :\. And I'll not talk
any more about the set operations.

If consistency is the goal, decide between :: and +:. Let's say the
choice is ::.

As Paul points out, + for insertion is a non-starter. There is no harm
in using :+ for sets.

Let's say we keep - for removal.

For bulk operations:

:++ ::: --

For mutation:

:+= :++= -= --= =:: =:::

That's a set of twelve consistent operators. I can explain it with three rules:

1) Prepend is ::, Add/append is :+, Remove is -
2) For bulk operations, one doubles the last character
3) The = goes to the right for left-associative operators and to the
left for right-associative ones.

It's not beautiful, but it has a few advantages over the operators
that we have now.

+ ++ :+ +: ++: - -- += ++= :+= +=: ++=: -= --= :: :::

Here are the best rules I could come up with for describing them:

1) :+ appends, +: prepends, and + is used for unordered collections. - removes.
2) For bulk operations, use ++ to append, ++: to prepend. Little minds
might think it should be :++ to append, but you should realize that :+
was chosen because + is ambiguous with string concatenation. (For sets
we live with the ambiguity. Don't ask.) With ++, there is no such
ambiguity, so the unsightly colon is dropped.
3) The = goes on the right for left-associative operators, but for :+,
the mutation is +=. Remember, the rule is that we drop the colon when
we can. (By the way, be sure not to get confused about :+= which is
synthesized from :+ and only works with for vars.)
4) For right-associative operators, insert the = before the colon: +:
turns into +=: and ++: into ++=:. This may seem an odd place to insert
the =, but think about it this way: The : on the right turns around
whatever you apply it to, so += is turned around to +=: and ++= is
turned around to ++=:. Just like ++: is the turned-around ++. And +:
is a turned-around +, erm, actually :+, because, remember, + is
ambiguous with string concatenation.
5) :: and ::: are a special case for lists.

Cheers,

Cay

On Sat, Dec 3, 2011 at 1:43 PM, martin odersky wrote:
> Given Paul's observations on +, and your own on ::, I believe the only
> redundant operators here are | & for sets and ::: for lists. I think | and &
> are kind of obvious, at least for bitsets. Would be a shame to have them on
> single words treated as bitsets but not arbitrary ones. So, the only
> operator that I think we can easily do without is :::. And I'm happy to see
> it go (after a deprecation period).
>
> Cheers
>
>  -- Martin
>
>
> On Sat, Dec 3, 2011 at 4:59 PM, Cay Horstmann
> wrote:
>>
>> On Fri, Dec 2, 2011 at 11:08 AM, martin odersky
>> wrote:
>> >
>> >
>> > Cay, thanks for the thoughtful suggestions!
>> >
>> > On Fri, Dec 2, 2011 at 7:55 PM, Cay Horstmann
>> > wrote:
>> >>
>>
>> >> And yes, the operators have gotten a bit out of hand in the collections
>> >> library. I put them all into a table, and the result wasn't pretty. (The
>> >> problem isn't the operators, but their inconsistency.) There is a lot to
>> >> like about the collections library, but it's not perfect. Perhaps it needs
>> >> to get redone one more time, or perhaps Scaladoc needs to be smarter about
>> >> giving a more user-centric view.
>> >>
>> > Do you have suggestions regarding inconsistency of operators? Given a
>> > long enough deprecation cycle we could do changes if they are necessary. One
>> > other thing I thought of was merging the Traversable and Iterable layers if
>> > collections, because this would get rid of about 20% of the supertraits of
>> > standard collection classes.
>>
>> My gripe is with the operators to add and remove items. They are 17
>> operators + ++ :+ +: ++: :: ::: (for lists) | (for sets) += ++= +=:
>> ++=: (for buffers) - -- &~ (for sets) -= --=
>>
>> 1) Why have ::? You can use +:, of course, but not always--in
>> particular, not in pattern matching.
>> 2) Why the set operators? Just use ++, --
>> 3) Is it really worth worrying about the difference between + and :+?
>> I understand that + is supposed to be used for unordered collections,
>> and :+ for ordered collections. But then shouldn't we also use ++ for
>> unordered and :++ for ordered? And shouldn't we use :+= instead of +=
>> for buffers? I think it would be simpler to say "+ and ++ add, and the
>> addition is at the end for ordered collections".
>> 4) The +: and = don't work well together. += means "add/mutate". :+=
>> means "prepend/mutate". +:= should mean "append/mutate", but we need
>> the colon to the right, so it must be +=:. Or =+:? The choice seems
>> arbitrary. With :: for prepend, there is only one natural choice, =::
>>
>> I realize it would be painful to eliminate :: for lists. So, I'd give
>> up on :+, and I'd give up on the distinction between + and +:. What's
>> left is
>>
>> + ++ :: ::: - -- += ++= =:: =::: -= --=
>>
>> That's 12 operators, one for each choice of
>> - add/prepend/remove
>> - one or many
>> - mutate or not
>>
>> But if you love + vs :+ vs. +:, then the following 16 operators are a
>> consistent set:
>>
>> + ++ :+ :++ +: ++: - -- += ++= :+= :++= +=: ++=: -= --=
>>
>> Cheers,
>>
>> Cay
>
>
>
>
> --
> Martin Odersky
> Prof., EPFL and Chairman, Typesafe
> PSED, 1015 Lausanne, Switzerland
> Tel. EPFL: +41 21 693 6863
> Tel. Typesafe: +41 21 691 4967
>

If consistency is the goal and :+ is append I would say that :- is better than just -

BR,
John

Den 4 dec 2011 19:14 skrev "Cay Horstmann" <cay [dot] horstmann [at] gmail [dot] com>:

I didn't say "redundant". I said "inconsistent".

If you want to make the set of operators consistent, you have to work
harder than just deprecating :::.

Again, I am only talking about the operators for adding and removing
from a collection. I have no beef with /: and :\. And I'll not talk
any more about the set operations.

If consistency is the goal, decide between :: and +:. Let's say the
choice is ::.

As Paul points out, + for insertion is a non-starter. There is no harm
in using :+ for sets.

Let's say we keep - for removal.

For bulk operations:

:++ ::: --

For mutation:

:+= :++= -= --= =:: =:::

That's a set of twelve consistent operators. I can explain it with three rules:

1) Prepend is ::, Add/append is :+, Remove is -
2) For bulk operations, one doubles the last character
3) The = goes to the right for left-associative operators and to the
left for right-associative ones.

It's not beautiful, but it has a few advantages over the operators
that we have now.

+ ++ :+ +: ++: - -- += ++= :+= +=: ++=: -= --= :: :::

Here are the best rules I could come up with for describing them:

1) :+ appends, +: prepends, and + is used for unordered collections. - removes.
2) For bulk operations, use ++ to append, ++: to prepend. Little minds
might think it should be :++ to append, but you should realize that :+
was chosen because + is ambiguous with string concatenation. (For sets
we live with the ambiguity. Don't ask.) With ++, there is no such
ambiguity, so the unsightly colon is dropped.
3) The = goes on the right for left-associative operators, but for :+,
the mutation is +=. Remember, the rule is that we drop the colon when
we can. (By the way, be sure not to get confused about :+= which is
synthesized from :+ and only works with for vars.)
4) For right-associative operators, insert the = before the colon: +:
turns into +=: and ++: into ++=:. This may seem an odd place to insert
the =, but think about it this way: The : on the right turns around
whatever you apply it to, so += is turned around to +=: and ++= is
turned around to ++=:. Just like ++: is the turned-around ++. And +:
is a turned-around +, erm, actually :+, because, remember, + is
ambiguous with string concatenation.
5)  :: and ::: are a special case for lists.

Cheers,

Cay

On Sat, Dec 3, 2011 at 1:43 PM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
> Given Paul's observations on +, and your own on ::, I believe the only
> redundant operators here are | & for sets and ::: for lists. I think | and &
> are kind of obvious, at least for bitsets. Would be a shame to have them on
> single words treated as bitsets but not arbitrary ones. So, the only
> operator that I think we can easily do without is :::. And I'm happy to see
> it go (after a deprecation period).
>
> Cheers
>
>  -- Martin
>
>
> On Sat, Dec 3, 2011 at 4:59 PM, Cay Horstmann <cay [dot] horstmann [at] gmail [dot] com>
> wrote:
>>
>> On Fri, Dec 2, 2011 at 11:08 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch>
>> wrote:
>> >
>> >
>> > Cay, thanks for the thoughtful suggestions!
>> >
>> > On Fri, Dec 2, 2011 at 7:55 PM, Cay Horstmann <cay [dot] horstmann [at] gmail [dot] com>
>> > wrote:
>> >>
>>
>> >> And yes, the operators have gotten a bit out of hand in the collections
>> >> library. I put them all into a table, and the result wasn't pretty. (The
>> >> problem isn't the operators, but their inconsistency.) There is a lot to
>> >> like about the collections library, but it's not perfect. Perhaps it needs
>> >> to get redone one more time, or perhaps Scaladoc needs to be smarter about
>> >> giving a more user-centric view.
>> >>
>> > Do you have suggestions regarding inconsistency of operators? Given a
>> > long enough deprecation cycle we could do changes if they are necessary. One
>> > other thing I thought of was merging the Traversable and Iterable layers if
>> > collections, because this would get rid of about 20% of the supertraits of
>> > standard collection classes.
>>
>> My gripe is with the operators to add and remove items. They are 17
>> operators + ++ :+ +: ++: :: ::: (for lists) | (for sets) += ++= +=:
>> ++=: (for buffers) - -- &~ (for sets) -= --=
>>
>> 1) Why have ::? You can use +:, of course, but not always--in
>> particular, not in pattern matching.
>> 2) Why the set operators? Just use ++, --
>> 3) Is it really worth worrying about the difference between + and :+?
>> I understand that + is supposed to be used for unordered collections,
>> and :+ for ordered collections. But then shouldn't we also use ++ for
>> unordered and :++ for ordered? And shouldn't we use :+= instead of +=
>> for buffers? I think it would be simpler to say "+ and ++ add, and the
>> addition is at the end for ordered collections".
>> 4) The +: and = don't work well together. += means "add/mutate". :+=
>> means "prepend/mutate". +:= should mean "append/mutate", but we need
>> the colon to the right, so it must be +=:. Or =+:? The choice seems
>> arbitrary. With :: for prepend, there is only one natural choice, =::
>>
>> I realize it would be painful to eliminate :: for lists. So, I'd give
>> up on :+, and I'd give up on the distinction between + and +:. What's
>> left is
>>
>> + ++ :: ::: - -- += ++= =:: =::: -= --=
>>
>> That's 12 operators, one for each choice of
>> - add/prepend/remove
>> - one or many
>> - mutate or not
>>
>> But if you love + vs :+ vs. +:, then the following 16 operators are a
>> consistent set:
>>
>> + ++ :+ :++ +: ++: - -- += ++= :+= :++= +=: ++=: -= --=
>>
>> Cheers,
>>
>> Cay
>
>
>
>
> --
> Martin Odersky
> Prof., EPFL and Chairman, Typesafe
> PSED, 1015 Lausanne, Switzerland
> Tel. EPFL: +41 21 693 6863
> Tel. Typesafe: +41 21 691 4967
>

Why ":-" and not "-:" ? ":" would denote pre- or post- but removing
doesn't happen at one end of a collection. "-" sounds like a reasonable
choice to me.

Paul

On Sun, Dec 4, 2011 at 20:07, John Nilsson wrote:
> If consistency is the goal and :+ is append I would say that :- is better
> than just -
>
> BR,
> John
>
> Den 4 dec 2011 19:14 skrev "Cay Horstmann" :
>
>> I didn't say "redundant". I said "inconsistent".
>>
>> If you want to make the set of operators consistent, you have to work
>> harder than just deprecating :::.
>>
>> Again, I am only talking about the operators for adding and removing
>> from a collection. I have no beef with /: and :\. And I'll not talk
>> any more about the set operations.
>>
>> If consistency is the goal, decide between :: and +:. Let's say the
>> choice is ::.
>>
>> As Paul points out, + for insertion is a non-starter. There is no harm
>> in using :+ for sets.
>>
>> Let's say we keep - for removal.
>>
>> For bulk operations:
>>
>> :++ ::: --
>>
>> For mutation:
>>
>> :+= :++= -= --= =:: =:::
>>
>> That's a set of twelve consistent operators. I can explain it with three
>> rules:
>>
>> 1) Prepend is ::, Add/append is :+, Remove is -
>> 2) For bulk operations, one doubles the last character
>> 3) The = goes to the right for left-associative operators and to the
>> left for right-associative ones.
>>
>> It's not beautiful, but it has a few advantages over the operators
>> that we have now.
>>
>> + ++ :+ +: ++: - -- += ++= :+= +=: ++=: -= --= :: :::
>>
>> Here are the best rules I could come up with for describing them:
>>
>> 1) :+ appends, +: prepends, and + is used for unordered collections. -
>> removes.
>> 2) For bulk operations, use ++ to append, ++: to prepend. Little minds
>> might think it should be :++ to append, but you should realize that :+
>> was chosen because + is ambiguous with string concatenation. (For sets
>> we live with the ambiguity. Don't ask.) With ++, there is no such
>> ambiguity, so the unsightly colon is dropped.
>> 3) The = goes on the right for left-associative operators, but for :+,
>> the mutation is +=. Remember, the rule is that we drop the colon when
>> we can. (By the way, be sure not to get confused about :+= which is
>> synthesized from :+ and only works with for vars.)
>> 4) For right-associative operators, insert the = before the colon: +:
>> turns into +=: and ++: into ++=:. This may seem an odd place to insert
>> the =, but think about it this way: The : on the right turns around
>> whatever you apply it to, so += is turned around to +=: and ++= is
>> turned around to ++=:. Just like ++: is the turned-around ++. And +:
>> is a turned-around +, erm, actually :+, because, remember, + is
>> ambiguous with string concatenation.
>> 5)  :: and ::: are a special case for lists.
>>
>> Cheers,
>>
>> Cay
>>
>> On Sat, Dec 3, 2011 at 1:43 PM, martin odersky
>> wrote:
>> > Given Paul's observations on +, and your own on ::, I believe the only
>> > redundant operators here are | & for sets and ::: for lists. I think |
>> > and &
>> > are kind of obvious, at least for bitsets. Would be a shame to have them
>> > on
>> > single words treated as bitsets but not arbitrary ones. So, the only
>> > operator that I think we can easily do without is :::. And I'm happy to
>> > see
>> > it go (after a deprecation period).
>> >
>> > Cheers
>> >
>> >  -- Martin
>> >
>> >
>> > On Sat, Dec 3, 2011 at 4:59 PM, Cay Horstmann
>> > wrote:
>> >>
>> >> On Fri, Dec 2, 2011 at 11:08 AM, martin odersky
>> >>
>> >> wrote:
>> >> >
>> >> >
>> >> > Cay, thanks for the thoughtful suggestions!
>> >> >
>> >> > On Fri, Dec 2, 2011 at 7:55 PM, Cay Horstmann
>> >> >
>> >> > wrote:
>> >> >>
>> >>
>> >> >> And yes, the operators have gotten a bit out of hand in the
>> >> >> collections
>> >> >> library. I put them all into a table, and the result wasn't pretty.
>> >> >> (The
>> >> >> problem isn't the operators, but their inconsistency.) There is a
>> >> >> lot to
>> >> >> like about the collections library, but it's not perfect. Perhaps it
>> >> >> needs
>> >> >> to get redone one more time, or perhaps Scaladoc needs to be smarter
>> >> >> about
>> >> >> giving a more user-centric view.
>> >> >>
>> >> > Do you have suggestions regarding inconsistency of operators? Given a
>> >> > long enough deprecation cycle we could do changes if they are
>> >> > necessary. One
>> >> > other thing I thought of was merging the Traversable and Iterable
>> >> > layers if
>> >> > collections, because this would get rid of about 20% of the
>> >> > supertraits of
>> >> > standard collection classes.
>> >>
>> >> My gripe is with the operators to add and remove items. They are 17
>> >> operators + ++ :+ +: ++: :: ::: (for lists) | (for sets) += ++= +=:
>> >> ++=: (for buffers) - -- &~ (for sets) -= --=
>> >>
>> >> 1) Why have ::? You can use +:, of course, but not always--in
>> >> particular, not in pattern matching.
>> >> 2) Why the set operators? Just use ++, --
>> >> 3) Is it really worth worrying about the difference between + and :+?
>> >> I understand that + is supposed to be used for unordered collections,
>> >> and :+ for ordered collections. But then shouldn't we also use ++ for
>> >> unordered and :++ for ordered? And shouldn't we use :+= instead of +=
>> >> for buffers? I think it would be simpler to say "+ and ++ add, and the
>> >> addition is at the end for ordered collections".
>> >> 4) The +: and = don't work well together. += means "add/mutate". :+=
>> >> means "prepend/mutate". +:= should mean "append/mutate", but we need
>> >> the colon to the right, so it must be +=:. Or =+:? The choice seems
>> >> arbitrary. With :: for prepend, there is only one natural choice, =::
>> >>
>> >> I realize it would be painful to eliminate :: for lists. So, I'd give
>> >> up on :+, and I'd give up on the distinction between + and +:. What's
>> >> left is
>> >>
>> >> + ++ :: ::: - -- += ++= =:: =::: -= --=
>> >>
>> >> That's 12 operators, one for each choice of
>> >> - add/prepend/remove
>> >> - one or many
>> >> - mutate or not
>> >>
>> >> But if you love + vs :+ vs. +:, then the following 16 operators are a
>> >> consistent set:
>> >>
>> >> + ++ :+ :++ +: ++: - -- += ++= :+= :++= +=: ++=: -= --=
>> >>
>> >> Cheers,
>> >>
>> >> Cay
>> >
>> >
>> >
>> >
>> > --
>> > Martin Odersky
>> > Prof., EPFL and Chairman, Typesafe
>> > PSED, 1015 Lausanne, Switzerland
>> > Tel. EPFL: +41 21 693 6863
>> > Tel. Typesafe: +41 21 691 4967
>> >

True. I didn't think it through.

BR,
John

Den 4 dec 2011 20:11 skrev "Paul Brauner" <polux2001 [at] gmail [dot] com>:

Why ":-" and not "-:" ? ":" would denote pre- or post- but removing
doesn't happen at one end of a collection. "-" sounds like a reasonable
choice to me.

Paul

On Sun, Dec 4, 2011 at 20:07, John Nilsson <john [at] milsson [dot] nu> wrote:
> If consistency is the goal and :+ is append I would say that :- is better
> than just -
>
> BR,
> John
>
> Den 4 dec 2011 19:14 skrev "Cay Horstmann" <cay [dot] horstmann [at] gmail [dot] com>:
>
>> I didn't say "redundant". I said "inconsistent".
>>
>> If you want to make the set of operators consistent, you have to work
>> harder than just deprecating :::.
>>
>> Again, I am only talking about the operators for adding and removing
>> from a collection. I have no beef with /: and :\. And I'll not talk
>> any more about the set operations.
>>
>> If consistency is the goal, decide between :: and +:. Let's say the
>> choice is ::.
>>
>> As Paul points out, + for insertion is a non-starter. There is no harm
>> in using :+ for sets.
>>
>> Let's say we keep - for removal.
>>
>> For bulk operations:
>>
>> :++ ::: --
>>
>> For mutation:
>>
>> :+= :++= -= --= =:: =:::
>>
>> That's a set of twelve consistent operators. I can explain it with three
>> rules:
>>
>> 1) Prepend is ::, Add/append is :+, Remove is -
>> 2) For bulk operations, one doubles the last character
>> 3) The = goes to the right for left-associative operators and to the
>> left for right-associative ones.
>>
>> It's not beautiful, but it has a few advantages over the operators
>> that we have now.
>>
>> + ++ :+ +: ++: - -- += ++= :+= +=: ++=: -= --= :: :::
>>
>> Here are the best rules I could come up with for describing them:
>>
>> 1) :+ appends, +: prepends, and + is used for unordered collections. -
>> removes.
>> 2) For bulk operations, use ++ to append, ++: to prepend. Little minds
>> might think it should be :++ to append, but you should realize that :+
>> was chosen because + is ambiguous with string concatenation. (For sets
>> we live with the ambiguity. Don't ask.) With ++, there is no such
>> ambiguity, so the unsightly colon is dropped.
>> 3) The = goes on the right for left-associative operators, but for :+,
>> the mutation is +=. Remember, the rule is that we drop the colon when
>> we can. (By the way, be sure not to get confused about :+= which is
>> synthesized from :+ and only works with for vars.)
>> 4) For right-associative operators, insert the = before the colon: +:
>> turns into +=: and ++: into ++=:. This may seem an odd place to insert
>> the =, but think about it this way: The : on the right turns around
>> whatever you apply it to, so += is turned around to +=: and ++= is
>> turned around to ++=:. Just like ++: is the turned-around ++. And +:
>> is a turned-around +, erm, actually :+, because, remember, + is
>> ambiguous with string concatenation.
>> 5)  :: and ::: are a special case for lists.
>>
>> Cheers,
>>
>> Cay
>>
>> On Sat, Dec 3, 2011 at 1:43 PM, martin odersky <martin [dot] odersky [at] epfl [dot] ch>
>> wrote:
>> > Given Paul's observations on +, and your own on ::, I believe the only
>> > redundant operators here are | & for sets and ::: for lists. I think |
>> > and &
>> > are kind of obvious, at least for bitsets. Would be a shame to have them
>> > on
>> > single words treated as bitsets but not arbitrary ones. So, the only
>> > operator that I think we can easily do without is :::. And I'm happy to
>> > see
>> > it go (after a deprecation period).
>> >
>> > Cheers
>> >
>> >  -- Martin
>> >
>> >
>> > On Sat, Dec 3, 2011 at 4:59 PM, Cay Horstmann <cay [dot] horstmann [at] gmail [dot] com>
>> > wrote:
>> >>
>> >> On Fri, Dec 2, 2011 at 11:08 AM, martin odersky
>> >> <martin [dot] odersky [at] epfl [dot] ch>
>> >> wrote:
>> >> >
>> >> >
>> >> > Cay, thanks for the thoughtful suggestions!
>> >> >
>> >> > On Fri, Dec 2, 2011 at 7:55 PM, Cay Horstmann
>> >> > <cay [dot] horstmann [at] gmail [dot] com>
>> >> > wrote:
>> >> >>
>> >>
>> >> >> And yes, the operators have gotten a bit out of hand in the
>> >> >> collections
>> >> >> library. I put them all into a table, and the result wasn't pretty.
>> >> >> (The
>> >> >> problem isn't the operators, but their inconsistency.) There is a
>> >> >> lot to
>> >> >> like about the collections library, but it's not perfect. Perhaps it
>> >> >> needs
>> >> >> to get redone one more time, or perhaps Scaladoc needs to be smarter
>> >> >> about
>> >> >> giving a more user-centric view.
>> >> >>
>> >> > Do you have suggestions regarding inconsistency of operators? Given a
>> >> > long enough deprecation cycle we could do changes if they are
>> >> > necessary. One
>> >> > other thing I thought of was merging the Traversable and Iterable
>> >> > layers if
>> >> > collections, because this would get rid of about 20% of the
>> >> > supertraits of
>> >> > standard collection classes.
>> >>
>> >> My gripe is with the operators to add and remove items. They are 17
>> >> operators + ++ :+ +: ++: :: ::: (for lists) | (for sets) += ++= +=:
>> >> ++=: (for buffers) - -- &~ (for sets) -= --=
>> >>
>> >> 1) Why have ::? You can use +:, of course, but not always--in
>> >> particular, not in pattern matching.
>> >> 2) Why the set operators? Just use ++, --
>> >> 3) Is it really worth worrying about the difference between + and :+?
>> >> I understand that + is supposed to be used for unordered collections,
>> >> and :+ for ordered collections. But then shouldn't we also use ++ for
>> >> unordered and :++ for ordered? And shouldn't we use :+= instead of +=
>> >> for buffers? I think it would be simpler to say "+ and ++ add, and the
>> >> addition is at the end for ordered collections".
>> >> 4) The +: and = don't work well together. += means "add/mutate". :+=
>> >> means "prepend/mutate". +:= should mean "append/mutate", but we need
>> >> the colon to the right, so it must be +=:. Or =+:? The choice seems
>> >> arbitrary. With :: for prepend, there is only one natural choice, =::
>> >>
>> >> I realize it would be painful to eliminate :: for lists. So, I'd give
>> >> up on :+, and I'd give up on the distinction between + and +:. What's
>> >> left is
>> >>
>> >> + ++ :: ::: - -- += ++= =:: =::: -= --=
>> >>
>> >> That's 12 operators, one for each choice of
>> >> - add/prepend/remove
>> >> - one or many
>> >> - mutate or not
>> >>
>> >> But if you love + vs :+ vs. +:, then the following 16 operators are a
>> >> consistent set:
>> >>
>> >> + ++ :+ :++ +: ++: - -- += ++= :+= :++= +=: ++=: -= --=
>> >>
>> >> Cheers,
>> >>
>> >> Cay
>> >
>> >
>> >
>> >
>> > --
>> > Martin Odersky
>> > Prof., EPFL and Chairman, Typesafe
>> > PSED, 1015 Lausanne, Switzerland
>> > Tel. EPFL: +41 21 693 6863
>> > Tel. Typesafe: +41 21 691 4967
>> >

+1. Good idea, imho.

ascii, then symbols, then deprecated.

On Sat, Dec 3, 2011 at 19:43, martin odersky wrote:
> Given Paul's observations on +, and your own on ::, I believe the only
> redundant operators here are | & for sets and ::: for lists. I think | and &
> are kind of obvious, at least for bitsets. Would be a shame to have them on
> single words treated as bitsets but not arbitrary ones. So, the only
> operator that I think we can easily do without is :::. And I'm happy to see
> it go (after a deprecation period).

Not so fast...

scala> 1 :: List(2) ::: 3 :: List(4)
res2: List[Int] = List(1, 2, 3, 4)

scala> 1 :: List(2) ++ 3 :: List(4)
:8: error: type mismatch;
found : Int(3)
required: scala.collection.GenTraversableOnce[?]
1 :: List(2) ++ 3 :: List(4)
^

I'd like to make a suggestion. If you look at the post quoted below, you will see essentially a one-liner followed by a lengthy section of auto-quoted text approximately 4 or 5 levels deep. I don't want to make a major issue of it, but this is certainly a minor annoyance, and it seems to be more and more common. 
Auto-quoting is convenient for making it clear exactly what you are replying to, but it shouldn't be used to rehash the entire thread in each post. My suggestion is to cut the extraneous auto-quoted text before you post. In the example below, the first 4 or so lines of the auto-quoted text would have been sufficient to provide the context of the reply. It only takes a few seconds, and it eliminates a huge amount of clutter that everyone else has to scroll past. In some cases I have difficulty even finding the new post amidst all the clutter.
I am not claiming that a long auto-quoted section is never useful. I am just suggesting the use of common sense. Thanks.
--Russ P.


On Sun, Dec 4, 2011 at 11:35 AM, John Nilsson <john [at] milsson [dot] nu> wrote:

True. I didn't think it through.

BR,
John

Den 4 dec 2011 20:11 skrev "Paul Brauner" <polux2001 [at] gmail [dot] com>:

Why ":-" and not "-:" ? ":" would denote pre- or post- but removing
doesn't happen at one end of a collection. "-" sounds like a reasonable
choice to me.

Paul

On Sun, Dec 4, 2011 at 20:07, John Nilsson <john [at] milsson [dot] nu> wrote:
> If consistency is the goal and :+ is append I would say that :- is better
> than just -
>
> BR,
> John
>
> Den 4 dec 2011 19:14 skrev "Cay Horstmann" <cay [dot] horstmann [at] gmail [dot] com>:
>
>> I didn't say "redundant". I said "inconsistent".
>>
>> If you want to make the set of operators consistent, you have to work
>> harder than just deprecating :::.
>>
>> Again, I am only talking about the operators for adding and removing
>> from a collection. I have no beef with /: and :\. And I'll not talk
>> any more about the set operations.
>>
>> If consistency is the goal, decide between :: and +:. Let's say the
>> choice is ::.
>>
>> As Paul points out, + for insertion is a non-starter. There is no harm
>> in using :+ for sets.
>>
>> Let's say we keep - for removal.
>>
>> For bulk operations:
>>
>> :++ ::: --
>>
>> For mutation:
>>
>> :+= :++= -= --= =:: =:::
>>
>> That's a set of twelve consistent operators. I can explain it with three
>> rules:
>>
>> 1) Prepend is ::, Add/append is :+, Remove is -
>> 2) For bulk operations, one doubles the last character
>> 3) The = goes to the right for left-associative operators and to the
>> left for right-associative ones.
>>
>> It's not beautiful, but it has a few advantages over the operators
>> that we have now.
>>
>> + ++ :+ +: ++: - -- += ++= :+= +=: ++=: -= --= :: :::
>>
>> Here are the best rules I could come up with for describing them:
>>
>> 1) :+ appends, +: prepends, and + is used for unordered collections. -
>> removes.
>> 2) For bulk operations, use ++ to append, ++: to prepend. Little minds
>> might think it should be :++ to append, but you should realize that :+
>> was chosen because + is ambiguous with string concatenation. (For sets
>> we live with the ambiguity. Don't ask.) With ++, there is no such
>> ambiguity, so the unsightly colon is dropped.
>> 3) The = goes on the right for left-associative operators, but for :+,
>> the mutation is +=. Remember, the rule is that we drop the colon when
>> we can. (By the way, be sure not to get confused about :+= which is
>> synthesized from :+ and only works with for vars.)
>> 4) For right-associative operators, insert the = before the colon: +:
>> turns into +=: and ++: into ++=:. This may seem an odd place to insert
>> the =, but think about it this way: The : on the right turns around
>> whatever you apply it to, so += is turned around to +=: and ++= is
>> turned around to ++=:. Just like ++: is the turned-around ++. And +:
>> is a turned-around +, erm, actually :+, because, remember, + is
>> ambiguous with string concatenation.
>> 5)  :: and ::: are a special case for lists.
>>
>> Cheers,
>>
>> Cay
>>
>> On Sat, Dec 3, 2011 at 1:43 PM, martin odersky <martin [dot] odersky [at] epfl [dot] ch>
>> wrote:
>> > Given Paul's observations on +, and your own on ::, I believe the only
>> > redundant operators here are | & for sets and ::: for lists. I think |
>> > and &
>> > are kind of obvious, at least for bitsets. Would be a shame to have them
>> > on
>> > single words treated as bitsets but not arbitrary ones. So, the only
>> > operator that I think we can easily do without is :::. And I'm happy to
>> > see
>> > it go (after a deprecation period).
>> >
>> > Cheers
>> >
>> >  -- Martin
>> >
>> >
>> > On Sat, Dec 3, 2011 at 4:59 PM, Cay Horstmann <cay [dot] horstmann [at] gmail [dot] com>
>> > wrote:
>> >>
>> >> On Fri, Dec 2, 2011 at 11:08 AM, martin odersky
>> >> <martin [dot] odersky [at] epfl [dot] ch>
>> >> wrote:
>> >> >
>> >> >
>> >> > Cay, thanks for the thoughtful suggestions!
>> >> >
>> >> > On Fri, Dec 2, 2011 at 7:55 PM, Cay Horstmann
>> >> > <cay [dot] horstmann [at] gmail [dot] com>
>> >> > wrote:
>> >> >>
>> >>
>> >> >> And yes, the operators have gotten a bit out of hand in the
>> >> >> collections
>> >> >> library. I put them all into a table, and the result wasn't pretty.
>> >> >> (The
>> >> >> problem isn't the operators, but their inconsistency.) There is a
>> >> >> lot to
>> >> >> like about the collections library, but it's not perfect. Perhaps it
>> >> >> needs
>> >> >> to get redone one more time, or perhaps Scaladoc needs to be smarter
>> >> >> about
>> >> >> giving a more user-centric view.
>> >> >>
>> >> > Do you have suggestions regarding inconsistency of operators? Given a
>> >> > long enough deprecation cycle we could do changes if they are
>> >> > necessary. One
>> >> > other thing I thought of was merging the Traversable and Iterable
>> >> > layers if
>> >> > collections, because this would get rid of about 20% of the
>> >> > supertraits of
>> >> > standard collection classes.
>> >>
>> >> My gripe is with the operators to add and remove items. They are 17
>> >> operators + ++ :+ +: ++: :: ::: (for lists) | (for sets) += ++= +=:
>> >> ++=: (for buffers) - -- &~ (for sets) -= --=
>> >>
>> >> 1) Why have ::? You can use +:, of course, but not always--in
>> >> particular, not in pattern matching.
>> >> 2) Why the set operators? Just use ++, --
>> >> 3) Is it really worth worrying about the difference between + and :+?
>> >> I understand that + is supposed to be used for unordered collections,
>> >> and :+ for ordered collections. But then shouldn't we also use ++ for
>> >> unordered and :++ for ordered? And shouldn't we use :+= instead of +=
>> >> for buffers? I think it would be simpler to say "+ and ++ add, and the
>> >> addition is at the end for ordered collections".
>> >> 4) The +: and = don't work well together. += means "add/mutate". :+=
>> >> means "prepend/mutate". +:= should mean "append/mutate", but we need
>> >> the colon to the right, so it must be +=:. Or =+:? The choice seems
>> >> arbitrary. With :: for prepend, there is only one natural choice, =::
>> >>
>> >> I realize it would be painful to eliminate :: for lists. So, I'd give
>> >> up on :+, and I'd give up on the distinction between + and +:. What's
>> >> left is
>> >>
>> >> + ++ :: ::: - -- += ++= =:: =::: -= --=
>> >>
>> >> That's 12 operators, one for each choice of
>> >> - add/prepend/remove
>> >> - one or many
>> >> - mutate or not
>> >>
>> >> But if you love + vs :+ vs. +:, then the following 16 operators are a
>> >> consistent set:
>> >>
>> >> + ++ :+ :++ +: ++: - -- += ++= :+= :++= +=: ++=: -= --=
>> >>
>> >> Cheers,
>> >>
>> >> Cay
>> >
>> >
>> >
>> >
>> > --
>> > Martin Odersky
>> > Prof., EPFL and Chairman, Typesafe
>> > PSED, 1015 Lausanne, Switzerland
>> > Tel. EPFL: +41 21 693 6863
>> > Tel. Typesafe: +41 21 691 4967
>> >

--
http://RussP.us

On Sun, Dec 4, 2011 at 12:16 PM, Daniel Sobral wrote:
> On Sat, Dec 3, 2011 at 19:43, martin odersky wrote:
>> Given Paul's observations on +, and your own on ::, I believe the only
>> redundant operators here are | & for sets and ::: for lists. I think | and &
>> are kind of obvious, at least for bitsets. Would be a shame to have them on
>> single words treated as bitsets but not arbitrary ones. So, the only
>> operator that I think we can easily do without is :::. And I'm happy to see
>> it go (after a deprecation period).
>
> Not so fast...
>
>
> scala> 1 :: List(2) ::: 3 :: List(4)
> res2: List[Int] = List(1, 2, 3, 4)
>
> scala> 1 :: List(2) ++ 3 :: List(4)
> :8: error: type mismatch;
>  found   : Int(3)
>  required: scala.collection.GenTraversableOnce[?]
>              1 :: List(2) ++ 3 :: List(4)
>                              ^
>
> --
> Daniel C. Sobral

Actually, that should be

1 :: List(2) ++: (3 :: List(4))

::: is ++:, not ++.

Like I said, having an inconsistent set of operators is no fun. If it
had been :++ vs. ++:, then you wouldn't have made that mistake.

Cheers,

Cay

On Sun, Dec 4, 2011 at 18:29, Cay Horstmann wrote:
> On Sun, Dec 4, 2011 at 12:16 PM, Daniel Sobral wrote:
>> On Sat, Dec 3, 2011 at 19:43, martin odersky wrote:
>>> Given Paul's observations on +, and your own on ::, I believe the only
>>> redundant operators here are | & for sets and ::: for lists. I think | and &
>>> are kind of obvious, at least for bitsets. Would be a shame to have them on
>>> single words treated as bitsets but not arbitrary ones. So, the only
>>> operator that I think we can easily do without is :::. And I'm happy to see
>>> it go (after a deprecation period).
>>
>> Not so fast...
>>
>>
>> scala> 1 :: List(2) ::: 3 :: List(4)
>> res2: List[Int] = List(1, 2, 3, 4)
>>
>> scala> 1 :: List(2) ++ 3 :: List(4)
>> :8: error: type mismatch;
>>  found   : Int(3)
>>  required: scala.collection.GenTraversableOnce[?]
>>              1 :: List(2) ++ 3 :: List(4)
>>                              ^
>>
>> --
>> Daniel C. Sobral
>
> Actually, that should be
>
> 1 :: List(2) ++: (3 :: List(4))
>
> ::: is ++:, not ++.
>
> Like I said, having an inconsistent set of operators is no fun. If it
> had been :++ vs. ++:, then you wouldn't have made that mistake.

:++ and ++: are weird, but this is an object-oriented thingy. I have
sequences A and B, and I want to concatenate them. In the OO world,
that doesn't exist. What exists is prepending and appending one
sequence into another, which shouldn't have been relevant but, alas,
it is.

Given that it is, I much prefer asymmetric operators like :+, +:, ++:,
:++, etc. The colon convention helps use here by giving us right
associativity. :: and ::: are not asymmetric, so I'd rather see them
go than stay.

And "+" should never be used even if ignoring the string concatenation
problem, and how I wish we would pick up something else for string
concatenation! The least we can expect from "+" is that both sides can
be seen as the same type. Personally, I'd be perfectly happy with :++
and ++: for string concatenation.

Anyway, let us just be reminded that symbolic operators represent 10%
or less of all methods in a given collection. Having them be mnemonic
of their operators is very helpful, but it will never stop people who
complain about operators because they _are_ operators.

I like
scala> 1 :: List(2) ::: 3 :: List(4)
res2: List[Int] = List(1, 2, 3, 4)

more than

scala> 1 :: List(2) ++: (3 :: List(4))
res2: List[Int] = List(1, 2, 3, 4)

I would say:
:: prepending/appending an element to collection
::: prepending/appending a collection to a collection (concatenation)

On 4 dec, 21:29, Cay Horstmann wrote:
> On Sun, Dec 4, 2011 at 12:16 PM, Daniel Sobral wrote:
> > On Sat, Dec 3, 2011 at 19:43, martin odersky wrote:
> >> Given Paul's observations on +, and your own on ::, I believe the only
> >> redundant operators here are | & for sets and ::: for lists. I think | and &
> >> are kind of obvious, at least for bitsets. Would be a shame to have them on
> >> single words treated as bitsets but not arbitrary ones. So, the only
> >> operator that I think we can easily do without is :::. And I'm happy to see
> >> it go (after a deprecation period).
>
> > Not so fast...
>
> > scala> 1 :: List(2) ::: 3 :: List(4)
> > res2: List[Int] = List(1, 2, 3, 4)
>
> > scala> 1 :: List(2) ++ 3 :: List(4)
> > :8: error: type mismatch;
> >  found   : Int(3)
> >  required: scala.collection.GenTraversableOnce[?]
> >              1 :: List(2) ++ 3 :: List(4)
> >                              ^
>

On Sun, Dec 4, 2011 at 18:46, Dave wrote:
> I like
> scala> 1 :: List(2) ::: 3 :: List(4)
> res2: List[Int] = List(1, 2, 3, 4)
>
> more than
>
> scala> 1 :: List(2) ++: (3 :: List(4))
> res2: List[Int] = List(1, 2, 3, 4)
>
> I would say:
> :: prepending/appending an element to collection
> ::: prepending/appending a collection to a collection (concatenation)

I'd just use sequence operators:

scala> 1 +: List(2) ++: 3 +: List(4)
res4: List[Int] = List(1, 2, 3, 4)

It kind of takes more than 4 seconds on my phone though. In fact it's the default behavior so I didn't even realize how much it was. Sorry about that. The good news is you made me discover the conveniently placed checbox for including text. ;-)

BR,
John

Den 4 dec 2011 21:29 skrev "Russ Paielli" <russ [dot] paielli [at] gmail [dot] com>:
> My suggestion is to cut the extraneous auto-quoted text before you post.

The solution to making operators consistent is to generalise them so that there are not multiple occurrences. This way, they also become more readable.

On Dec 5, 2011 6:16 AM, "Daniel Sobral" <dcsobral [at] gmail [dot] com> wrote:

On Sat, Dec 3, 2011 at 19:43, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
> Given Paul's observations on +, and your own on ::, I believe the only
> redundant operators here are | & for sets and ::: for lists. I think | and &
> are kind of obvious, at least for bitsets. Would be a shame to have them on
> single words treated as bitsets but not arbitrary ones. So, the only
> operator that I think we can easily do without is :::. And I'm happy to see
> it go (after a deprecation period).

Not so fast...


scala> 1 :: List(2) ::: 3 :: List(4)
res2: List[Int] = List(1, 2, 3, 4)

scala> 1 :: List(2) ++ 3 :: List(4)
<console>:8: error: type mismatch;
 found   : Int(3)
 required: scala.collection.GenTraversableOnce[?]
             1 :: List(2) ++ 3 :: List(4)
                             ^

--
Daniel C. Sobral

I travel to the future all the time.

On Sun, Dec 4, 2011 at 12:39 PM, Daniel Sobral wrote:

> Given that it is, I much prefer asymmetric operators like :+, +:, ++:,
> :++, etc. The colon convention helps use here by giving us right
> associativity. :: and ::: are not asymmetric, so I'd rather see them
> go than stay.

I understand the argument, but I made my proposal in the context of
"getting from here to there". One can leave the +: and :: methods
around for a while, deprecating one or the other. But one can't add a
case class +: for pattern matching that lives alongside the :: case
class.

So, I think we are stuck with :: for lists.

If one wants consistency (and I realize that I may be the only one to
want it), +: has to go.

Cheers,

Cay

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 04.12.2011 22:49, schrieb John Nilsson:
> The good news is you made me discover the conveniently placed checbox
> for including text. ;-)
>

In Thunderbird (3.1.15) I can mark a sentence, and if I then hit 'reply
to list', only the marked text get's inserted as citation.

On Sun, Dec 4, 2011 at 3:22 PM, Cay Horstmann wrote:
> If one wants consistency (and I realize that I may be the only one to
> want it), +: has to go.

Ha ha, I would give up limbs for more consistency until such time as
no limbs remained. Then I'd give up your limbs.

> But one can't add a
> case class +: for pattern matching that lives alongside the :: case
> class.

One can, and probably should, add a +: extractor. And the way things
are going in patmat land it might be enough.

I think +: has to remain if only because the symmetry is too
attractive to give up.

scala> val elems = Seq(3, 4)
elems: Seq[Int] = List(3, 4)

scala> val xs = 1 +: 2 +: elems :+ 5 :+ 6
xs: Seq[Int] = List(1, 2, 3, 4, 5, 6)

> So, I think we are stuck with :: for lists.
>
> If one wants consistency (and I realize that I may be the only one to
> want it), +: has to go.
>
> Cheers,
>
> Cay

But you cannot remove +: and keep :+ because there is a symmetry rule
for operators that says if you have :+ ( append) then there must be a
mirrored symbol (thus +:) that does the opposite thing (thus prepend)

:: is only redundant for lists and this thread was not about
redundancy.

This seems the simplest and most natural to me:
append-value:         +append-collection:    ++prepend-value:        +:prepend-collection:   ++:

On Sun, Dec 4, 2011 at 3:56 PM, Paul Phillips wrote:
> On Sun, Dec 4, 2011 at 3:22 PM, Cay Horstmann wrote:
>> If one wants consistency (and I realize that I may be the only one to
>> want it), +: has to go.
>
> Ha ha, I would give up limbs for more consistency until such time as
> no limbs remained.  Then I'd give up your limbs.
>
>> But one can't add a
>> case class +: for pattern matching that lives alongside the :: case
>> class.
>
> One can, and probably should, add a +: extractor.  And the way things
> are going in patmat land it might be enough.

I see. I didn't think of that. Somehow I thought one had to use the
same class, but any class with an unapply will do. This works:

case object +: {
def unapply[T](input: List[T]) = if (input.isEmpty) None else
Some((input.head, input.tail))
}

("A" +: "B" +: Nil) match { case h +: t => println(t) }

Ok, that's nice. In fact, it's nicer than with :: because it's so
obvious that the association is right to left.

Then the endpoint is this:

1) Append is :+, prepend is +:, remove is -
2) Bulk ops are :++ ++: --
3) Mutators are :+= :++= =+: =++: -= --=

To get there,

1) Deprecate :: and :::
2) Deprecate ++, ++= and provide :++, :++=
3) Deprecate +=: ++=: and provide =+: and =++:
4) Deprecate + for sets, and provide :+ +:

There is a way. Is there the will?

Cheers,

Cay

On Sun, Dec 4, 2011 at 7:22 PM, Cay Horstmann wrote:
> Then the endpoint is this:
>
> 1) Append is :+, prepend is +:, remove is -
> 2) Bulk ops are :++ ++: --
> 3) Mutators are :+= :++= =+: =++: -= --=
>
> To get there,
>
> 1) Deprecate :: and :::
> 2) Deprecate ++, ++= and provide :++, :++=
> 3) Deprecate +=: ++=: and provide =+: and =++:
> 4) Deprecate + for sets, and provide :+ +:
>
> There is a way. Is there the will?

Subtleties and highwires remain.

The fact that :: is specific to lists means that you can
compose/decompose them and have some confidence you aren't entering
O(n^2) land. A uniform operator for that robs you of much defense
against

def f(xs: Seq[_]) = xs match { case x +: rest => f(rest) }
f(1 to 10000 toArray)

We couldn't even consider phasing out :: until/unless a +: extractor
offered equivalent features, which is to say,
exhaustiveness/unreachability checking and case-class speed pattern
matching, both of which may come but neither of which is here. And
then that said, it won't be deprecated anyway: it has "language
tenure." I think you have to embrace :: as list's little buddy and if
+: reaches feature/performance parity :: could perhaps be
de-emphasized.

I can't see the will to deprecate ++ coming along either.

I could see losing '+' on sets, as it's not worth the inconsistency to
let set hang onto '+' after the others had to let it go. Let the evil
tendrils of any2stringadd have their way with all the lonely pluses.

I don't see a good reconciliation of +: and mutation. One problem is
that the spec says to be right-associative you must end in a colon,
and to be an assignment operator you must end in an equals sign.
Personally I can't keep the possible mixes of :, +, and = straight as
to which exists and what they do without spinning up a whole spare
wing of my brain, which doesn't bode well for people who write less
scala than I do. But I can't see operators like =+: as much of an
improvement.

I'd rather just avoid symbolic notation which combines more than two
symbols. x += y, ok. xs ++= ys, ok. (That's two, ++ and =, for any
who think I can't count.) xs ?++= ys, suddenly the anti-operator
people start looking like they have a point.

On Sun, Dec 4, 2011 at 21:22, Cay Horstmann wrote:
> On Sun, Dec 4, 2011 at 12:39 PM, Daniel Sobral wrote:
>
>> Given that it is, I much prefer asymmetric operators like :+, +:, ++:,
>> :++, etc. The colon convention helps use here by giving us right
>> associativity. :: and ::: are not asymmetric, so I'd rather see them
>> go than stay.
>
> I understand the argument, but I made my proposal in the context of
> "getting from here to there". One can leave the +: and :: methods
> around for a while, deprecating one or the other. But one can't add a
> case class +: for pattern matching that lives alongside the :: case
> class.

Why not? In fact, Josh (iirc) has proposed just such a thing!

Far too much colons imho.

I think the real question is if append should have a colon for symmetry purposes.

I'm not sure that is a good idea in fact. People learn about the special rule that a colon at the end changes associativity and keep wondering which special magic happens in case of the colon in front.
At least this is what happened to me. Quite some head-scratching over a few months, because I thought I kept missing something obvious.

Imho colons in a method should only be used at the end (I would let ::, ::: live, though.)

This brings us back to the question if removing any2stringadd is an option.

Imho it should be done, because "" + foo + "TestTest" has no bytecode penalty anymore afaik, compared to foo + "TestTest".

If it would be an option: remove it and prefer less no-op colons over symmetry.

Otherwise, I don't see a solution where benefits would out weight the costs.

Thanks and bye,

Simon

> To get there,
>
> 1) Deprecate :: and :::
> 2) Deprecate ++, ++= and provide :++, :++=
> 3) Deprecate +=: ++=: and provide =+: and =++:
> 4) Deprecate + for sets, and provide :+ +:
>
5) Deprecate #:: and #::: for streams

On Sun, Dec 4, 2011 at 7:22 PM, Cay Horstmann wrote:
> On Sun, Dec 4, 2011 at 3:56 PM, Paul Phillips wrote:
>> On Sun, Dec 4, 2011 at 3:22 PM, Cay Horstmann wrote:
>>> If one wants consistency (and I realize that I may be the only one to
>>> want it), +: has to go.
>>
>> Ha ha, I would give up limbs for more consistency until such time as
>> no limbs remained.  Then I'd give up your limbs.
>>
>>> But one can't add a
>>> case class +: for pattern matching that lives alongside the :: case
>>> class.
>>
>> One can, and probably should, add a +: extractor.  And the way things
>> are going in patmat land it might be enough.
>
> I see. I didn't think of that. Somehow I thought one had to use the
> same class, but any class with an unapply will do. This works:
>
> case object +: {
>  def unapply[T](input: List[T]) = if (input.isEmpty) None else
> Some((input.head, input.tail))
> }
>
> ("A" +: "B" +: Nil) match { case h +: t => println(t) }
>
> Ok, that's nice. In fact, it's nicer than with :: because it's so
> obvious that the association is right to left.
>

It would also invalidate every single document and book that was ever
written about Scala. Sometimes we have to live with history. :: came
from ML, is close to Haskell's :. We can't simply replace it with a
new operator. Imagine Haskell programmers proposed to change : to +:,
maybe for the same reasons? Would you think that was viable?

Also, if you provide +: as an extractor for all collections, you add
another inconsistency. Will you also provide :+? What about efficiency
concerns?

I think the discussion so far was useful because it gave us better
view of collections. But it is altogether too sequence centric. +:,
+:, simply make no sense for maps!

The way I see it is much closer to the status quo.

For sequences:

1) Append is :+, prepend is +:, remove is -
2) Bulk ops are ++, ++:, --
3) Mutators are +=, ++=, +=: ++=: -= --=

Yes, there's a bias for bulk ops vs single ops. I think that's OK
because it makes bulk ops simpler and emphasizes the fact that bulk
ops are supposed to be associative.

For lists: In addition can compose and pattern match with ::.

For streams: In addition can compose and pattern match with #::

For sets and maps: Append/prepend ops are replaced by +. Only unbiased
mutators +=, ++=, -= exist.

I think that's not so bad!

>
> To get there,
>
> 1) Deprecate :: and :::
> 2) Deprecate ++, ++= and provide :++, :++=
> 3) Deprecate +=: ++=: and provide =+: and =++:
> 4) Deprecate + for sets, and provide :+ +:
>
The other problem with this, besides being incompatible and too
sequence centric is that it makes a lot of operators longer. Now, I
think we all agree that symbolic operators should be as short as
possible. Every additional symbol makes them harder to read. Why
insist on :+, +:, :++ and ++: when order does not matter and you might
just as well have written + or ++?

Cheers

Please do not remove /: and :\. I cannot be the only person who prefers these greatly over their counterparts for previously stated reasons [1] and who finds this form far *more* intuitive! 
Please do not remove & and &~ on Sets either; again they are incredibly useful for readability; a Set is a distinct collection type from a Sequence and I think that it is far from clear that (s & t) is "not intuitive": the only obvious name which would be crystal clear is ∩ but something tells me that you won't be a fan of this either.
As others have observed, it doesn't seem very likely that any person who would discount a computer language over seeing something which they don't recognise is not going to find something else to get upset about. And also, I think when people say something is "not intuitive" they should include the silent "I find this" prefix, or "to me" suffix, assuming they agree with the sentiment that others may hold a different opinion. I much prefer /: but I am not arguing for the removal of foldLeft.

[1] http://stackoverflow.com/a/7340037/16853

Date: Sat, 3 Dec 2011 14:50:42 -0800
From: simon [dot] ochsenreither [at] googlemail [dot] com

What about removing /:, :\, /:\ instead? :-)

They are redundant, heavily criticized and not intuitive, compared to ::/:::.

A compromise would be to keep those three as @bridge methods, so nothing breaks while they can "slowly" disappear.

Simon

On 5 dec, 14:25, Chris Marshall wrote:
> Please do not remove /: and :\.
I agree. I find them visually very intuitive.
And from /: and :\ you can compose the meaning of /:\

Hi,

The way you explained it sounded very intuitive and reasonable. Maybe this could be added to the FAQ?

The issues with fold operators still remain, though.

Bye,

Simon

On Sun, Dec 04, 2011 at 01:02:28PM -0500, ARKBAN wrote:
> If this were all up to me I'd use only the most basic +, -, =
> operators (and their combinations) and save all the other forms
> until Scala 3 or 4, sometime *after* Scala is the clearer winner of
> the JVM language wars (in terms of replacing Java).

I'm not necessarily disagreeing with your argument per se, but I don't
think that the "Scala must replace Java to be successful" path is the
only path for Scala to go to be successful.

In fact, I worry that "we the community" spend more time that we should
on worrying about whether Scala will replace Java and not enough time
on making Scala itself awesome on its own terms [1].

On Mon, Dec 5, 2011 at 11:48 AM, Erik Osheim wrote:
> On Sun, Dec 04, 2011 at 01:02:28PM -0500, ARKBAN wrote:
>> If this were all up to me I'd use only the most basic +, -, =
>> operators (and their combinations) and save all the other forms
>> until Scala 3 or 4, sometime *after* Scala is the clearer winner of
>> the JVM language wars (in terms of replacing Java).
>
> I'm not necessarily disagreeing with your argument per se, but I don't
> think that the "Scala must replace Java to be successful" path is the
> only path for Scala to go to be successful.
>
> In fact, I worry that "we the community" spend more time that we should
> on worrying about whether Scala will replace Java and not enough time
> on making Scala itself awesome on its own terms [1].
>

On Mon, Dec 5, 2011 at 11:22, martin odersky wrote:
>
> Also, if you provide +: as an extractor for all collections, you add
> another inconsistency. Will you also provide :+? What about efficiency
> concerns?

I don't see why not. The efficiency of :+ as an extractor is exactly
the same as +: for IndexedSeq collections, and bad (or downright
impossible for infinite collections) for LinearSeq. So, perhaps, it
could be defined as accepting only IndexedSeq? Nevertheless, it is
efficient enough for many classes.

> For sets and maps: Append/prepend ops are replaced by +. Only unbiased
> mutators +=, ++=, -= exist.

As I stated before, I think + is unintuitive, in that the type of the
parameter it receives is quite different than the type of the object
it is called on. Besides having that String problem. But I'll grant
that I'm way outnumbered here! :-)