

A Scala Corrections Library - yummyfajitas
http://www.slideshare.net/extempore/a-scala-corrections-library

======
brandonbloom
Can somebody explain to me the motivation for all the CanBuildFrom machinery?

Is the goal solely to avoid having to explicitly state the type of the target
collection? It seems to me that assuming the output collection is likely to be
of the same type as the input collection is... frankly... wrong.

Clojure's approach makes a lot more sense to me: Coerce to lazy sequences &
chain together O(N) operations by operating on sequences, then require
explicit reconstitution of the target type. Using something like (into #{} (f
(g (h #{:some :set :items})))) manages to 1) avoid stating the target type (by
using an empty set literal) 2) support processing into an existing non-empty
collections and 3) avoid the overhead of re-constructing more complex data
structures for intermediate steps (at the cost of lazy sequence construction),
4) is trivially extensible to new target types (implement conj) and 5) plays
nice with fast transient object construction (implement transient,
persistent!, and conj!). Then with reducers and monoidal operations, you can
switch from sequential algorithms to parallel algorithms without paying the
lazy sequence cost.

Scala's model buys me what exactly? I don't have to write (vec ...) or (into
(my-data-structure) ...) or whatever? Seems a steep complexity price to pay
for such a trivial and questionable feature.

Am I missing something?

~~~
zackangelo
> Is the goal solely to avoid having to explicitly state the type of the
> target collection?

Pretty much.

[http://stackoverflow.com/questions/1722726/is-the-
scala-2-8-...](http://stackoverflow.com/questions/1722726/is-the-
scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist)

