
[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