trunk collections cleanups

On Fri, Nov 6, 2009 at 8:20 PM, Paul Phillips wrote:
> I have a whole pile of stuff I'd hoped would be taken care of before we
> invited anyone in.  I'll table that ambition but I can at least bring a
> few things up and see if we can make a command decision.
>
> Deprecations: Jorge, do I remember you were going to propose
> deprecations which could be deleted? I know you're busy, if that's not
> done could you maybe send me what you've got in whatever state it is? I
> do not like that as of now we are proceeding with a source base which:
>
>  1) compiles with 100s of deprecation warnings

>  2) has deprecated methods with vaporware alternative (List.map2, etc.)

Actually, Tuple.map is in trunk now, but we are changing that again to
TraversableLike.map2. Adriaan is taking care of that over the next
couple of days.
>  3) offers deprecation messages which suggest not-equivalent alternatives

Which ones?

>  4) has deprecated methods which recommend other deprecated methods

That should be corrected by transitive closure, surely.

>  5) has methods marked deprecated which did not exist in 2.7 which could
> simply be removed
>
yes, sure.

> ...and more.  I've eliminated 100s of deprecation warnings but the
> majority of the rest are at this point out of my hands.
>
> Consistency: For historical reasons List has some methods other
> sequences don't.  Looks like there may only be a couple left, but I
> think these should both either be deprecated or defined on Seq.  (I am
> in favor of keeping both methods, not that I think mapConserve is
> debatable since it's used about 100 places in the compiler.)
>
>  def reverseMap[B](f: A => B): List[B]
>  def mapConserve[B >: A] (f: A => B): List[B]
>
yes, we could move these up to Seq. mapConserve would have to be
re-implemented in LinearSeq to satisy the property that
it also conserves tails of lists even if the heads change.

> I'm still in the dark as to the future of a method with the nice simple
> name of "sort".  Our only sorts are a deprecated method in List and one
> on the scala.util.Sorting object.  Is there a clear short-term plan
> about naming (sort, sortWith, sortBy), where these are to be defined,
> what kind of arguments they are to accept?
>
All of them are good. Just waiting to be implemented. I'd say in
SeqLike, where sortWith is already defined.

> Deletions: I hate these methods:
>
>  def reduceLeftOption[B >: A](op: (B, A) => B): Option[B]
>  def reduceRightOption[B >: A](op: (A, B) => B): Option[B]
>
> and I think (not 100% sure, correct me if I'm wrong) that dpp agreed we
> could live without them.

I can't recall that. I'm also not very keen on these methods, but
there was such a strong push to put them in that I''d be surprised if
we could remove the without opposition.

> Can I delete them? We can always put them in
> later, but they will be hard to take out (we'll have headOption and
> lastOption until we die I'm sure) and the issue is so much larger than
> reduceRight and reduceLeft, it cries out for a more general approach
> than ad hoc sprinklings of xxxOption.
>
I'd leave them in. Not worth fighting against.

Cheers

On Fri, Nov 06, 2009 at 09:47:50PM +0100, martin odersky wrote:
> Actually, Tuple.map is in trunk now, but we are changing that again to
> TraversableLike.map2. Adriaan is taking care of that over the next
> couple of days.

This seems like a big design decision. You're saying TraversableLike is
going to gain a map2 method which I assume will look something like:

def map2[T1, T2, B, That](f: (T1, T2) => B)(
implicit bf: CanBuildFrom[Repr, B, That],
implicit ev: A <:< (T1, T2)): That

And it will also gain: exists2, forall2, foreach2, zip2, zipWith2? And
what about map3, zip3, etc? Personally I find the arity limits on these
methods to be highly constraining (especially zip and map) but if
everything is going onto TraversableLike that doesn't seem like a sign
they'll all be heading to 5.

> >  3) offers deprecation messages which suggest not-equivalent alternatives
>
> Which ones?

For the life of me I can't remember where I sent the list of ones I
noticed a couple months ago, but here's one I remember:

scala> List(1,1,1,2) -- List(1)
:5: warning: method -- in class List is deprecated: use `diff' instead
List(1,1,1,2) -- List(1)
^
res0: List[Int] = List(2)

scala> List(1,1,1,2) diff List(1)
res1: List[Int] = List(1, 1, 2)

> >  4) has deprecated methods which recommend other deprecated methods
>
> That should be corrected by transitive closure, surely.

Taking that to mean I can fix them, will do.

> All of them are good. Just waiting to be implemented. I'd say in
> SeqLike, where sortWith is already defined.

What is the signature of "def sort"? I am figuring:

def sort[B >: A](implicit ord: Ordering[B]): Repr

...which is actually (one of) sortWith's (overloaded) signatures, except
with ord implicit. Which makes me think the better answer is to not
overload sortWith (which impairs type inference) and rename the newer
variation of sortWith to sort and implicitify the argument.

I miss the ability to arrange for the ordering in advance and have
"xs.sort" do what I mean.

> > and I think (not 100% sure, correct me if I'm wrong) that dpp agreed we
> > could live without them.
>
> I can't recall that.

Oh sorry, I meant in real-life conversation. I put him on the To line
to confirm or deny my recollection, but if his cooperation isn't enough
to ditch them then I suppose the point is moot.