[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PROCLAIM-LEXICAL (Version 7)
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: PROCLAIM-LEXICAL (Version 7)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 27 Sep 88 13:53 EDT
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU, JAR@AI.AI.MIT.EDU
- In-reply-to: <19880927173749.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 27 Sep 88 13:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... the cost to implementors is grossly understated ("some compiler work
would probably be needed" indeed!). ...
I had written "a fair amount" in v6 and Rees seemed to think that was
overstating things. I'm content to add that back in, or something stronger. :-)
In fact I have been unable to think of any way to implement this proposal
in a fully shallow-bound system...
Rees suggested (and I was going to add in the next revision), that you could
mark the global cell with a bit saying whether it had been re-bound in the
The only place this cost comes up at all is when a free lexical is referenced.
Bound lexicals incur no overhead. As such, only new code can be affected and
a slowdown cannot be perceived because there is nothing to compare timings with.
Also, I would expect that in by far the majority of situations, variables
declared lexical will not be used dynamically and vice versa. As such, the
one-bit mark above (assuming an implementation has a place to put that bit
without increasing the size of symbols by a whole slot-width) will nearly
always allow you to avoid the search because the valid bit will nearly always
be set (I (very unscientifically) claim).
Your proposal gives no hint of this efficiency cost.
Next draft will fix that.
Maybe there's a clever implementation technique I haven't thought of;
if so I wish someone would tell me.
You can tell me if the above seems clever enough.
The KMP/EB discussion suggests that the semantics of the proposal are
very confusing even to experts, although perhaps it's just unfamiliar.
That example would not be intuitive no matter -what- the semantics.
It's an example you created yourself in order to demonstrate the edge
effects concisely but shouldn't be taken to be model code. It does ok
but isn't something to be taken as model code. In practice, programs
use more mnemonic names, don't bind variables and then throw the values
away, don't bind a lexical variable and then disable references to the
binding by funny local declarations, etc. In the next draft, I'll put
the other example first so that people can practice on an intuitive case
before doing the extra credit problem.