Relationship between Scala core and Scalaz libs

[Ben Hutchison]

I have a question about the relationship between Scala core and Scalaz
libs.

Its motivated by the appearance (to my untrained eye) that Scalaz
defines a number of traits that are, conceptually, foundational
supertypes of key types defined in Scala core.

Its unusual for a library to do this, and seems to present some
difficulties if one wants to use both libraries in the most harmonious
fashion.

This awareness came about while reading the "Typeclassopedia" article
about the Haskell type class hierarchy in Mondad.Reader issue 13. On
page 19 there is a diagram of many core Haskell types, which are also
found in Scalaz. [http://www.haskell.org/sitewiki/images/8/85/TMR-
Issue13.pdf]

It seems this class hierarchy should be of interest to Scala because
(a) its abstractions have been created by condensing > 10 years of
programming experience, and
(b) it models mathematical concepts that are also applicable to Scala
(or any language) and not in any deep way Haskell-specific.

Towards the bottom of Haskell's diagram is a type class Traversable.
This class has similarities to the Traversable base class for the
Scala collections [see page 3 of the Scala 2.8 collections redesign,
http://www.nabble.com/2.8-collections-td23602869.html].

What struck me was that Traversable was the /only/ overlap between
Scala's collections and Haskell's core type classes. Why? For example,
what about (Haskell)Traversable's supertype Functor - why isnt that
present in the Scala core?

In search of answers, I investigated Scalaz, and found many of the
other Haskell types are defined here.

But that then raises many questions:

- If Scala core types (eg Collections) extended Scalaz types (eg
Functor), would that be workable and useful to general users?

- Have you (the Scalaz authors), are you or would you, engage(d) in a
conversation with Martin & the Scala core team WRT to pushing some of
these foundation types up into the core?"

- If there's been discussions, what was the response? Are relevant
discussions archived?

- How do you integrate Scalaz super- and ScalaCore sub- types
currently?

-Ben

[Runar Bjarnason]

Ben,


Tony Morris, the main brains and brawn behind Scalaz, will be able to
answer most of your questions in detail. But I can address your last
question a little.

Subclassing goes against Scalaz's design principles in general. The
way Scalaz and Scala Core types are currently integrated is through
implicit conversions in Scalaz. We define implicit instances of most
of its typeclasses for the majority of Scala Core (as well as JDK)
types. For instance, if you just import Scalaz, you implicitly have
Applicative and Functor for Scala Core's Option type:

scala> import scalaz.Scalaz._
import scalaz.Scalaz._

scala> Some(7) <*> (Some(8) |> ((a:Int) => (b:Int) => a + b))
res0: Option[Int] = Some(15)


This also works with standard Java library classes:

scala> val a = new java.util.ArrayList[Int]()
a: java.util.ArrayList[Int] = []

scala> a.add(1); a.add(2); a.add(3);

scala> a <*> (a |> ((a:Int) => (b:Int) => a + b))
res1: java.util.ArrayList[Int] = [2, 3, 4, 3, 4, 5, 4, 5, 6]


This really speaks to the power and flexibility of the Scala language.
And it might go a long way towards answering your other questions as
well. It's not necessarily a design goal of the Scala core libraries
to provide a correct be-all end-all hierarchy of type-classes. But
we're free to augment it in a very elegant manner. Or discard it, as
the case may be.


Runar

[Tony Morris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ben,
Scalaz is unusual because it generalises a lot of the core Scala
library. However, unlike the Scala core libraries, Scalaz can change
quickly to adapt to new project requirements for libraries that are
not specific to a particular project. It also has a different approach
to solving programming problems in general, than the core Scala libraries.

Scalaz aims for componentisation and abstraction, sometimes at the
expense of performance (though this is taken into account) and
encountering language deficiencies. Why isn't Functor in the Scala
core libraries indeed? It kind of is, in the sense of a
for-comprehension, but I think you'd agree that this quite a feeble
attempt. Also, higher-kinds were not always part of the Scala
language. Much of the standard library reflects this e.g. List.flatMap
signature rather than a Monad type-class.

In order to get "extension" of Scala libraries, Scalaz uses implicits
to emulate type-classes. For example, Scalaz has an "instances" of the
"Functor" type-class for scala.List and java.util.LinkedList for that
matter.

This way, it needn't depend on any processes in the Scala core library
and so can introduce abstractions quickly. There has also been
demonstrated and unshakable aversion to abstraction and reusability by
some members the Scala community. I suspect this is due to "fear of
the unknown" so to speak, so I wanted to side-step this completely.

I'd love to see much of Scalaz in the core mostly so the Scala core
library is more complete and useful, but I very much doubt it will, or
we might see some watered-down version, which would be worse than
nothing in my opinion.

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkorHTYACgkQmnpgrYe6r62NNACgsnHk36KTqpieSgoD5FRghu07
GC4An1f9AMZ68FgcJfXuPlpjSc/0j66W
=Nt8h
-----END PGP SIGNATURE-----