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 WAA03243; Thu, 5 Feb 2004 22:29:51 +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 WAA02820 for ; Thu, 5 Feb 2004 22:29:49 +0100 (MET) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id i15LTnf08771 for ; Thu, 5 Feb 2004 22:29:49 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id 2CF3E4AAEF; Thu, 5 Feb 2004 15:29:48 -0600 (CST) Received: from cs.rice.edu ([127.0.0.1]) by localhost (cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17972-01-71; Thu, 5 Feb 2004 15:29:45 -0600 (CST) Received: from boromir.cs.rice.edu (boromir.cs.rice.edu [128.42.129.71]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by cs.rice.edu (Postfix) with ESMTP id 8403A4ABDD; Thu, 5 Feb 2004 15:29:43 -0600 (CST) Date: Thu, 5 Feb 2004 15:29:42 -0600 (CST) From: Walid Taha To: Andrew Lenharth Cc: caml-list@inria.fr Subject: Re: [Caml-list] partial eval question In-Reply-To: <20040204055326.GA2617@peuter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavis-20030616-p5 at rice.edu X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 well-typed:01 metaocaml:01 ad-hoc:01 metaocaml:01 escapes:01 runtime:01 keywork:01 well-typed:01 compiler:01 ocaml:01 ocaml:01 garbage:01 polymorphic:01 checking:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hello Andrew, On Wed, 4 Feb 2004, Andrew Lenharth wrote: |> OK. There is an article specifically about this point: |> |> http://www.cs.rice.edu/~taha/publications/preprints/2003-12-01.pdf |> |> (Comments are welcome, actually, the paper is undergoing the final |> revision). | |It is late, and I will more carefully read the paper tomorrow, but I |do have a couple of initial questions. | |With C++ templates I can implement optimizations based on data type, |as you mention in 4.1, and provide a default implementation to ensure |a well-typed function. Can I get the same from MetaOCaml? Really I |guess I am almost asking for ad-hoc polymorphism, but with a fall back |polymorphic implementation. No. Not in the current MetaOCaml, which is basically just OCaml + Brackets + Escape + Run As far as typing issues are concerned, there is an easy way to determine if something can be typed done in MetaOCaml or not: Erase your brackets, escapes, and run. If your program can't be typed in OCaml, it can't be typed in MetaOCaml. What you describe requires a change to the core type system, which MetaOCaml tries to keep unchanged. There are other research efforts that explore adding related changes to the core type system. If we have the resources, it would certainly be worthwhile to incorporating such changes into MetaOCaml. |Also, you say you can generate code at runtime, is the generated code |garbage collected? Not in the current (alpha) versions. Do I see a volunteer? :) |> |The C example relies on a fairly smart compiler to |> |do interprocedual analysis. The C++ example |> |only requires the inline keywork be honored, and you |> |don't need explicit pow3 pow2, you have pow<3> pow<2> |> |pow. |> | |> |Gives a bit more control over code generation. |> |> The draw back with C++ templates, in this case, is that you have to wait |> until the C++ code is generate before you know it type checks. A key goal |> of MSP is to ensure that generated code is *always* well-typed. That |> actually has been achieved in the context of a wide-range of type systems. | |I was a bit confused by this paragraph at first, but the paper |clarified it. I think you meant to imply that any code that could be |generated by MSP will be well-typed. Yes. |This is starting to sound like other type checking arguments :) It is |correct for every way it is used v.s. it is correct for every way it |could be used. I am not sure I understand what you are saying. Can you clarify? Walid. ------------------- 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