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

- 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

----- Original Message ----- From: Matt Hellige Date: Friday, December 20, 2002 0:20 am Subject: Re: Interpret haskell within haskell. transformations. 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?

Are you trying to argue here that monads, type classes, etc. remove the difficulties you list? Otherwise, it seems to me that supporting eval would remove just about every advantage Haskell has over imperative languages.

Matt

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

Jon Cast