[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A Proposal for Environments in Scheme
I have some problems with your proposal:
MAKE-ENVIRONMENT <id> <parent> ... [Procedure]
1) The <id> seems spurious, although harmless.
2) What is the purpose of multiple inheritance? With single
inheritance there is still the "fiction" of lexical scoping: You can
picture the new environment as appearing virtually somewhere in its
parent, but with multiple inheritance this fiction goes away.
Is the confusion warranted?
In addition to these procedures, We propose a change to the meanings of
identifiers whose names include colons:
-- No identifier may begin or end with a colon.
(Alternatively, such identifiers behave as they do now.)
-- An identifier of the form a:b1:...:bk (k >= 1) is entirely equivalent to
(ENVIRONMENT-REF a:b1:...:bk-1 'bk)
I have strong objections against read syntax:
1) What is wrong with (ACCESS a b1 b2 ... bk)? If it is too long, I'm
perfectly happy with (: a b1 b2 ... bk), which only adds 4 characters
to your proposal, and no read syntax.
2) Read syntax has the following problem:
(set! a:b:c 3)
(set! (environment-ref (environment-ref a 'b) 'c) 3)
which is not valid syntax for SET! Clearly it would be desirable if
the above expanded into
(environment-set! (environment-ref a 'b) 'c 3)
but this is no longer read syntax.
A file of Scheme code, under this proposal, may optionally begin with a piece of
syntax, called a >herald<, that arranges for special treatment of the
environmental context of the code in the file. Heralds obey the following
I think this is not very well thought out. By placing a HERALD in a
file you are making the file "absolute" rather than "relative". I
can no longer load the file into multiple environments with different
contexts except by munging the loader (to change GLOBAL, or whatever,
I think you would be much better off separating the contents of the
file from the definition of the system that describes and creates the
context into which the file is supposed to be loaded.