This page is no longer maintained — Please continue to the home page at www.scala-lang.org

proposed alterations to TupleN#Zipped

No replies
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.

Hey adriaan -- I have some questions about the design of the zipped
classes. Here are proposed changes:

http://github.com/scala/scala/tree/tuple-zipped

I enclose the current commit message which about sums it up:

A proposed overhaul of the collection-oriented methods in
Tuple2/Tuple3 (which should go all the way to Tuple5.)

* Failure of zip semantics: zip and zipped never terminate
if the first collection of the tuple is an infinite sequence, even
if one of the other positions runs out of elements.

* Strictness of zipped: Isn't the following behavior an
improvement over non-termination? Fans of infinite loops can
always use .zip instead. I rewrote these methods to short
circuit rather than fold forever.

scala> val ys = Stream from 1
ys: scala.collection.immutable.Stream[Int] = Stream(1, ?)

scala> (ys, ys).zipped forall ((x, y) => x+y < 100)
res0: Boolean = false

scala> (ys, ys).zipped exists ((x, y) => x+y > 100)
res1: Boolean = true

* Limited utility of the TraversableLikeLike frankenstein classes:
Zipped can't implement Traversable because the relationship of the
type parameters to the signature of foreach is fixed. But it seems
pretty useful to provide access to the 95% of Traversable methods
we're missing in tupled form, like so:

// and etc for 3, 4, 5
implicit def zipped2ToTraversable[El1, El2](zz: Tuple2[_, _]#Zipped[_, El1,
new Traversable[(El1, El2)] {
def foreach[U](f: ((El1, El2)) => U): Unit = zz foreach Function.untuple
}

And then we can do this:

scala> (ys, ys, ys).zipped find { case (x, y, z) => x+y+z > 1000 }
res0: Option[(Int, Int, Int)] = Some((334,334,334))

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland