caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
Cc: skaller@users.sourceforge.net, caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Delaying module initialization
Date: 29 Mar 2004 16:10:13 +1000	[thread overview]
Message-ID: <1080540612.4708.219.camel@pelican.wigram> (raw)
In-Reply-To: <20040329123654I.garrigue@kurims.kyoto-u.ac.jp>

On Mon, 2004-03-29 at 13:36, Jacques Garrigue wrote:
> From: skaller <skaller@users.sourceforge.net>
[]
Thanks for that long explanation!
Put in FAQ?

> > If dynamic loading is as Jacques suggests, then it would
> > seem mod_caml has a strange design..

> Here we enter another problem: ocaml has dynamic loading, but not
> auto-loading/initializing.  Looks like lots of people would want to
> have that: a module would be initialized only when one of its members
> is used. 

Yes: this seems to imply the modules are pre-linked instead
of loaded dynamically.

> This is _not_ a problem of dynamic loading, and this could
> actually change the semantics of the language,

Indeed, and Xaviers solution is the way to handle this, as in C++
where the trick originates and has an interesting encoding, but
the bottom line is: if you want to control 'initialisation order'
make the 'initialisation' a user defined function and call it.

> Without auto-loading, you end-up loading everything in your name
> space; so that would result in initializing all Perl modules if you
> are initializing them on load. Some workarounds have already been
> suggested to delay this initialization.

Indeed but it seems the wrong solution to pre-load every
module you might want to use. The only viable universal 
solution is to load dynamically the same way Perl itself does.

More precisely I'd envisage the following design:

(1) Core modules are linked statically. Example:
some module used for formatting HTML is likely
to be needed in every script.

(2) A user defined list of modules is loaded
at run time initially. This introduces a delay
processing user script in an HTML page, but it
will crash the processes early if there is a failure.

On some architectures, it may be possible to do this
ONCE and suspend the process, then fork the processs
for the client page, greatly speeding up service
of the client page by reducing initialisation
to copying on demand performed by the Virtual Memory
system. I don't know if Apache can do this ..

(3) Other modules are loaded on demand.
This should be used where there is some conditional
execution, and must be where there is dynamic module 
name determination. This technique is the least reliable,
but avoids loading modules that might not be used.

An interesting module set is: ones to handle differences
is the client browser. EG: a module to uniformly
handle generation of *different* HTML for Mozilla
or Internet Explorer.

Note by "load on demand" i do not mean 'pre-load
and initialise on use' .. that's a separable technique
that might be useful for (1) or (2) if there is a lot of 
'pieces' of initialisation needed for different functions, 
and a lot of functions, only some of which are likely to be used
in a given invocation.

The three kinds of module are specified:

(1) At mod_caml construction time in the
actual Ocaml namespace: static linkage.

(2) In a configuration file. Load time linkage.

(3) In the client HTML page. Run time linkage.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2004-03-29  6:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-26 16:59 Richard Jones
2004-03-26 17:26 ` Yamagata Yoriyuki
2004-03-26 18:44   ` Richard Jones
2004-03-26 19:05     ` Remi Vanicat
2004-03-27 10:19       ` Richard Jones
2004-03-27 11:18         ` Xavier Leroy
2004-03-27 11:21           ` Richard Jones
2004-03-27 15:47             ` skaller
2004-03-27 12:38           ` Benjamin Geer
2004-03-27 16:04             ` skaller
2004-03-28 10:34               ` Jacques Garrigue
2004-03-28 23:51                 ` skaller
2004-03-28 23:58                 ` skaller
2004-03-29  0:35                   ` skaller
2004-03-29  3:36                     ` Jacques Garrigue
2004-03-29  6:10                       ` skaller [this message]
2004-03-27 15:41           ` skaller
2004-03-26 21:10 ` skaller

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=1080540612.4708.219.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=garrigue@kurims.kyoto-u.ac.jp \
    /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;
as well as URLs for NNTP newsgroup(s).