[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
common lisp- &environment objects
- To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>, David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
- Subject: common lisp- &environment objects
- From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
- Date: Mon, 10 Jun 85 14:59 EDT
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: <FAHLMAN.12118019135.BABYL@CMU-CS-C.ARPA>
Date: Mon, 10 Jun 1985 09:47 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
So again the question is whether we can accomplish everything we need to
with environment objects even if these objects have only dynamic extent.
Whether some parts of the environment need to have indefinite extent in
order to make closures work is a different question, I think.
OK, I think I understand the question you are asking. My question is:
Does it matter? I cannot think of any valid programs (read: macros)
that would want to store an environment in permanent storage. For that
matter, I cannot think of any valid programs (read: macros) that side
effect the environment. They only USE them, which means you pass them
as arguments to macroexpand(-1). Therefore, I don't think it matters
how they are implemented, since all programs should be using them as
lexical scope, dynamic extent, which is the most restrictive. The only
"program" that needs to update the environment is the interpreter (read:
special forms), and that "program" is supplied by the vendor and users
don't need to know about it.
Aside: Symbolics' EVAL function takes an &OPTIONAL ENV argument so that
the implementation of special forms can call EVAL instead of
EVAL-WITH-ENV or somesuch.