From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA03415; Sat, 15 Mar 2003 16:53:34 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA03052 for ; Sat, 15 Mar 2003 16:53:18 +0100 (MET) Received: from viola.sinor.ru (viola.sinor.ru [217.70.106.9]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h2FFrHX09362 for ; Sat, 15 Mar 2003 16:53:17 +0100 (MET) Received: from sibnet.ru (tlg5-ppp84.sibnet.ru [217.70.116.84]) by viola.sinor.ru (8.12.8/8.12.3) with ESMTP id h2FFrDDC006086 for ; Sat, 15 Mar 2003 21:53:13 +0600 Received: by sibnet.ru id m18uDxY-001EpZC; Sat, 15 Mar 2003 21:52:32 +0600 (NOVT) Date: Sat, 15 Mar 2003 21:52:32 +0600 From: Max Kirillov To: caml-list@pauillac.inria.fr Subject: [Caml-list] globally valid symbols (was: Haskell-like syntax) Message-ID: <20030315215232.F5826@max.home> Mail-Followup-To: caml-list@pauillac.inria.fr References: <005d01c2e76f$92d0f8b0$2713f9ca@WARP> <20030314003336.D748@max.home> <20030315013056.C5826@max.home> <200303141301.59458.seth@cql.com> <20030315082727.E5826@max.home> <20030315105846.GA28233@fichte.ai.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030315105846.GA28233@fichte.ai.univie.ac.at>; from markus@oefai.at on Sat, Mar 15, 2003 at 11:58:46AM +0100 X-Sender: Max X-Spam: no; 0.00; kirillov:01 haskell-like:01 mli-files:01 initialized:01 reorder:01 side-effect:01 impure:01 haskell:01 compiler:01 side-effects:02 syntax:02 signatures:02 mottl:02 linking:02 modules:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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