A Proposal for Environments in Scheme

[David Bartley <bartley@mips.csc.ti.com>]

Thanks for your proposal; I imagine it will stimulate some discussion
on the topic.  Could you please clarify the following?

-- Suppose we had (HERALD (EXPORT ENV (FOO BAR))).  What is the effect
if FOO already has a binding in ENV?  What is the effect if BAR is
bound in an ancestor of the current (file's) environment but not
directly in the current environment?

-- What is the effect of (HERALD (EXPORT ENV (A B) (C B)))?  Is this
an error or are all three identifiers bound to the same location?

-- In your Q&A section, you mention "locking" of environments to
protect them against change.  This is an intriguing idea.  Would this
be done at the environment level or a binding at a time?  Can one
export a binding from an unlocked environment into a locked
environment?  If so, does the binding become locked?  If so, are uses
of both identifiers having that binding locked?  Likewise, what
happens if you export a binding from a locked environment into an
unlocked one?

-- The EXPORT mechanism doesn't require any hierarchical or other
structural relationship between the specified environment and the
current environment, so it is possible to inject a shared binding into
any environment you can get your hands on.  Such a binding could be a
trojan horse.  Perhaps it should be possible to "lock" an environment
against being exported into (?!) as well?

-- Have you found it to be important to have the `:' notation as a
short-hand for ENVIRONMENT-REF ?  My previous proposals to reserve the
`:' character for CL-style package notation have been soundly drubbed.

Just for grins, how would you react to a notation using curly braces, so
your A:B1:B2 becomes {{A}B1}B2, and STRINGS:SET! becomes {STRINGS}SET!.

Regards,
David Bartley