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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 02DE7BC57 for ; Wed, 17 Mar 2010 18:43:01 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQBAL+xoEtRZ90xkWdsb2JhbACDC5d9FQEBAQEJCwoHEwMfqhWQO4EsgmBqBA X-IronPort-AV: E=Sophos;i="4.49,658,1262559600"; d="scan'208";a="55464635" Received: from mtaout03-winn.ispmail.ntl.com ([81.103.221.49]) by mail1-smtp-roc.national.inria.fr with ESMTP; 17 Mar 2010 18:43:00 +0100 Received: from aamtaout01-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 <20100317174259.HESX10950.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Wed, 17 Mar 2010 17:42:59 +0000 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20100317174259.KMFG13254.aamtaout01-winn.ispmail.ntl.com@romulus.metastack.com>; Wed, 17 Mar 2010 17:42:59 +0000 Received: from Tenor ([172.16.0.8]) (authenticated bits=0) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id o2HHgtMm024712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Mar 2010 17:42:56 GMT From: "David Allsopp" To: "'Dario Teixeira'" , References: <571731.77500.qm@web111510.mail.gq1.yahoo.com> In-Reply-To: <571731.77500.qm@web111510.mail.gq1.yahoo.com> Subject: RE: [Caml-list] Lazy modules Date: Wed, 17 Mar 2010 17:42:55 -0000 Message-ID: <00d801cac5f9$474281f0$d5c785d0$@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+qu0W4jVyRrUM1k4vCbxZlbxqrALUbXjW 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=1ggfb5FlKZQUfF3vzm9UBYZ2uTfLsbs/8dSljwg5+mE= c=1 sm=0 a=8sW17jYxVu0A:10 a=IkcTkHD0fZMA:10 a=nOQ_vVFzf1mTHQl32ygA:9 a=qoRKPiP77rFESI2xnhiCJci2ET8A:4 a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Spam: no; 0.00; semantics:01 runtime:01 ocaml:01 functor:01 sig:01 afaik:01 syntax:01 compiler:01 syntax:01 renames:01 sig:01 struct:01 sockaddr:01 sockaddr:01 foo:01 Dario Teixeira wrote: > I've come across a problem which though novel to me, I presume must be > familiar to those with more ML baggage. Namely, I need a module whose > values are not known at the initialisation stage, since they can only = be > determined after reading a configuration file. If this were a lone > value, I would declare it as a lazy value which when forced would read > from the configuration file. But how can I achieve similar semantics > with a whole module? I've hit this similarly with databases - if for example you have a = signature DB and modules, say, OracleDB, MSSQLDB, PostgresDB. What I'd = wanted in the past is a module DB which is one of those three but = determined at runtime when a configuration file is loaded. I couldn't = find a satisfactory solution with OCaml 3.09 at the time which didn't = involve recompiling on each change. > I do have a solution which though hackish and relying on a language > extension (local modules) seems to work: I create the module on demand > via a functor parameterised over an empty sig: 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 > module Socket_maker (S: sig end) : Client.SOCKET =3D struct > let sockaddr =3D !Config.sockaddr > let sockdomain =3D !Config.sockdomain > let socktype =3D !Config.socktype > let sockproto =3D !Config.sockproto > end >=20 > let foo =3D > let module Socket =3D Socket_maker (struct end) in > ... >=20 > But I wonder a) what's the penalty associated with the runtime > application of the functor, and 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. There are I believe some = performance overheads in using modules if you care about speed as some = optimisations in ocamlopt can't happen across module boundaries. My = impression has been that if you're that worried about these slight = performance hits then maybe OCaml is the wrong language for you :o) > b) if there's some better way of doing this. Any thoughts? I believe that the module system due for OCaml 3.12.0 will allow this = kind of runtime application of functors as modules are first class = values. Hope that's helpful - the inability to do what you're wanting to do is = one of the reasons that I've never delved deeply into the module system = - powerful as it may be, it didn't seem to be able to help performing a = simple task (similar to yours) that I wanted it to do (I have also in = the past wanted to exactly what you're doing - i.e. a module of loaded = configuration values). David