score:5

to be honest i'm not sure how that really works:

implicit def collectionextras[cc[x] <: iterable[x], a](xs: cc[a]) = new {
  import collection.generic.canbuildfrom
  def zipwith[b, c](ys: iterable[b])(f: (a, b) => c)
  (implicit cbf:canbuildfrom[nothing, c, cc[c]]): cc[c] = {
    xs.zip(ys).map(f.tupled)(collection.breakout)
  }
}

scala> vector(2, 2, 2).zipwith(vector(4, 4, 4))(_ * _)
res1: scala.collection.immutable.vector[int] = vector(8, 8, 8)

i sort of monkey patched this answer from retronym until it worked!

basically, i want to use the cc[x] type constructor to indicate that zipwith should return the collection type of xs but with c as the type parameter (cc[c]). and i want to use breakout to get the right result type. i sort of hoped that there was a canbuildfrom implicit in scope but then got this error message:

required: scala.collection.generic.canbuildfrom[iterable[(a, b)],c,cc[c]]

the trick was then to use nothing instead of iterable[(a, b)]. i guess that implicit is defined somewhere...

also, i like to think of your zipwith as zip and then map, so i changed the implementation. here is with your implementation:

implicit def collectionextras[cc[x] <: iterable[x], a](xs: cc[a]) = new {
  import collection.generic.canbuildfrom
  def zipwith[b, c](ys: iterable[b])(f: (a, b) => c)
  (implicit cbf:canbuildfrom[nothing, c, cc[c]]) : cc[c] = {
    val builder = cbf()
    val (i, j) = (xs.iterator, ys.iterator)
    while(i.hasnext && j.hasnext) {
      builder += f(i.next, j.next)
    }
    builder.result
  }
}

note this article provides some background on the type constructor pattern.

score:8

the problem above is that your implicit conversion collectionextras causes the obtained object to lose type information. in particular, in the solution above, the concrete collection type is lost because you're passing it an object of type iterable[a] - from this point on, the compiler no longer knows the real type of xs. although the builder factory canbuildfrom programatically ensures that the dynamic type of the collection is correct (you really get a vector), statically, the compiler knows only that zipwith returns something that is an iterable.

to solve this problem, instead of having the implicit conversion take an iterable[a], let it take an iterablelike[a, repr]. why?

iterable[a] is usually declared as something like:

iterable[a] extends iterablelike[a, iterable[a]]

the difference with iterable is that this iterablelike[a, repr] keeps the concrete collection type as repr. most concrete collections, in addition to mixing in iterable[a], also mix in the trait iterablelike[a, repr], replacing the repr with their concrete type, like below:

vector[a] extends iterable[a] with iterablelike[a, vector[a]]

they can do this because type parameter repr is declared as covariant.

long story short, using iterablelike causes you implicit conversion to keep the concrete collection type information (that is repr) around and use it when you define zipwith - note that the builder factory canbuildfrom will now contain repr instead of iterable[a] for the first type parameter, causing the appropriate implicit object to be resolved:

import collection._
import collection.generic._

implicit def collectionextras[a, repr](xs: iterablelike[a, repr]) = new {
  def zipwith[b, c, that](ys: iterable[b])(f: (a, b) => c)(implicit cbf: canbuildfrom[repr, c, that]) = {
    val builder = cbf(xs.repr)
    val (i, j) = (xs.iterator, ys.iterator)
    while(i.hasnext && j.hasnext) {
      builder += f(i.next, j.next)
    }
    builder.result
  }
}

reading your question formulation more carefully ("how to write a zipwith method that returns the same type of collection as those passed to it?"), it seems to me that you want to have the same type of collection as those passed to zipwith, not to the implicit conversion, that is the same type asys.

same reasons as before, see solution below:

import collection._
import collection.generic._

implicit def collectionextras[a](xs: iterable[a]) = new {
  def zipwith[b, c, that, repr](ys: iterablelike[b, repr])(f: (a, b) => c)(implicit cbf: canbuildfrom[repr, c, that]) = {
    val builder = cbf(ys.repr)
    val (i, j) = (xs.iterator, ys.iterator)
    while(i.hasnext && j.hasnext) {
      builder += f(i.next, j.next)
    }
    builder.result
  }
}

with results:

scala> immutable.vector(2, 2, 2).zipwith(mutable.arraybuffer(4, 4, 4))(_ * _)
res1: scala.collection.mutable.arraybuffer[int] = arraybuffer(8, 8, 8)

score:9

you got close enough. just a minor change in two lines:

implicit def collectionextras[a, cc[a] <: iterablelike[a, cc[a]]](xs: cc[a]) = new {
  def zipwith[b, c, that](ys: iterable[b])(f: (a, b) => c)(implicit cbf: canbuildfrom[cc[a], c, that]) = {
    val builder = cbf(xs.repr)
    val (i, j) = (xs.iterator, ys.iterator)
    while(i.hasnext && j.hasnext) {
      builder += f(i.next, j.next)
    }
    builder.result
  }
}

first, you need to get the collection type being passed, so i added cc[a] as a type parameter. also, that collection needs to be able to "reproduce" itself -- that is guaranteed by the second type parameter of iterablelike -- so cc[a] <: iterablelike[a, cc[a]]. note that this second parameter of iterablelike is repr, precisely the type of xs.repr.

naturally, canbuildfrom needs to receive cc[a] instead of iterable[a]. and that's all there is to it.

and the result:

scala> vector(2, 2, 2).zipwith(vector(4, 4, 4))(_ * _)
res0: scala.collection.immutable.vector[int] = vector(8, 8, 8)

Related Query

More Query from same tag