There were various mixed concerns, like perhaps requiring implicit
scoping of @-names to be practical in classes,
Like implicitly scoping this, super, and arguments, this would cause
problems with nested scopes. Unless the name of the class was made
part of the implicitly named scope reference?
their operational generativity perhaps being a mismatch with their
seemingly static meaning in certain syntactic forms,
This appears to be ungrounded. See below.
potential ambiguities with what @x actually denotes in certain
contexts. And probably more. Most of that should be in the meeting
minutes.
Can't say about ambiguities. And I started asking because I couldn't
find (valid) reasons in the minutes;-)
Implicit scoping in a language with nested scopes has never been a
good idea (even the implicit var/let scopes in JS are not its strongest
point). Prolog got away with it because it had a flat program structure
in the beginning, and even that fell down when integrating Prolog-like
languages into functional one, or when adding local sets of answers.
Indeed. (Although I don't think we have implicit let-scopes in JS.)
There are few enough cases (scope to nearest enclosing block unless
there is an intervening conditional or loop construct, to nearest for
loop body if it appears in the loop header, to the right in a
comprehension) that the difference might not matter.
I would have preferred if let had not been modeled after var so
much, but that is another topic.
Symbols will definitely still be usable as property names, that's
their main purpose.
The main technical reason that arbitrary objects cannot be used indeed
is backwards compatibility. The main moral reason is that using
general objects only for their identity seems like overkill, and you
want to have a more targeted and lightweight feature.
Having specific name objects sounds like the right approach.
So I'm not sure how your concerns are being addressed by
merely replacing a declarative scoping construct by an explicitly
imperative gensym construct?
We have the gensym construct anyway, @-names were intended
to be merely syntactic sugar on top of that.
Yes, so my question was how removing the sugar while keeping
the semantics is going to address the concerns voiced in the meeting
notes.
- explicit scopes (this is the difference to gensym)
- scope extrusion (this is the difference to lambda scoping)
Scope extrusion semantics actually is equivalent to an allocation
semantics. The only difference is that the store is part of your term
syntax instead of being a separate runtime environment, but it does
not actually make it more declarative in any deeper technical sense.
Name generation is still an impure effect, albeit a benign one.
For me, as a fan of reduction semantics, having all of the semantics
explainable in the term syntax is an advantage!-) While it is simple
to map between the two approaches, the nu-binders are more
"declarative" in terms of simpler program equivalences: for gensym,
one needs to abstract over generated symbols and record sharing
of symbols, effectively reintroducing what nu-binders model directly.
gensym is more "imperative" in terms of the simplest implementation:
create a globally unused symbol.
As Brendon mentions, nu-scoped variables aren't all that different
from lambda-scoped variables. It's just that most implementations
do not support computations under a lambda binder, so lambda
variables do not appear to be dynamic constructs to most people,
while nu binders rely on computations under the binders, so a
static-only view is too limited.
I think you are confusing something. All the classical name calculi
like pi-calculus or nu-calculus don't reduce/extrude name binders
under abstraction either.
Not under lambda-binders, but under nu-binders - they have to.
If was explaining that the static/dynamic differences that seem to make
some meeting attendees uncomfortable are not specific to nu-scoped
variables, but to implementation strategies. For lambda-binders, one
can get far without reducing below them, but if one lifts that restriction,
lambda-bound variables appear as runtime constructs, too, just as for
nu-binders and nu-bound variables (gensym-ed names).
Claus
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
