From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id B4290BBAF for ; Fri, 4 Jun 2010 03:34:12 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMGAOf0B0yFBoIF/2dsb2JhbACSIo0GsFmOMAEEhRaDSg X-IronPort-AV: E=Sophos;i="4.53,358,1272837600"; d="scan'208";a="60589062" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail1-smtp-roc.national.inria.fr with ESMTP; 04 Jun 2010 03:34:11 +0200 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 1C5E7B6F3 for ; Fri, 4 Jun 2010 10:34:09 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (camel-172 [172.16.254.4]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id D38D888AD for ; Fri, 4 Jun 2010 10:34:08 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=math.nagoya-u.ac.jp; h= date:message-id:to:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=alpha; bh=HjPm0CzYuUpADmxn//H7DVu1Dc8=; b=gPJ50yOdWYxxMVItvQOsXn1rBfgG 96Ko+sVO+slfRCWBp6chPNXO26cKe3pMNPEnPT52Sv25LRUVdOpEk8XRXpcOQwDm np/rfEezvWthkwLFL8yOjrajcgxjLjOMPVpsyzggiOWESo3fPbIZVKJ9Oe3HSzUD rDRQ2b25Kd1bze0= DomainKey-Signature: a=rsa-sha1; h=Received:Date:Message-Id:To:Subject:From:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; b=A2tnXSOOslMmTtR/Dvgnfm2piWlrvPkgnSj+Byy01xZeFS0Ux8prsfgaHVadFGEvhxM/EiBRoSWlShjsBWABso0LGNTkvoqQ7NkdVug5wF4oPsextIDVxGO0KvTysepLnHlcl0KKHiqK/9GEs3NRaKGHM9JATRxA5cYSEAqEcAI=; c=nofws; d=math.nagoya-u.ac.jp; q=dns; s=alpha Received: from localhost (bsdserver02 [172.16.249.2]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id BC8DD88AB for ; Fri, 4 Jun 2010 10:34:08 +0900 (JST) Date: Fri, 04 Jun 2010 10:34:08 +0900 (JST) Message-Id: <20100604.103408.51384535.garrigue@math.nagoya-u.ac.jp> To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Questions concerning modules as first-class values From: Jacques Garrigue In-Reply-To: <4C07CAB4.3060803@frisch.fr> References: <21533_1275496091_o52GSC5l015052_4C068697.5050007@frisch.fr> <20100602173618.GD23344@localhost> <4C07CAB4.3060803@frisch.fr> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; frisch:01 frisch:01 runtime:01 marshaled:01 marshalling:01 plug-ins:01 uniformly:01 existential:01 plug-in:98 plug-in:98 polymorphic:01 wrote:01 abstract:01 caml-list:01 functions:01 From: Alain Frisch > 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