caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Walid Taha <taha@cs.rice.edu>
To: Andrew Lenharth <alenhart@cs.ohiou.edu>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] partial eval question
Date: Thu, 5 Feb 2004 15:29:42 -0600 (CST)	[thread overview]
Message-ID: <Pine.LNX.4.44.0402051512540.27241-100000@boromir.cs.rice.edu> (raw)
In-Reply-To: <20040204055326.GA2617@peuter>


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

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


  reply	other threads:[~2004-02-05 21:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-27  1:41 Ben Kavanagh
2003-10-27  7:14 ` Damien
2003-10-27 15:39   ` William Chesters
2003-10-27 18:50     ` Andrew Lenharth
2003-10-27 19:12       ` William Chesters
2003-10-27 20:08         ` Jacques Carette
2004-02-04  3:03           ` Walid Taha
2003-10-27 22:11         ` Andrew Lenharth
2004-02-04  2:59       ` Walid Taha
2004-02-04  5:53         ` Andrew Lenharth
2004-02-05 21:29           ` Walid Taha [this message]
2003-10-27 19:17     ` Yann Regis-Gianas
2003-10-28 10:46       ` William Chesters
2004-02-04  2:22         ` Walid Taha
2004-02-04  2:56     ` Walid Taha
2003-10-28 15:09   ` Dmitry Lomov
2003-10-27 15:16 ` Vincent Balat [prof Moggi team]
2004-02-04  2:51 ` Walid Taha
2004-02-04 10:26   ` Ben Kavanagh
2004-02-04 10:32   ` Ben Kavanagh
2004-02-05 21:11     ` Walid Taha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0402051512540.27241-100000@boromir.cs.rice.edu \
    --to=taha@cs.rice.edu \
    --cc=alenhart@cs.ohiou.edu \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).