On Sat, Mar 15, 2003 at 11:58:46AM +0100, Markus Mottl wrote:
> Things are not this easy: the order is actually required for linking,
> not for compiling (as long as you provide explicit signatures in
> .mli-files).  The order during linking determines in which order side
> effects will be caused when values are initialized, which only the user
> can know. Furthermore, the "mutually recursive modules"-problem is more
> of a typing problem than one of compilation.

Writing a programming language is usually considered as a diffucult
task...:). The linking problem is not unsolvable. I believe it's a
matter of political choice. For example there are the following way
(that's just an idea): most meaningful side effects are unnamed
(let _ = or let () =), so there's no need to reorder them, and most
side-effect in evaluting the named values are some initialization, the
order of which is not important. So, compiler might safely reorder the
named values definitions (considering only the side-effects, not the
binding, so function declarations would be untouched) and preserve the
order of unnamed code pieces (that is always possible). There could be
an option to warn user when the compiler have to reorder some
impure value definitions.

In fact, only few of real life modules doing something during
initialization, so it could not be a real trouble. 

Typing of recursive modules might be a problem. But, I think it's not
fatal. At least, haskell has a way to do that. Well, when developer need
to solve 2 problem to do something, he is more likely to reject any
action when one of the problems was already solved.

-- 
Max

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