On Thu, Dec 23, 2010 at 11:49 AM, Brendan Eich <span dir="ltr">&lt;<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div class="im"><div>On Dec 23, 2010, at 10:17 AM, Mark S. Miller wrote:</div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><font face="monospace">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.</font></div>

</div></blockquote><div><br></div><div>Rather than more or less, I was suggesting different.</div></div></blockquote><div><br></div></div>More + new = different, but it&#39;s also more -- adding @ in addition to dot, or @ as sigil usable after dot and left-square-bracket. We&#39;re not taking away syntax, so the budget ceiling must rise just for @.</div>
<div><br></div><div><br></div><div><div class="im"><blockquote type="cite"><div class="gmail_quote"><div> I would hate to see @ added to support soft fields in addition to &quot;private&quot; and/or &quot;#&quot; added to support names.</div>
</div></blockquote><div><br></div></div>I agree, but I&#39;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&#39;s why I wrote that only private names (as currently proposed) is burdened (or blessed, or both) with new syntax.</div>
<div class="im"><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"><div> 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&#39;s continue to try all syntax proposals on both semantics and see what the pros, cons, and non-orthogonalities are.</div>
</div></blockquote><br></div></div><div>As I wrote to David-Sarah, I&#39;m now convinced we should *not* try mapping syntax strawmen to both semantics. We don&#39;t even have agreement on the syntax requirements, on #.id to get private names into runtime expressions, reflection, and proxies.</div>
<div><br></div><div>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).</div><div><br></div><div>GIven weak maps in harmony, and lack of experience using them enough to motivate syntactic sugar, I&#39;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.</div>
<div><br></div><div>After all this discussion it is clear to me that we should not compare apples to oranges </div></div></blockquote><div><br></div><div><meta charset="utf-8"><div>You&#39;ve said this &quot;apples to oranges&quot; thing many times. I just don&#39;t get it. My comparisons at &lt;<a href="http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields">http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields</a>&gt; show that these two semantics address extremely overlapping use cases. For both to be in the language, with one group (including myself) saying &quot;use soft fields for these use cases&quot; and another group saying the opposite, is to create conflicting conventions and the horrors of Perl&#39;s TIMTOWTDI philosophy. </div>
<div><br></div><div>Do you agree at least that for the use case shown by the &lt;<a href="http://wiki.ecmascript.org/doku.php?id=strawman:private_names#conflict-free_object_extension_using_private_names">http://wiki.ecmascript.org/doku.php?id=strawman:private_names#conflict-free_object_extension_using_private_names</a>&gt; clone example, we should all recommend soft fields, so that these extensions will not needlessly break when they encounter frozen prototypes?</div>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div>or prematurely standardize only one kind of fruit.</div>
</div></blockquote><div><br></div><div>I don&#39;t get this either. Certainly, both are equally premature at this point. Are you saying that neither should be in ES6? </div><div><br></div><div>And please let&#39;s also agree not to prematurely standardize both kinds of fruit.</div>
<meta charset="utf-8"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div> We&#39;re likely to end up with a Meyer lemon by mistake.</div>
</div></blockquote><div><br></div><div>I will try to resist the temptation to expand on these colorful metaphors ;).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><br></div><font color="#888888"><div>/be</div></font></div></blockquote></div><br><br clear="all"><br>-- <br>    Cheers,<br>    --MarkM<br>