From: Xavier Leroy <xavier.leroy@inria.fr>
To: caml-list@inria.fr
Subject: [Caml-list] recursive modules
Date: Mon, 5 May 2003 10:21:21 +0200 [thread overview]
Message-ID: <20030505102121.B23988@pauillac.inria.fr> (raw)
Since the issue of recursive modules has (again) popped up on this
list, it seems that now is a good time to announce an experimental
design and implementation for recursive modules in OCaml that I've
been working on lately. A note describing the design is at
http://cristal.inria.fr/~xleroy/publi/recursive-modules-note.pdf
and the implementation can be downloaded from the CVS repository
on camlcvs.inria.fr, tag "recursive_modules".
What this extension provides is a "module rec ... and ..." binding
that allows the definition of mutually-recursive modules within the
same compilation units. Recursion between compilation units is a
different problem that is not adressed yet. To give a flavor of the
extension, one can write for instance
module A : sig
type t = Leaf of string | Node of ASet.t
val compare: t -> t -> int
end
= struct
type t = Leaf of string | Node of ASet.t
let compare t1 t2 =
match (t1, t2) with
(Leaf s1, Leaf s2) -> Pervasives.compare s1 s2
| (Leaf _, Node _) -> 1
| (Node _, Leaf _) -> -1
| (Node n1, Node n2) -> ASet.compare n1 n2
end
and ASet : Set.S with type elt = A.t
= Set.Make(A)
The other point worth mentioning is that the detection of ill-founded
recursive definitions (definitions that have no fixpoint in a
call-by-value evaluation regime) is not completely static and may
cause an "Undefined" exception to be thrown at program initialization
time. Fully static prevention of ill-founded recursion would, in the
current state of our knowledge, either rule out too many valuable
uses, or require major complications in the type system. The proposed
approach is a pragmatic compromise rather than a 100% intellectually
satisfying solution.
No decision has been taken yet concerning the possible integration of
this extension in a future release of OCaml.
Comments and feedback are most welcome, as long as they are of the
constructive kind.
- Xavier Leroy
-------------------
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
next reply other threads:[~2003-05-05 8:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-05 8:21 Xavier Leroy [this message]
2003-05-05 11:29 ` Markus Mottl
2003-05-16 16:31 ` brogoff
2003-05-05 12:20 ` John Max Skaller
2003-05-05 16:59 ` brogoff
2003-08-29 20:17 [Caml-list] Recursive Modules Christopher Dutchyn
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=20030505102121.B23988@pauillac.inria.fr \
--to=xavier.leroy@inria.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