This is the mail archive of the
mailing list for the Guile project.
Re: "environment" unsuitable name for top-level environment
- To: firstname.lastname@example.org
- Subject: Re: "environment" unsuitable name for top-level environment
- From: Keith Wright <email@example.com>
- Date: Tue, 17 Aug 1999 22:35:54 -0400
- CC: firstname.lastname@example.org, email@example.com
- References: <E11GpUjfirstname.lastname@example.org>
> From: Mikael Djurfeldt <email@example.com>
> The proposed new data type for top-level environments is called
> In my opinion, this is unsuitable since the name "environment" is
> already occupied: It is commonly used when referring to lexical
> environments, in the current Guile implementation and in other Scheme
> implementations, most notably SCM.
'Environment' is standard terminology in denotational semantics for a
mapping from identifiers (or symbols) to locations (i.e. a set of
bindings). It is also used in R5RS for the second argument of EVAL.
There are many rules for which environments are used in evaluating
which parts of the program. If there is a data type within the
language which reifies or reflects these semantic functions then
'environment' seems like a fine name for this data type. There
may be several procedures which create or use such objects.
Maybe I don't really understand the objection here; it seems like
saying we can't call reals 'numbers' because the term is already
used for integers.
I am assuming that top-level environments, local environments,
and all other types of environment can be passed as the second
argument of EVAL, used to lookup up symbols (whatever the procedure
that does that is called), and so on. If this is not the case,
then it is the design that is broken, not the terminology.
-- Keith Wright <firstname.lastname@example.org>
Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
--- Food, Shelter, Source code. ---