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.
Indeed!
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 *)
(* ... *)
end
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).
Alain
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
