[Caml-list] "Open" generics?

[Caml-list] "Open" generics?

[Markus Mottl]

Hi,

I've recently been studying some of the nifty encodings for
tagless-final interpreters, generics, and open GADTs, especially this
one:

  http://okmij.org/ftp/ML/first-class-modules/index.html#generics

This encoding of type representations seems particularly elegant.
Given a value of type ('a repr) representing some type ('a), you can
obtain a functor that can be instantiated with arbitrary interpreters
for this type.  You can then define functions like the following with
great ease:

  val show : 'a repr -> 'a -> string
  val compare : 'a repr -> 'a -> 'a -> bool

However, unless I'm mistaken, this particular approach seems to be
suffering from one shortcoming: the representation of types cannot be
open.  One apparently cannot reuse already existing structured types
and add e.g. new base types to them without having to duplicate
(literally cut&paste) code.

For example, this is the definition I use for representing the type of "pairs":

    let pair (type a) (type b) ((module A) : a repr) ((module B) : b repr) =
      ((module struct
        type t = a * b
        module Interpret (I : Interpretation) = struct
          module AI = A.Interpret (I)
          module BI = B.Interpret (I)
          let res = I.pair AI.res BI.res
        end
      end) : (a * b) repr)

Lets assume the signature "Interpretation" supports type
representations for integers and pairs:

  type 'a t
  val int : int t
  val pair : 'a t -> 'b t -> ('a * 'b) t

The module returned by function "pair" contains a functor "Interpret"
for interpreting types - but only for the "Interpretation" supporting
"int" and "pair".  Lets assume I wanted to add a new base type:

  val string : string t

The only way I have managed to do this is by copying&pasting the above
definition for "pair" into a context where the signature
"Interpretation" also contains the definition for "string".

This just doesn't feel right.  It seems there must be some way of
avoiding this annoying code duplication.  Has anybody (Oleg?  Jeremy?
;) ever played with these encodings and found a solution to this
problem?  This would be awesome for defining extensible type
representations.

Best regards,
Markus

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