New private names proposal

[David-Sarah Hopwood]

On 2010-12-17 06:44, Brendan Eich wrote:
> On Dec 16, 2010, at 9:11 PM, David-Sarah Hopwood wrote:
>> On 2010-12-17 01:24, David Herman wrote:
>>> Mark Miller wrote:
>>>> Ok, I open it for discussion. Given soft fields, why do we need private
>>>> names?
>>>
>>> I believe that the syntax is a big part of the private names proposal. It's
>>> key to the usability: in my view, the proposal adds 1) a new abstraction to
>>> the object model for private property keys and 2) a new declarative
>>> abstraction to the surface language for creating these properties.
>>
>> I don't like the private names syntax. I think it obscures more than it
>> helps usability, and losing the x["id"] === x.id equivalence is a significant
>> loss.
> 
> As Chuck Jazdzewski pointed out, this equivalence does not hold for id not
> an IdentifierName.

Of course not, because the syntax 'x.id' is not valid for id not an
IdentifierName (in either ES5 or ES5 + private_names). Whenever we state
semantic equivalences, we mean them to hold only for syntactically valid
terms. So 'x' necessarily has to be something that can precede both '[_]'
and '.', i.e. MemberExpression or CallExpression. Similarly, 'id' necessarily
has to be something that can both occur within quotes and follow '.', i.e.
it must be an IdentifierName.

(This has nothing to do with any difference between soft fields and private
names. Anyway, for future reference, I rarely state the productions that
syntactic variables range over when they can be unambiguously inferred as
above.)

> The new equivalence under private names would be x[#.id] === x.id.

... which is strictly weaker, more complex, and less explanatory.
Let's simplify things by taking the '===' operator out of the picture.
For ES5 we have x["id"] ≡ x.id in any context, and for ES5 + private_names
we have x[#.id] ≡ x.id, where ≡ means substitutability.

x["id"] ≡ x.id relates the meaning of existing basic constructs:
string literals, '_[_]', and '_._'. In particular, it *defines* the
semantics of _._ in terms of string literals and _[_], so that _._
need not be considered as being in the "core" or "kernel" of the
language [*].

In the case of x[#.id] ≡ x.id, '#.id' is a new construct that is
being added as part of the private names proposal. Furthermore, the
meaning of '#.id' is context-dependent; it depends on whether a
'private id' declaration is in scope. So, what if we want to
understand '_._' in terms of existing constructs? Unfortunately,
'#.id' must be primitive; there is nothing else that it can desugar
to because 'private id' does not introduce an ordinary variable
(unlike 'const id_ = SoftField()', say). Rather it introduces an
element in an entirely new lexically scoped namespace alongside
ordinary variables. This is fundamentally more complex than "id",
which is just a stringification of the identifier.


[*] Yes, I know that the ES5 spec doesn't take a "kernel language approach"
    to defining ECMAScript. That doesn't mean it can't be understood that
    way, and it's very useful to be able to do so.

>> As Mark points out, though, that syntax can be supported with either
>> proposal. The private names proposal is more entangled with syntactic
>> changes, but that's a bug, not a feature.
> 
> No, that is a usability feature.

You're misunderstanding me.

The syntax could be considered a usability feature. Some people like it,
others don't.

The fact that the proposal is entangled with that syntax, so that it is
difficult to see its semantic consequences separate from the syntax,
cannot possibly be considered a feature of the proposal, at the meta level
of the language design process. At that level it's clearly undesirable --
as the course of the discussion has amply demonstrated!

> The inherited soft fields approach is more entangled with its
> reference implementation, which is not the efficient route VM
> implementors can swallow.

I think you're being rather patronising to VM implementors (including
yourself!) if you think that they're incapable of understanding how a
feature specified in this way is intended to be implemented. Of course
they can.

Specifying it in this way has very concrete benefits to VM implementors:

 - A test suite can directly compare this very simple reference
   implementation with the optimized implementation, to check that they
   give the same results in cases of interest. (It's still necessary to
   identify which cases are needed to give adequate test coverage, but
   that's no more difficult than in any other approach.)

 - Disputes about the validity of any proposed optimization can be
   resolved by asking what the reference implementation would do in
   that case.

 - The specification is concise and localised, without being cryptic.
   This kind of conciseness aids understanding.

Of course this style of specification also has *potential* disadvantages,
the main one being a risk of overspecification. However, to argue against
a particular proposal in this style, you need to say why that proposal
overspecifies, not just handwave that it must. I have looked at the
proposed definition of SoftField carefully and cannot see any
overspecification in it. The only mildly tricky part is the treatment
of the 'undefined' value, and it's fairly easy to see that that is
handled as intended.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101221/318aceac/attachment.bin>