Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] recursive modules
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Markus Mottl <markus@o...>
Subject: Re: [Caml-list] recursive modules
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