Re: [Caml-list] Deriving + type-conv + OCaml-Templates + camlp4* = ?

["Markus Mottl" <markus.mottl@gmail.com>]

On Wed, Feb 27, 2008 at 5:56 AM, Jeremy Yallop <jeremy.yallop@ed.ac.uk> wrote:
>  > I think that different projects have different trade-offs that are
>  > hard, if not impossible, to combine.
>
>  I fear that you may be right, although (as the author of deriving) I'd
>  be more than happy to consider collaboration, given a concrete proposal.

We'd certainly be very happy to have a general framework for deriving
code from type definitions, since we (Jane Street Capital) have been
using this idea very successfully in our projects.  Having written two
complete and fairly complex libraries of that kind, I found that the
overlap between them was so small that it almost doesn't count in
comparison to the total effort required.  Thus I'm rather skeptical
that a general purpose library for type-derived code will be possible
without giving up on performance, but I'd surely like to be
surprised....

>  This is a little more surprising, since completeness *is* a focus of
>  deriving.
>
>  If I understand you rightly, then the case you mention is actually
>  handled: are you referring to using deriving with a polymorphic variant
>  type that extends another, such as
>
>     type a = [`A]
>     type ab = [a|`B]

Right.

>  This sort of thing is certainly handled; indeed, deriving handles
>  considerably more complicated cases as well, e.g. involving various
>  sorts of recursion:

Ok, I possibly misremembered something.  Sorry about that.

Sexplib treats this issue (inherited polymorphic variant types) by
using backtracking.  This has the advantage of a clear semantics
concerning which type converter will be used if types overlap (always
the first one left-to-right).  This doesn't seem to be the case with
some Deriving generators, but this may not be a big deal there.

>  To avoid giving the impression that deriving is absolutely complete, I
>  should mention that nested (i.e. irregular) types are not handled.  This
>  is in some ways a limitation of the approach of using modules for
>  recursion.  I don't think this limitation is significant for most
>  people, but I may look into adding support at some point.

This is surely a very minor limitation.  I can't remember the last
time I encountered irregular types in real life.  Sexplib seems to
support them, though one has to pass the -rectypes flag to the
compiler, of course.

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com