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 LAA09204; Tue, 28 Oct 2003 11:43:30 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA13708 for ; Tue, 28 Oct 2003 11:43:29 +0100 (MET) Received: from protactinium.btinternet.com (protactinium.btinternet.com [194.73.73.176]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h9SAhS117017 for ; Tue, 28 Oct 2003 11:43:28 +0100 (MET) Received: from host81-128-104-98.in-addr.btopenworld.com ([81.128.104.98] helo=beertje.william.bogus) by protactinium.btinternet.com with esmtp (Exim 3.22 #23) id 1AERJu-0007Lc-00; Tue, 28 Oct 2003 10:43:26 +0000 Received: by beertje.william.bogus (Postfix, from userid 501) id 4A04E9240D; Tue, 28 Oct 2003 10:46:24 +0000 (GMT) From: William Chesters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16286.18688.149948.39036@beertje.william.bogus> Date: Tue, 28 Oct 2003 10:46:24 +0000 To: caml-list@inria.fr Subject: Re: [Caml-list] partial eval question In-Reply-To: <200310272017.50686.yann.regisgianas@free.fr> References: <004a01c39c2b$819db8f0$1fcf2952@Archimedes> <20031027081453.37b9f6ee.Damien.Pous@ens-lyon.fr> <16285.15401.421786.814601@beertje.william.bogus> <200310272017.50686.yann.regisgianas@free.fr> X-Mailer: VM 7.04 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid X-Loop: caml-list@inria.fr X-Spam: no; 0.00; chesters:01 williamc:01 paneris:01 caml-list:01 yann:01 regis-gianas:01 inlining:01 unrolling:01 multi-stage:01 optimiser:01 metaml:01 tightly:01 infer:01 metaml:01 inlining:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Yann Regis-Gianas writes: > I agree with you that constant folding, inlining and unrolling are well known > by common compilers. However, when you want to _control_ these > optimisations, this is more difficult with standard optimizers since they are > black-boxes. That's a strength as well as a weakness. In reasonably simple cases it "just works" and is less effort, more readable, more maintainable. > By adding the multi-stage evaluation into a programming language, we obtain > one general, transparent and simple tool. Why should we develop or learn the > usage of many special-purpose optimizers ? Partial/abstract evaluation is a pretty general purpose optimiser. Half seriously: Metaml improves on C++ templates by making the metalanguage the same as and more tightly integrated with the object language. Partial evaluation can almost be seen as going a step further and having the compiler infer the tightest meta/object boundary. Perhaps if there was a way of telling the partial evaluator "specialise this code block by value of parameter i / type of parameter j / whatever" (*) it would handle all the everyday tasks for which metaml is designed, and require considerably less effort and expertise. (*) to get this effect with good current compilers you have to isolate the block in a function, turn up the inlining sufficiently, and use "if" branches to trigger specialisation > By adding the multi-stage evaluation into a programming language, > we obtain one general, transparent and simple tool. It's not simple or transparent, and for many tasks it isn't necessary. Perhaps it's a good general tool for the generation of code for numerics etc.---it may help specialist library writers. For everyday programming I think one has to remember that heavyweight attempts to achieve generality are often not worth it. Simple things can be done by the compiler or just written out by hand. Complex things look nasty when hand-optimised, but if you try to do them "better and more generally" using metaprogramming, you are likely to take much longer, and end up with something which is hard to decipher and disappointingly doesn't generalise in quite the way you want. There is little point in trading the "complexity" of prolix, irritating but basically straightforward hand-specialised code for the genuinely challenging complexity of a meta-programming system. (It really does become extremely complicated when you start taking into account the detailed requirements of real world problems.) The most viable option is often to settle on a reasonably general and extensible conceptual framework (at the level of conventions rather than anything more formal) and implement just the bits of it that you actually need for your particular problem, encapsulated in a consistent way. ------------------- 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