From: Christian Rinderknecht <rinderkn@pst.polyspace.com>
To: "David Mentré" <David.Mentre@irisa.fr>
Cc: caml-list@inria.fr
Subject: Re: How to cleanly encode "quasi-constants"?
Date: Thu, 22 Jun 2000 10:41:50 +0200 (MET DST) [thread overview]
Message-ID: <Pine.GSO.4.05.10006220919520.3542-100000@pst> (raw)
In-Reply-To: <wd8g0q8xs0o.fsf@parate.irisa.fr>
Hi David,
I think it's worth reading the caml-list thread "one-time initialization",
starting at http://caml.inria.fr/caml-list/1005.html.
Personnally, in the particular situation you mention, I would do the
following.
In a Second(ary) module you define a functor taking as argument a module
with all the globals you need.
second.mli
----------
module type S =
sig
type type0 = ...
val const0 : type0
end
module Run (Args : S) :
sig
val entry_point : unit -> unit
end
second.ml
---------
module type S =
sig
type type0 = ...
val const0 : type0
...
end
module Run = functor (M : S) ->
struct
open M
... (* From here you handle "real" constants" [const0] etc. *)
let entry_point () = ...
end
By the way, note that in OCaml, contrary to SML, you cannot define a
functor at top-level (this would require extra syntax), i.e. whose name is
mapped to a file name.
Now in your Main module:
main.ml
-------
module Args =
struct
type type0 = ...
let quasi_const0 : (type0 option) ref = ref (None)
...
let _ = Arg.parse .... (* Initialization by side-effects of
[quasi_const0] etc. *)
let const0 =
match !quasi_const0 with
None -> failwith "Missing arg" (* Or whatever *)
| Some (v) -> v
...
end
module Go = Second.Run (Args)
let _ = Go.entry_point ()
Note that name [Go] is necessary (Second.Run(Args).enty_point() does
not work).
Hope this helps,
Christian
--------------------------------------------------------------------
Christian Rinderknecht Christian.Rinderknecht@polyspace.com
PolySpace Technologies Tel: 04.76.61.54.17
c/o INRIA Fax: 04.76.61.54.09
655, Av. de l'Europe http://www.polyspace.com/
F-38330 Montbonnot St Martin
On 20 Jun 2000, David Mentré wrote:
> In my program, I have variables that can only be modified once
> (potentially at initialization time after parsing command line and done
> some computation) and then are never modified for a very long time (rest
> of program execution).
next prev parent reply other threads:[~2000-06-23 14:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-20 15:59 David Mentré
2000-06-22 8:41 ` Christian Rinderknecht [this message]
2000-06-22 20:46 ` Daniel de Rauglaudre
2000-06-23 14:27 ` Remi VANICAT
2000-06-26 10:19 ` Pierre Weis
2000-06-27 2:26 ` Julian Assange
2000-06-26 10:42 ` Daniel de Rauglaudre
2000-06-27 19:12 ` Brian Rogoff
2000-06-27 19:20 ` Daniel de Rauglaudre
2000-06-21 19:59 Don Syme
2000-06-28 16:40 Marcin 'Qrczak' Kowalczyk
2000-06-30 8:04 ` Daniel de Rauglaudre
2000-07-01 10:01 ` Julian Assange
2000-07-01 18:52 ` Brian Rogoff
2000-07-01 19:21 Marcin 'Qrczak' Kowalczyk
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=Pine.GSO.4.05.10006220919520.3542-100000@pst \
--to=rinderkn@pst.polyspace.com \
--cc=David.Mentre@irisa.fr \
--cc=caml-list@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