----- Original Message ----- From: Matt Hellige <[EMAIL PROTECTED]> Date: Friday, December 20, 2002 0:20 am Subject: Re: Interpret haskell within haskell.
> 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? 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 [EMAIL PROTECTED] > http://matt.immute.net Jon Cast _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
