Interpret haskell within haskell.

[Matt Hellige]

[Christopher Milton <cmiltonperl@yahoo.com>]
> --- David Sankel <camio@yahoo.com> wrote:
> > I was wondering if there is any project that aims to
> > interpret haskell within haskell.

[... snipped intro to ghci ...]

> If you have defined functions in "myprog.hs":
> :load myprog.hs
> then the functions defined in the file are available,
> or else you'll get error message(s) about problems
> found parsing "myprog.hs".
> 

I'm not sure this is quite what he's asking for. For many projects it
is useful to be able to dynamically (and programatically) load and
evaluate arbitrary chunks of code for one reason or another. I
previously inquired about using Haskell as an extension language,
which is one application of this idea. There are many others. The
ability to do this, and hopefully to do it in a simple, well-specified
(and well-integrated into the rest of the language) way is perceived
as a major benefit of using many high-level languages. The classic
example, obviously, is lisp, where constructs to do exactly this are
an integral part of the language's design.

So it seems natural, especially to new users, to hope that Haskell and
the ML variants, sharing many other features common to these
languages, would offer this facility as well. The answer, in general,
is that they do not.

In many ways, this is a shame. In languages that support it cleanly,
the ability to parse, manipulate and evaluate programs in an abstract,
reflective way is wonderful. I suppose there's no need for examples,
but I'd be happy to argue the point if there's disagreement. :)

I know that I personally would love it if, as part of the language
definition, Haskell and ML provided the ability to do these types of
things.

I'm not sure that I really understand all the reaons why this hasn't
been done. I have some ideas, and I'd be very curious to know how far
off the mark they are... In fact, I think this would make a wonderful
Not-so-frequently Asked Question for the Wiki, if we could get
together a good list of reasons why this is hard/inappropriate for
Haskell. (If we can't, I nominate it to go into Haskell 2... :)

In any case, here are my guesses at why Haskell doesn't have "eval":
 - It is difficult to make the kind of run-time safety guarantees
   that we are used to with Haskell/ML if we introduce constructs of
   this kind.
 - It would seem to require considerable typing information to be
   carried around at run-time, which in general Haskell compilers
   seem to rely on being able to avoid. More generally, it may
   render unsafe a wide range of optimizing program transformations.
 - It would require the run-time for potentially every program to be
   considerably larger, carrying around an entire interpreter.
 - It has not, historically, been a priority for the community. The
   FP community has tended to focus more on safety and static analysis,
   as well as efficiency of compiled output. The general answer has
   been, "Well, if you want that, you should be using lisp/scheme/etc."

Are those reasons basically right, basically wrong, somewhere in the
middle? If it's actually mostly the final reason, I wonder if the idea
deserves more consideration. Has the idea been revisited in light of
monadic control flow, type classes and other relatively recent
developments? Would it be possible, in this case, to have our cake
and eat it too? 

Matt

-- 
Matt Hellige                  matt@immute.net
http://matt.immute.net