Interpret haskell within haskell.

[Jonathan.C.Cast-1]

----- Original Message -----
From: Matt Hellige <matt@immute.net>
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                  matt@immute.net
> http://matt.immute.net

Jon Cast