- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
proposed alterations to TupleN#Zipped
Thu, 2010-09-16, 19:53
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))