caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Markus Mottl <markus@oefai.at>
To: Xavier Leroy <xavier.leroy@inria.fr>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] recursive modules
Date: Mon, 5 May 2003 13:29:11 +0200	[thread overview]
Message-ID: <20030505112911.GA15651@fichte.ai.univie.ac.at> (raw)
In-Reply-To: <20030505102121.B23988@pauillac.inria.fr>

On Mon, 05 May 2003, Xavier Leroy wrote:
> What this extension provides is a "module rec ... and ..." binding
> that allows the definition of mutually-recursive modules within the
> same compilation units.

This looks very promising indeed!

> Recursion between compilation units is a different problem that is
> not adressed yet.

I believe this shouldn't be such a big problem in practice, because one
can always functorize one module and tie the recursive knot elsewhere.

> To give a flavor of the extension, one can write for instance
[snip Set-example]

That's surely one of the major examples, where people really want (and
need) recursive modules.

> 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.

Guaranteed at program initialization time? But how about local modules?

> 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.

I personally could live with some dynamic checking of this sort. It's
always possible to improve static checking afterwards as long as the
language specification allows this in principle. The benefits of recursive
modules surely outweigh the drawbacks of some dynamic checking.

> No decision has been taken yet concerning the possible integration of
> this extension in a future release of OCaml.

This is of course a matter of how progressive (aggressive?) you want the
main distribution to be. I think that more exotic but otherwise usable
features in a distribution won't harm as long as they do not affect
normal work. Why not add this as usual to the "language extensions"
section of the manual?  People who want to be on the safe side are not
forced to use anything that's in there.

This would make it much easier to get feedback, because only few people
are daring enough to test things with some CVS-branch.

Regards,
Markus Mottl

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
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:[~2003-05-05 11:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-05  8:21 Xavier Leroy
2003-05-05 11:29 ` Markus Mottl [this message]
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=20030505112911.GA15651@fichte.ai.univie.ac.at \
    --to=markus@oefai.at \
    --cc=caml-list@inria.fr \
    --cc=xavier.leroy@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;
as well as URLs for NNTP newsgroup(s).