make-environment (long)

[jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)]

    I don't know if this is the right forum to raise this issue.  But, I wonder
    why make-environment works the way it does.  If I define
	    (define (complex x y)
		(make-environment
		    (define re x)
		    (define im y)))
	    (define a (complex 1 2))
    not only does a have re and im bound in it, but it also has x and y
    bound in it.  So,
	    (access x a)
    yields 1.  From the description of make-environment in Abelson and Sussman,
    it appears that only re and im should be bound in a.  Is this a bug, or a
    feature, or am I missing something?  If this is the way make-environment
    is supposed to work, is there some other primitive that binds re and im
    and forgets about x and y?

You have misunderstood section 4.3.1 of S&ICP.  If you read it
carefully, you will notice

"For use in conjunction with EVAL, Scheme provides an operation called
MAKE-ENVIRONMENT that constructs an environment, evaluates a
designated sequence of expressions within this environment, and
returns the environment as the value of the MAKE-ENVIRONMENT
expression.  The enclosing environment of the new environment is the
environment in which the MAKE-ENVIRONMENT expression was evaluated."

The last sentence in the above quote makes it quite clear that this
environment is built on top of the one in which the MAKE-ENVIRONMENT
expression was evaluated, and therefore all these names are visible to
EVAL.

You ask about ACCESS, which is not in S&ICP, so I assume you are
talking about MIT Scheme instead of the restricted subset used in
S&ICP.

There are two possibilities for ACCESS:

  Make it compatible with EVAL, and therefore make all the names (like X
  and Y in your example) visible.  This is the current implementation.

  Make ACCESS look only at the "topmost" frame of the environment.  This
  means that all the names that can be exported from a package must be
  defined in that package itself, and there is no "export" inheritance
  between packages built on top of packages.  

We tried the latter approach for a while and it was a total mess.  We
quickly changed it to its alternative.