This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: "environment" unsuitable name for top-level environment


Michael Livshin <mike@olan.com> writes:

> if I understand Mikael correctly, the point here is that "the idea of
> environment" can be (and the implementation is) divided into two
> ideas: top-level environments and lexical (closure) environments.

You understand me.  But I'd say that the idea is one and it's only the
implementation that is in need of division.

> R5RS uses the term "environment" for the former, so I guess the latter
> should be called differently.  "lexical environment" is fine, I think.

Hmm... from R5RS:

 "If there is no binding of the identifier whose region contains the
  use, then the use refers to the binding for the variable in the top
  level environment, if any (chapters 4 and 6); if there is no binding
  for the identifier, it is said to be unbound."

I seem to be reading R5RS differently than both you and Jost.  To me
it seems that lexical environment is called `environment' in most
cases and that top-level environments are called `top level
environments' in most cases.

More:

"The initial (or "top level") Scheme environment starts out with a
number of variables bound to locations containing useful values, most
of which are primitive procedures that manipulate data."

and:

"The environment in effect when the lambda expression was evaluated is
remembered as part of the procedure.  When the procedure is later
called with some actual arguments, the environment in which the lambda
expression was evaluated will be extended by binding the variables in
the formal argument list to fresh locations"

It seems to me that the very use of the word `initial' in `initial
environment' is an indication that the RnRS authors don't want to
make a separation between "top level" and "local" environments---it's
really the same thing on the semantic level.

It becomes necessary to make the distinction first in an
implementation.   Again, my point is that `environment' should be
reserved for the most general form of environment---"the environment
in effect" at a particular code position, not wasted on a special case
which is motivated by implementation reasons.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]