On 16.04.2011 2:28, David Herman wrote:
The fact is that "dynamic scope" is used to mean multiple things: 1) the
"stack-like" semantics employed by e.g. the original Lisps, and 2) any non-static scoping
semantics. The former was so famous that it came to be the common usage of the term, but #1 is
really just a special case of #2. I've seen people use it both ways. Sam's using it the second way,
Dmitry is using it the first way (and trying to claim that Sam's way is wrong). It's not really a
deep issue, just ambiguous terminology.
Yeah, it's not a big issue, as I also mentioned, just a terminology
ambiguity. Moreover, I also mention in my article that "dynamic scope"
definition can be applied in the context.
Once again (to conclude it):
A static (lexical) scope means that we can determine by looking on the
source text in _which environment frame_ an identifier will be
_resolved_ at further usage in runtime. This determination is made by
the place of the identifier definition.
Actually, from this definition already may follow the fact that if the
program allows runtime scope augmentation (i.e. adding new bindings in
runtime) it has not only static scope, since using `eval`, `with` and
new runtime bindings of the global object don't allow us to say
precisely in which scope the binding will be resolved
(http://bit.ly/gWAULX , this is also to show that I also used
terminology of "dynamic scope" but adding the word "feature").
And since "classical" (?) dynamic scope has its own meaning, probably
"runtime scope augmentation" is a better definition. Though, if everyone
in discussion is aware about both application of this term, it's OK.
Notice, this runtime scope augmentation doesn't cancel the fact that the
scope is still static (lexical). But if we have the possibility of this
runtime scope augmentation then we cannot make the optimization with
lexical addressing and need to use runtime scope chain lookup. However
having avoided these runtime new bindings, we do have this optimization
-- which is was my main point.
OK, let's conclude on the terminology debates (we've found out the truth
and understood each other) and return to the very first topic -- do we
need for all that this existential operator or not?
Having this thread read I already think that it makes sense in this
operator only if we can to support all its features and only it it can
be done easily in respect of parsers, unambiguous syntax constructs, etc.
OTOH, taking into account this talk on eliminating of the global object
with imposibility to define a new global binding at runtime cancels the
feature of just testing a variable -- since all variables exists before
the code is executed.
I.e. there's no need in this:
if foo? {
/* foo exists, do this */
}
Though, it's only on first glance, since if we take e.g. two combined
files, then such a check can make sense (the the check sounds as "are we
combined with another file which has the needed binding?":
if Widget? {
/* we have this module */
}
Dmitry.
Dave
On Apr 15, 2011, at 2:31 PM, Brendan Eich wrote:
I've noticed that there are at least two uses of dynamic scope, all
maledictions (and so tending to blur together into one general curse):
* Using the dynamic link or call stack as scope chain link (clearly evil; er,
eval ;-).
* Having a scope chain element be a mutable object in which bindings can come
and even go (also bad, and the issue here in ES5 non-strict and older JS).
We could try to call the latter "dynamic binding", but "binding" is so horribly
overused and overloaded informally...
Not sure this helps :-(.
/be
On Apr 15, 2011, at 10:59 PM, Sam Tobin-Hochstadt wrote:
On Fri, Apr 15, 2011 at 4:53 PM, Mark S. Miller<erig...@google.com> wrote:
I understand how dynamic scope works. And ES5 with the mutable global
object has it:
function bar() { return foo };
bar() // error: foo is not defined
var foo = 7;
bar(); // produces 7
Lexical scope would produce the error both times.
Hi Sam, this does establish that ES5 does not have lexical scope. But I
don't how ES5 has dynamic scope. In the above example, the 'foo' that bar
has in scope during the second call still has nothing to do with what's in
scope at the call site from which bar is called.
I think what you're saying is that if I then do:
(function (){ var foo = 8; return bar(); })();
I'll get 7, not 8, which is certainly true. We can think of this as
dynamically scoped with respect to "top-level" variables, ie those
bound at the top level or unbound at the time of definition, or we can
think of this as a variety of scoping that is neither lexical nor
dynamic -- that's just a terminology question.
--
sam th
sa...@ccs.neu.edu
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
