On Tue, Feb 03, 2004 at 08:59:57PM -0600, Walid Taha wrote:
> 
> On Mon, 27 Oct 2003, Andrew Lenharth wrote:
(CUT C and C++ version)
> |in what way exactly?  (If it doesn't work for you, try 
> |-O2) :)

Of course, after I posted this, I made a version that was much better.
Sigh.

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

Examples (in C++) may include generating code for vector units (SSE,
altivec, etc) for operations with known semantics (+, etc) if a type
in a vector is basic and falling back to calling the operator on
unknown types.  Similar thing for choosing a bitwise copy of a
container verses using the copy constructor of the members.

For such type optimizations I want

let t_eq x y = 
match (type x),(type y) with
  int,int -> int compare
| float,float -> float compare
| bool,bool -> (x && y)|| ((not x) && (not y))
| _,_ -> x = y

This is a silly example in that it only uses the mechanism to avoid
the runtime overhead for polymorphic functions, but it is late and I
hope you can understand what I am getting at.

Also, you say you can generate code at runtime, is the generated code
garbage collected?

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

Andrew

-- 
"The reasonable man adapts himself to the world; the unreasonable 
one persists in trying to adapt the world to 
himself. Therefore all progress depends on the unreasonable man."
-- George Bernard Shaw

No matter how cynical you become, it's never enough to keep up.
-- Lily Tomlin

Fools ignore complexity; pragmatists suffer it; experts avoid it; 
geniuses remove it.
-- A. Perlis

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