Browse thread
Deriving + type-conv + OCaml-Templates + camlp4* = ?
-
David Teller
-
Markus Mottl
- Jeremy Yallop
- Till Varoquaux
-
Markus Mottl
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jeremy Yallop <jeremy.yallop@e...> |
| Subject: | Re: [Caml-list] Deriving + type-conv + OCaml-Templates + camlp4* = ? |
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.