View transformers

[pnf]

POC for composing view transformations, ala transducers.

[julienrf]

Thanks for putting this work together. I like the overall idea. I left some minor comments.

[julienrf]

I’m not a fan of the transform name. Maybe transformView?

[pnf]

Except in this case it starts out as an Iterable and ends up as one. The intermediate representation as Views is really an implementation detail. The closest equivalent in Clojure's transducer kit would be sequence, but that's even worse.

[pnf]

Actually, whether it ends up as a View, depends only on whether it started out as one, which is nice.

[julienrf]

Why choose to use a type alias + an implicit class rather than a proper class?

[pnf]

I did have it as a real class originally, and after playing around a bit, the typeclass approach seemed neater. I'm not committed to this though. I'll fiddle around some more.

[pnf]

It ends up looking like

abstract class ViewTransformer[-A,+B] {
  def apply(v: Iterable[A]): View[B]
  def map[C](f: B => C) = new ViewTransformer[A,C]  {
    def apply(v: Iterable[A]): View[C] = new View.Map(ViewTransformer.this(v),f)
  }
  ...
}

which is fine I guess, but feels clunkier (to me).

[Ichoran]

I think this form is more easily grasped by a larger fraction of Scala users (as it depends on a smaller more widely used set of language features). Elegance is fine, but approachability is usually more important.

[julienrf]

What’s clunkier exactly? You can also define a factory method in the ViewTransformer companion:

object ViewTransformer {
  def apply[A, B](f: Iterable[A] => View[B]): ViewTransformer[A, B] = …
}

class ViewTransformer[-A, +B] {
  def apply(as: Iterable[A]): View[B]
  def map[C](f: B => C) = ViewTransformer(it => View.Map(apply(v)), f)
}

Or, you can also use the “lambda” syntax (which has been generalized to SAM types):

trait ViewTransformer[-A, +B] {
  def apply(as: Iterable[A]): View[B]
  def map[C](f: B => C): ViewTransformer[A, C] = as => View.Map(apply(as), f)
}

[pnf]

I didn't realize we could use lambda sugar for any SAM. I'll do that...

[julienrf]

I’m not a big fan of the source name. What about id (since this view transformer preserves the same collection)?

[pnf]

Hah! It was originally called id. You seem to have inferred all my first draft ideas. Anyway, I'm fine changing it back.

[julienrf]

I’m wondering if we really need ViewTransformer operations.

If we go back to a form where ViewTransformer[-A, +B] is just an alias for View[A] => View[B] (and there is no view transformer operations) we can still combine ViewTransformer instances by defining functions on Views. Your example would look as follows:

val x: ViewTransformer[Int, Double] = xs => xs.map(i => i * 2).flatMap(i => Seq(i + 0.0, i + 0.5))
val x2: ViewTransformer[Double, (String, Int)] = xs => xs.collect { case d if d < 3.0 => s"Hey $d" }.zipWithIndex
xs.transform(x andThen x2)

instead of the current:

val x = id[Int].map{ i => i * 2 }.flatMap { i => collection.immutable.Seq(i + 0.0, i + 0.5) }
val x2 = id[scala.Double].collect { case d if d < 3.0 => s"Hey $d"}.zipwithIndex
xs.transform(x andThen x2)

[He-Pin]

FYI https://github.com/knutwalker/transducers-scala

[SethTisue]

closing all open pull requests in this repo. perhaps this could move forward in scala/scala, where the code now lives