Interpret haskell within haskell.

[Matt Hellige]

[oleg@pobox.com]
> 
> David J. Sankel wrote:
> > I was referring to a haskell interpreter to be used
> > within haskell code.  For instance:
> 
> 
> This was exactly the gist of the message:
> 
> http://www.haskell.org/pipermail/haskell-cafe/2002-September/003423.html
> 
> The message gave the working example. The end of the message posed
> that GHCi is better for these kinds of things. Simon Marlow's message
> shows that this is indeed the case.
> 

Unfortunately, as the message you cited admits ("Perhaps someone will
implement Staged Haskell one day?"), it is hardly an elegant solution,
and (I believe) it is not well suited to a large-scale application.

Here's the best example I can come up with of what I'd hope to be able
to address: suppose I love emacs, but hate lisp, and would love to
have the benefits of static typing. I'd like to be able to write emacs
with Haskell (or some appropriate variant) in place of elisp. This
means I'd like to be able to bind keys to Haskell code (with type
safety!) and so on. I'd like to able to enter a mode where the user
could enter a read-eval-print loop and evaluate arbitrary expressions.
These kinds of things are pretty much trivial with lisp, and what I'm
basically asking is: is it possible to make them equally trivial (and
similarly efficient) in a statically typed language.

So, in my mind at least, forking a process and loading a new
interpreter is not an acceptable solution. I suppose ghci packaged as
a library, with a well-designed and appropriately granular interface
would be OK, but of course it would be GHC-specific. I would also be
curious to know the penalties one would have to pay in terms of
performance, binary size, and so on, and I am also curious to know
how easy it would be to add support for all the "incidental"
functionality one would need to actually use it in a commercial app:
e.g., how easy is it to grab, inspect and display useful error
messages when loading code? 

Once again, I think it would be ideal if the standard library included
data types and functions for reflection, staged
evaluation/type-checking and so on. GHC, of course, could probably
implement them using ghci, but I would like to maintain the delusion
that eventually this stuff would work the same in any Haskell
implementation.

In the end, it seems like people ARE working on this problem, and it
seems like it's really just not quite there. It also seems like I
should probably stop talking about it unless I'm willing to invest a
lot of time actually working on it. :)

Thanks to all for the tips and the thoughtful responses.

Matt

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