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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
