Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Questions concerning modules as first-class values
Date: Fri, 04 Jun 2010 10:34:08 +0900 (JST)	[thread overview]
Message-ID: <20100604.103408.51384535.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <4C07CAB4.3060803@frisch.fr>

From: Alain Frisch <alain@frisch.fr>
> On 02/06/2010 19:36, Eric Cooper wrote:
>> Is it possible to marshal and unmarshal these packages?
> 
> Yes, this is possible, but:
> 
> 1. Extremely dangerous: there is no runtime type-checking. If you
> marshal a module, you need to unmarshal it to the same package type,
> exactly (no coercion allowed).
> 
> 2. Rather useless: the code for functions within modules is not
> marshaled (as for regular functions). If you marshal a module that
> define functions, you need to unmarshal it in the same program.
> 
>> That might be a nice way to implement a plug-in architecture.
> 
> Given the points above, I don't think so!

While marshalling of first-class modules is indeed not a good idea, I
think that dynamic loading of first-class modules might provide a nice
plug-in architecture.
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.

There is however a difficulty if you want to save and load data used
by these plugins uniformly. Namely, even if all these plugins expose
some data with a type "t", the "t" is actually going to be different
in each, and the type system will enforce it. This is good, but it
will be seen as different for the same plugin in a different run of
the same application. So you need to do some standard hacking around,
having unique ids for each plugin, and some magic to recover the data.
Otherwise this seems a nice approach, easier than using objects, since
objects don't let you expose internal data of different types.
(Well, actually you can probably do this with objects too, using a
polymorphic method to encoding existential types in CPS style, but
this is going to be costly and not very natural.)

Jacques Garrigue


  reply	other threads:[~2010-06-04  1:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-02 13:14 Dario Teixeira
2010-06-02 13:43 ` [Caml-list] " Julien Signoles
2010-06-02 16:28   ` Alain Frisch
     [not found]   ` <21533_1275496091_o52GSC5l015052_4C068697.5050007@frisch.fr>
2010-06-02 17:36     ` Eric Cooper
2010-06-03 15:31       ` Alain Frisch
2010-06-04  1:34         ` Jacques Garrigue [this message]
2010-06-04  4:59           ` Alain Frisch
2010-06-02 14:05 Dario Teixeira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100604.103408.51384535.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox