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

[Jeremy Yallop <jeremy.yallop@ed.ac.uk>]

Markus Mottl wrote:
> On Tue, Feb 26, 2008 at 3:27 PM, David Teller 
> <David.Teller@ens-lyon.org> wrote:
>> Browsing around the net, I've found three 
>> "scrap-your-boilerplate"-style projects for OCaml: the simple 
>> Type-conv, the ambitious Deriving and the unmaintained 
>> OCaml-Templates, and of course the ability to use camlp4/camlp5 for
>>  the same purpose. I imagine that there are a number of nice 
>> boilerplate-based modules just waiting to be implemented or 
>> adopted.
>> 
>> As far as I understand, there's no interaction between the project 
>> authors, which is a shame. So this is an open call to whoever is in
>> charge of each work: do you think it would be possible for you all
>> to join forces and produce something robust, simple and possible to
>> adopt as a standard ?
> 
> 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.

> Deriving is a very elegant, general approach, but last time I checked
>  it would be hard to generate highly optimized code with it,

Thanks for the kind words!  I expect you're right about generating
optimized code; as you suggest this hasn't been a focus.  Performance of
generated code should be at least reasonable, though, and it is possible
to substitute handwritten code at critical points, as with any such
approach.

> and it was also not complete (e.g. handling hard cases like
> polymorphic variants with inherited types, etc.).

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]

?

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

    type ('a,'b) x = [`One of 'a | `Two of 'b]           deriving (Show)
    type 'a y = [`Four of ([('z,'a) x | `Three] as 'z)]  deriving (Show)
    type z = z y                                         deriving (Show)

    let _ = print_endline (Show.show<z>
                            (`Four (`One (`Two (`Four `Three)))))

In fact, the way that deriving treats structural types with inline 
recursion (i.e. the "as" syntax) is perhaps an example of a difficulty 
in combining projects: deriving converts types into a normalized 
representation in which this recursion is shifted to the type 
declaration level: a sort of ANF for types.  This works well (and makes 
it much easier to write new generic functions, since it removes the need 
to deal with "as"), but might be a little heavyweight for projects with 
other focuses.

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.

Jeremy.