This is the mail archive of the
mailing list for the Guile project.
Re: "environment" unsuitable name for top-level environment
- To: Jost Boekemeier <email@example.com.TU-Berlin.DE>
- Subject: Re: "environment" unsuitable name for top-level environment
- From: Mikael Djurfeldt <firstname.lastname@example.org>
- Date: 18 Aug 1999 18:53:53 +0200
- Cc: Mikael Djurfeldt <email@example.com>, firstname.lastname@example.org, email@example.com
- Cc: firstname.lastname@example.org
- References: <E11GpUjemail@example.com> <firstname.lastname@example.org>
Jost Boekemeier <email@example.com.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
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
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.