New private names proposal

[Brendan Eich]

On Dec 23, 2010, at 10:17 AM, Mark S. Miller wrote:

> It seems you agree enough to be exploring @ instead of ., which could desugar to transposed .get or .set. So perhaps more new syntax will help, rather than less new syntax and too much overloading of old.
> 
> Rather than more or less, I was suggesting different.

More + new = different, but it's also more -- adding @ in addition to dot, or @ as sigil usable after dot and left-square-bracket. We're not taking away syntax, so the budget ceiling must rise just for @.


> I would hate to see @ added to support soft fields in addition to "private" and/or "#" added to support names.

I agree, but I'm content to let soft fields and other weak map libraries get enough usage to warrant new syntax. The frozen AST use-case can use .get and .set explicitly in the interim. That's why I wrote that only private names (as currently proposed) is burdened (or blessed, or both) with new syntax.


> That exceeds my sense of the syntax budget we should be willing to pay. But if it helps brainstorming not to constrain this budget early, let's continue to try all syntax proposals on both semantics and see what the pros, cons, and non-orthogonalities are.

As I wrote to David-Sarah, I'm now convinced we should *not* try mapping syntax strawmen to both semantics. We don't even have agreement on the syntax requirements, on #.id to get private names into runtime expressions, reflection, and proxies.

Plus, we have no user testbed (yet -- Narcissus is being beefed up to prototype Harmony proposals and it can run in-browser via Zaphod -- more on this in a bit).

GIven weak maps in harmony, and lack of experience using them enough to motivate syntactic sugar, I'm not in favor of adding syntax for soft fields -- yet. Private names as proposed come with syntax as an essential part of the proposal.

After all this discussion it is clear to me that we should not compare apples to oranges or prematurely standardize only one kind of fruit. We're likely to end up with a Meyer lemon by mistake.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101223/c5f346d3/attachment-0001.html>