On dropping @names

Claus Reinke claus.reinke at talk21.com
Wed Dec 5 10:19:16 PST 2012


> 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
 


More information about the es-discuss mailing list