Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] partial eval question
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-02-05 (21:29)
From: Walid Taha <taha@c...>
Subject: Re: [Caml-list] partial eval question

Hello Andrew,

On Wed, 4 Feb 2004, Andrew Lenharth wrote:

|> OK.  There is an article specifically about this point:
|> (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<any constant>.
|> |
|> |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.


|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?


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: