Re: A Proposal for Environments in Scheme

[Pavel.pa@Xerox.COM]

Forwarded by request.

Morris Katz  23 May 88 Re: A Proposal for Environments i ...
Return-Path: <MKATZ@A.ISI.EDU>
Received: from A.ISI.EDU by Xerox.COM ; 23 MAY 88 10:18:55 PDT
Date: Mon, 23 May 88 13:15:01 EDT
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Re: A Proposal for Environments in Scheme
To: Pavel.pa
In-Reply-To: <880520-115000-2371@Xerox>
Message-ID: <12400648194.42.MKATZ@A.ISI.EDU>

I have a number of concerns about the environment proposal which I will
try to express as suscinctly as possible.  I will begin with the simple, 
syntactic ones and progress from there.

1)  I believe it is a big mistake to require that all environments have a name.
There was a good reason(s) for deciding that not all procedures in Lisp should
have to be named, and I believe that those arguments apply equally well to this
case.  Either there should be two forms (make-environment <parents>) and 
(make-named-environment <id> <parents>) or the order of the arguments should be
reversed and <id> should be made optional in dialects that support optional
arguemnts.  In the latter case, <parents> would either be an environment or a
list of environments.  

2)  I have been interested in the semantics and use of multiple environment
inheritance for some time; but, I am not sure that it is well enough understood
to become part of R3RS.  (Maybe someone else understands it better than I do 
and can convince me otherwise.)  In particular, I am concerned about efficient 
implementations for interpreted code, difficulty in understanding code which 
utilizes this feature, and the development of suitable browser technology to 
make debugging of programs using it tractable.

3)  It is my belief that the loader should load the contents of files into the 
environment of the REP LOOP from which the load was initiated, unless 
specified otherwise in the load command.  (e.g., (load "foo" bar) would load
the file "foo" into the environment bar.)  Making all files load into the 
global environment unless specified otherwise in a herald seems artificial and
constraining.  What if one wants to load two slightly different copies of a
system into two sets of environments and compare their execution?  Using the 
herald approach I believe this would require copying all of the files and 
changing the heralds.  The logical extension of thiproach would be that 
<expression> in (env <expresssion>) in a herald be evaluated in the load
environment, rather than the global environment.

4) I can't quite explain why, but the entire export section makes me feel a 
little uneasy.  While there are some things that can be done convieniently 
through the unification of two symbols in different environments, I get the 
feeling that this feature can very quckly get one into trouble.  How do we
build debuggers to help support its use?  What are the costs added to normal 
lexical lookup due to this feature?  Does it interact pathologically with 
incremental definition, or is this just an erroneous gut level feeling?  Maybe
those who are more familiar witsimilar features in CommonLisp can answer some 
of these questions.

					Morry Katz
-------