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 NAA31631; Thu, 6 May 2004 13:17:31 +0200 (MET DST) 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 NAA31522 for ; Thu, 6 May 2004 13:17:30 +0200 (MET DST) Received: from ptb-relay02.plus.net (ptb-relay02.plus.net [212.159.14.213]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i46BHTEV032456 for ; Thu, 6 May 2004 13:17:29 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay02.plus.net with esmtp (Exim) id 1BLgsZ-000GaO-H8 for caml-list@inria.fr; Thu, 06 May 2004 11:17:27 +0000 From: Jon Harrop Organization: University of Cambridge To: caml-list@inria.fr Subject: Re: [Caml-list] Functors Date: Thu, 6 May 2004 12:16:53 +0100 User-Agent: KMail/1.5.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405061216.53738.jdh30@cam.ac.uk> X-Miltered: at nez-perce with ID 409A1EC9.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 functors:01 2004:99 brogoff:01 functor:01 functorised:01 inlined:01 statically:01 statically:01 lower-level:01 downsides:01 compiler:01 compiler:01 compilers:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wednesday 05 May 2004 21:41, brogoff@speakeasy.net wrote: > I'm not sure I understand the difference, since there is only one > defunctorizer for OCaml, wouldn't including it in the compiler be the > easiest way to get that functionality? As someone else said, using a "defunctorizer" apparently makes it impossible to perform some static analysis. Obviously, static analysis is a strong point of the language so we definitely want to keep that. I think this is an example of the static analysis being broken: use the core library Set functor to create a module implementing a set of integers, create two sets and merge them. If this were functorised, the integer compare could be inlined (which would probably result in a significant performance boost) but it would no longer be possible to statically check that the two sets being merged shared a common comparison function (which could be done statically before provided they were both created by our "integer set" module) because you can't compare functions. So you don't want to just plug the defunctorizer into the compiler. I was suggesting the application of much lower-level code transformations (at intermediate- or assembler-representations) when possible, to in-line small functions slightly more aggressively. I think this would be very useful, probably quite easy to implement and I can't think of any downsides. > ... I would have thought that a bytecode->C compiler would be quite feasible and, perhaps, quite useful. What other compilers for ocaml are there? Cheers, Jon. ------------------- 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