Interpret haskell within haskell.

oleg@pobox.com oleg@pobox.com
Mon, 23 Dec 2002 18:34:43 -0800 (PST)


Lauri Alanko wrote on Dec 22:
> The magic is _here_:

> (begin (define a 5) (eval '(set! a (+ a 1)) (interaction-environment)) a)
> ==> 6

> Here (interaction-enviroment) is a run-time representation of the
> compile-time environment. It makes possible two-way interaction between the
> stages. Essentially, first-class environments are all the magic you need to
> implement eval.

I'm sorry to act as a Grinch, but there is no magic. First, according
to R5RS, (interaction-environment) is not a first-class environment.

R5RS says (Section 6.5):

> [[optional procedure]] (interaction-environment)

> This procedure returns a specifier for the environment that contains
> implementation-defined bindings, typically a superset of those listed
> in the report. The intent is that this procedure will return the
> environment in which the implementation would evaluate expressions
> dynamically typed by the user.

There is nothing there about interaction between phases. And in fact,
this interaction does not work. If you put the following code

(module aaa)
(begin (define a 5) (eval '(set! a (+ a 1)) (interaction-environment))
       (display a) (newline))

into a file, _compile_ that file using Bigloo, and run the resulting
a.out, you will see a message
	*** ERROR:bigloo:eval:
	Unbound variable -- a

Nowhere the Scheme report talks about first-class environments. Please
note that the result of (interaction-environment) is a _specifier_ for
an environment.

Some Scheme systems do provide first-class environments.  For example,
MIT Scheme has a form 'the-environment'. It comes at a price. In a
post "Re: why isn't the environment explicit ?" on comp.lang.scheme on
Mar 15, 2001, Joe Marshall wrote:

> > Since you can (sort of) regard call/cc as making continuations
> > explicit, why aren't environments explict ?

> In MIT Scheme, they are.  The special form (the-environment) returns
> the current environment as a first-class object.

> However.

> The difficulty with using such a form is that it destroys any
> possibility of compiler optimization.  If you compile code with a
> (the-environment) form in it (in MIT Scheme), the compiler essentially
> throws up its hands and inserts code to call the interpreter.

There is no Santa either.