From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA00314 for caml-red; Sat, 7 Oct 2000 12:24:53 +0200 (MET DST) 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 MAA17706 for ; Sat, 7 Oct 2000 12:24:42 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e97AOeT03704; Sat, 7 Oct 2000 12:24:40 +0200 (MET DST) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA00163; Sat, 7 Oct 2000 12:24:40 +0200 (MET DST) From: Pierre Weis Message-Id: <200010071024.MAA00163@pauillac.inria.fr> Subject: Re: WWW Page of Team PLClub (Re: ICFP programming contest: results) In-Reply-To: <20001007115553.A24398@miss.wu-wien.ac.at> from Markus Mottl at "Oct 7, 100 11:55:53 am" To: mottl@miss.wu-wien.ac.at (Markus Mottl) Date: Sat, 7 Oct 2000 12:24:40 +0200 (MET DST) Cc: caml-list@inria.fr X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: weis@pauillac.inria.fr > Markus Mottl wrote: > On Sat, 07 Oct 2000, Pierre Weis wrote: > > Also consider that the Caml Light compiler does not optimize and > > symbolycally manipulate programs: that's devoted to the next ``tour de > > force'', the Objective Caml optimizing compiler, which does not use > > the De Bruijn indices notation for lambda terms... > > This sounds interesting! - May I ask what optimisations are considered? Classical: inlining, type-directed optimizations for primitives, compile time beta-reductions, constant folding, ... A bit more hairy: direct calls to functions (including curried functions and functions whose argument is a tuple), 0-cfa like analysis to access globals in modules, ... Xavier is the right man to tell you what's going on inside the compiler, but you can also read the compiler's source files ... > Will there be documentation for the (new) intermediate representation on > which optimisations operate? It would be really important to have > information about side effects there, too. Yes, you need a purity analysis for some of those optimizations... > I could imagine playing around with such representations in LambdaProlog > (extremely convenient for prototyping transformation systems). I don't know > whether anything useful will come out, but it may be fun - for others as > well. I'm sure many people will be interested at reading your code and conclusions about implementing transformations in Lambdaprolog ... Best regards, Pierre Weis INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/