Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Questions concerning modules as first-class values
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-06-04 (04:59)
From: Alain Frisch <alain.frisch@l...>
Subject: Re: [Caml-list] Questions concerning modules as first-class values
On 04/06/2010 03:34, Jacques Garrigue wrote:
> For instance, you can easily build a list of such plug-ins, with an
> uniform interface, and add elements to this list through dynamic
> loading. They can even expose internal data, with an abstract type.


That's basically our primary use of first-class modules at LexiFi. Our 
application maintains several sets of extensible notions (like 
"instruments" or "models") and it can load plugins which can register 
new such objects. Roughly speaking, each instrument is represented as a 
first-class module of type (module S) which looks like:

module type S = sig
   type t            (* the type of parameters for the instruments *)
   val t: t ttype    (* a dynamic representation of the type t *)
   val name: string  (* name to identify this instrument, presented
                        in a menu to the end-user *)
   val run: t -> contract (* build a fresh contract, which is a notion 
independent from the instrument *)

   type attrs   (* the type of attributes for this instrument *)
   val attrs: attrs ttype (* dynamic representation of attrs *)
   val compute: t -> contract -> attrs (* calculate attributes
                                    from initial parameters and
                                    a contract with history *)

   (* ... *)

The idea is that each instrument defines a number of abstract types 
(parameters, attributes) and operations on these types. It also exports 
values that gives the concrete structural representation of these 
abstract types (the 'a ttype components above) to enable generic 
operations such as automatic generation of GUI for showing/editing 
values of these types, or safe marshaling.  These "type" values can be 
derived automatically from the actual type definitions (either with a 
syntax extension, or with a compiler modification in our case).