From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id B03F8BC57 for ; Thu, 18 Mar 2010 12:10:50 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUBAKqmoUtRZ904mWdsb2JhbACDC5ghFQEBAQEBCAsKBxMipzWQSYEsgmJqBA X-IronPort-AV: E=Sophos;i="4.51,265,1267398000"; d="scan'208";a="59290903" Received: from queueout02-winn.ispmail.ntl.com ([81.103.221.56]) by mail4-smtp-sop.national.inria.fr with ESMTP; 18 Mar 2010 12:10:50 +0100 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100318111016.FCAN10950.mtaout03-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Thu, 18 Mar 2010 11:10:16 +0000 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20100318111015.XJFE2093.aamtaout03-winn.ispmail.ntl.com@romulus.metastack.com>; Thu, 18 Mar 2010 11:10:15 +0000 Received: from Tenor ([212.183.140.51]) (authenticated bits=0) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id o2IBA7nJ002423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Mar 2010 11:10:12 GMT From: "David Allsopp" To: "'Alain Frisch'" Cc: "'Dario Teixeira'" , References: <571731.77500.qm@web111510.mail.gq1.yahoo.com> <00d801cac5f9$474281f0$d5c785d0$@romulus.metastack.com> <4BA11E37.7000207@frisch.fr> In-Reply-To: <4BA11E37.7000207@frisch.fr> Subject: RE: [Caml-list] Lazy modules Date: Thu, 18 Mar 2010 11:10:06 -0000 Message-ID: <010c01cac68b$94c59150$be50b3f0$@romulus.metastack.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK+qu0W4jVyRrUM1k4vCbxZlbxqrALUbXjWAcuS8lsCijfh5g== Content-Language: en-gb Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77 X-Cloudmark-Analysis: v=1.1 cv=ZtHxNT4mZm3rCuM0SmWmgWxeBwJsziC8EqOrwwVkrhA= c=1 sm=0 a=8sW17jYxVu0A:10 a=IkcTkHD0fZMA:10 a=REMSLP8CWABxELGk_D0A:9 a=dtkpfLvPPmcj_fOjvgN89a63jI4A:4 a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Spam: no; 0.00; frisch:01 afaik:01 syntax:01 compiler:01 syntax:01 renames:01 toplevel:01 endline:01 runtime:01 sub-modules:01 runtime:01 functor:01 recursive:01 functors:01 functor:01 Alain Frisch wrote: > On 3/17/2010 6:42 PM, David Allsopp wrote: > > AFAIK local modules is a syntax extension not a compiler extension - = I > > expect (not looked at it) that the syntax extension simply alpha > > renames all the local module declarations to make them unique and = puts > > them globally... a very useful extension but no expressive power > > added. >=20 > This is not true. Local modules are not lifted in any way. This is not > simply a syntax extension. For instance, if the local module has > toplevel side-effects (e.g. a structure item like: let () =3D > print_endline "Hello"), then the side effect will occur every time the > local module is evaluated. I've muddled this with something else! I seem to have muddled a lot in = my post... :$ > At runtime, a structure is represented simply by a block with GC tag = 0, > exactly as a record or a tuple. The block contains dynamic components = of > the structure (values, sub-modules, exceptions, classes) in the order > given by its signature. Evaluating a structure simply evaluates its > runtime components a build the block. >=20 > A functor is represented as a function. >=20 > >The module system at present is a compile time feature (I think = that's > >universally true - even with weird things like recursive modules) - > >functors are simply a way of introducing more modules so there is no > >runtime overhead in using a functor. >=20 > Modules and functors are much more dynamic than what you believe. The > introduction of first-class module did not require any change in the = way > modules are compiled. >=20 > A local module which is a functor application really applies the = functor > at runtime and evaluates the functor body every time the local module > expression is evaluated. Live 'n learn - thanks for the correction! David