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

[Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se>]

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> > already occupied: It is commonly used when referring to lexical
> > environments, in the current Guile implementation and in other Scheme
> > implementations, most notably SCM.
> 
> Hmm.  R5rs also calls them `environment' ("interaction-environment",
> "scheme-report-environment" etc.) and as far as I can see SCM does
> this, too.

We are probably saying the same thing, but just to avoid confusion: If
you read through R5RS you see that the term `environment' is generally
used to refer to a lexical environment.

In the section about `eval' the term `environment specifier' is used,
and is the name for one of a set of special top-level environments
(which are special cases of a lexical environments).

The difference in the representations of top-level environments and
"local" environments is really an implementation detail which has to
do with efficiency.  (One could otherwise imagine that the `let'-form
copies a top-level environment and replaces the bindings of the
let-form, or that the top-level environment is represented as the
environment frame of a huge `let'.)

I'd like us to reserve the name `environment' for the data type
implementing the most general form of environment (the one
corresponding to the env-argument of the evaluator, and to the use of
the term `environment' in R5RS) rather than to a specialized data type
used to implement a part of such an environment.

> Can't we call the environment frames simply `env-frame' or something
> like that?

Yes, the name `env-frame' is suitable for an environment frame, but
that is only a component of a lexical environment---the one
introduced by one `let' or one application.  A lexical environment
normally consists of a list of environment frames + a top-level
environment.

My suggestion is that we call the data type encapsulating this list of
frames + the top level environment `environment' and call the
top-level environments something different.

> However I would say that the term "name-space" in unfortunate because
> a name space consists of more than one environment: an eval-environmen, 
> an export-environment and possibly an import-environment.
> 
> Just like a /process/ is a /programm/ at run-time a /name space/ is a opened
> /module/.

I don't want to fight particularly for the term `name-space' but in my
mind I would be happy to use `name-space' either to denote the
top-level environment, or the eval-, export- and import-components.
In both cases it's a mapping from symbols to locations.

But I'm not at all happpy with e.g. the term export-environment since
that object is not a lexical environment in the sense of R5RS.