Re: [MIT-Scheme-devel] tied in knots with environments

[Joe Marshall]

On Mon, Jan 31, 2011 at 12:51 AM, David Gray <address@hidden> wrote:
> The pain is self induced but I can't see anyway round it. I generate x from
> some earlier calculations.
> So the simplest thing is:
> (define x '(1 2 3 4 5))

X in the user-initial-environment is now bound to a list of 5 elements.

> (ge 'win32)

The REPL is now using the win32 environment for evaluation.  The value
of X is no longer visible.

> (define (myadd x)
>     (apply + x))

MYADD in the win32 environment is now bound to a function of one
argument.

> (ge user-initial-environment)

The REPL now uses the user-initial-environment for evaluation.
The binding of MYADD is no longer visible, but the binding of X
has now become visible.

> but now
> (eval '(myadd x)
>   (->environment '(win32)))

This invokes EVAL using the win32 environment.  Recall that the
binding of X is not visible in that environment.  This evaluation fails
with an unbound variable.

So there are three ways we can go:
  1.  Why not avoid this dance with multiple environments?
       (Simplest approach and recommended.)

  2.  Continue the dance and add the appropriate access calls:
       ((access myadd (->environment '(win32))) x)
       or
       (ge 'win32)
       (myadd (access x user-initial-environment))

       (This is rather advanced usage and not recommended.)

  3.  Use the `package' code to arrange for these identifiers
       to be shared within different environments.  (highly advanced)




-- 
~jrm