scalaz and boilerplate

[Stefan Hoeck]

Dear all

Below are several more or less related questions. Feel free to answer only part of them (if any).

In a personal project I work with a quite complex data model consisting of dozens of (at times deeply) nested case classes. For all of these I have to implement several type classes such as Equal, Arbitrary (from scalacheck), Ordered (sometimes), Monoid (sometimes) and so on. All of these have in common that when they are defined for all the types of the case classe's fields, implementing them is trivial but cumbersome. Now my first question is: Is there a way to reduce the amount of boilerplate involved with these type class definitions? I know that they are typically defined for the corresponding tuples, so if I can define the trivial isomorphism between my case class and the corresponding tuple, the other type class instances could be derived implicitly from there. Is this possible in scalaz7?

What I am talking about here is something similar to the following code:

   case class MyCaseClass (f1: String, f2: String)

   implicit val MyCaseClassAsTuple: Isomorphism[MyCaseClass,Tuple2] = ...

   val MyCaseClassEqual = implicitly[Equal[MyCaseClass]]


Another approach towards the same problem is provided by the shapeless library, where instead of tuples one has to provide isomorphisms to HList's. Deriving type classes like Equal or Monoid from an implicit isomorphism to an HList is trivial. Again, is it possible to do that in scalaz 7? I know there is an HList implementation but I couldn't find mechanisms similar to the ones in shapeless.

Since Scala 2.10 is about to be released I also wonder how macros will be able to help us here. I have no experience with them so far but still would like to know whether they will provide a simple way to derive the type class implementations mentioned above automatically. Also: Do the scalaz developers have other plans to exploit this new language feature?

An finally: The above questions also could have been asked for lenses, another source of somewhat annoying boilerplate. I know about the Lensed compiler plugin (though it seems to work only for scalaz 6 lenses) and again shapeless provides a neat way to define lenses via isomorphisms to HLists. Once more: Is this also possible in scalaz or are there plans to implement some similar functionality?

Thank you for your time

Stefan

[Jason Zaugg]

Firstly, It's truly impressive how far Miles has gotten *without*
macros in Shapeless for type class derivation. That said, I have a
feeling that macros might be a bit more straight forward for some of
these things.

I'm definitely going to explore this in the future. But the payoff
isn't immediate, as it will take some time for Scala 2.10 to be
released and adopted. (And for us to release Scalaz 7, it would seem!)

-jason

[Miles Sabin]

On Thu, Sep 27, 2012 at 7:26 AM, Jason Zaugg <jza...@gmail.com> wrote:
> Firstly, It's truly impressive how far Miles has gotten *without*
> macros in Shapeless for type class derivation. That said, I have a
> feeling that macros might be a bit more straight forward for some of
> these things.
>
> I'm definitely going to explore this in the future. But the payoff
> isn't immediate, as it will take some time for Scala 2.10 to be
> released and adopted. (And for us to release Scalaz 7, it would seem!)

(cross posting to shapeless-dev@, followups to scalaz@ please :-)

I agree that macros will make some things easier, but I don't think
they'll make the techniques used in shapeless redundant. On the
contrary, I think they'll make them even more practically applicable:
I'm particularly excited about the possibility of using implicit
macros to produce compile time witnesses (eg. of arithmetic
propositions) with tractable compile times and without runtime
overhead. And let's not forget runtime compilation: in some ways I
think this might be even more important both for shapeless and scalaz
... runtime selection of type class instances via lightweight staging
opens up all sorts of interesting possibilities.[1]

I've been reluctant for shapeless to have any dependencies at all, so
that I have complete freedom to track Scala master without having to
worry about the availability of compatible builds of dependencies ...
this, even to the extent of using only JUnit for tests. But I'm now
thinking that, once 2.10.0 is out of the door, this reason isn't quite
so strong. And if scalaz wants to pursue applications of macros
energetically, then I expect that both projects will be wanting to
track Scala master post 2.10.0 in much the same way.

For the future I definitely want to avoid things like the "pedagogic
subset of the Scalaz monoid" that I used to illustrate
(almost-)automatic type class derivation[2]. And I'd love to see
something like the project that Travis Brown suggested on Stack
Overflow[3] get off the ground.

So I'd like to see if we can work out some way for shapeless and
scalaz to collaborate more, while leaving both projects free to pursue
their own distinctive agendas.

I'd love to hear everyone's thoughts on this.

Cheers,


Miles

[1] https://github.com/milessabin/shapeless/blob/master/examples/src/main/scala/shapeless/examples/staging.scala
[2] https://github.com/milessabin/shapeless/blob/master/examples/src/main/scala/shapeless/examples/monoids.scala
[3] http://stackoverflow.com/questions/12426269/round-up-of-scalaz-type-class-instances-for-other-libraries

--
Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: mi...@milessabin.com
g+: http://www.milessabin.com
http://twitter.com/milessabin

[Lars Hupel]

> For the future I definitely want to avoid things like the "pedagogic
> subset of the Scalaz monoid" that I used to illustrate
> (almost-)automatic type class derivation[2]. And I'd love to see
> something like the project that Travis Brown suggested on Stack
> Overflow[3] get off the ground.
>
> So I'd like to see if we can work out some way for shapeless and
> scalaz to collaborate more, while leaving both projects free to pursue
> their own distinctive agendas.

There might be some space for that, e.g. by creating a shapeless-scalaz
or scalaz-shapeless submodule tracking both libraries. Such an "interop"
library could convert between the two different `HList` implementations
and could automatically derive instances using Miles' machinery.

It seems that there has recently been some momentum in the intersection
of shapeless and scalaz. (See, for example, Eugene's latest approach to
simplify the use of products.)

In conclusion, I'd definitely like to pursue this path, and will most
likely do so when I'm back from vacation.

[Tony Morris]

I, for one, would love to see shapelezz.

--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To post to this group, send email to sca...@googlegroups.com.
To unsubscribe from this group, send email to scalaz+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scalaz?hl=en.

[Stefan Hoeck]

Definitely. I always thought that the two libraries were somehow related. It just felt natural.

Stefan