[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PROCLAIM-LEXICAL (Version 7)
- To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
- Subject: Issue: PROCLAIM-LEXICAL (Version 7)
- From: Jon L White <firstname.lastname@example.org>
- Date: Wed, 28 Sep 88 16:11:51 PDT
- Cc: Jon L White <@NSS.Cs.Ucl.AC.UK,@edu.stanford.edu:email@example.com>, Moon@scrc-stony-brook.arpa, KMP@scrc-stony-brook.arpa, CL-Cleanup@sail.stanford.edu, JAR@ai.ai.mit.edu
- In-reply-to: Jeff Dalton's message of Wed, 28 Sep 88 16:51:09 BST <firstname.lastname@example.org>
re: I think the semantic implications of adding a declaration that prevents
dynamic binding are sufficiently straightforward that we should not
rule it out just because no one implemented it a year ago.
Of course, your right. I was reacting to the added complication
more recently added to permit "mixing" the D and G situations.
re: The strangeness in the current proposal is because the dynamic and
lexical environments meet in a separate global environment. So
a shallow bound implementation can't just change the global cell
when it pushes a new binding. The shallow binding cell has to
be a separate cell, making symbols (effectively) larger. KMP
and JAR suggested the use of a single cell combined with search
for the global value if both it and the dynamic are needed.
This is a new machanism, so we might want to think twice about
I think moon was right that the problem is really parallel to the
implementation of deep binding. In fact, PDP10 MacLisp is "shallow
bound", but implemented the restoration stack in such a way that
it could find the toplevel value, or any intermediate value, simply
by "walking" back up that stack -- very similar to a deep-bound
search [and such "walking" was in fact used when applying downward
funargs]. There are numerous "cacheing" techniques to accellerate
deep-bound searches, so I'm not making an inherent performance criticism;
rather, I fear that this is a new arena for all except perhaps ENVOS
[and Lucid's QLISP] and that simply taking on this coding task and
all its performance implications is a venture much bigger than I'd
like to see labelled as "cleanup".
re: . . .
I believe this alternative (which is more or less what was proposed
before minus all the stuff about CONSTANT proclamations, etc.) solves
the main problems (an easily referenced global for deep bound
implementations and a way to establish a global variable without
proclaiming it special and without some implementations thinking
it's a spelling error or an omitted proclamation) and is fairly
This is what I thought I liked about the proposal long ago.
re: In any case, I think there is a fallback better than "do nothing".
-- JonL --