<div dir="ltr">[resending]</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 20, 2015 at 4:44 PM, David Ungar <span dir="ltr"><<a href="mailto:ungar@mac.com" target="_blank">ungar@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Oh, the troubles with email.<div><br></div><div>I’ll try again:</div><div><br></div><div>Self stratifies things into base- and meta- level. The idea is that almost all code is better off sticking to base level because that promotes encapsulation and reuse.</div><div>At base-level all you can do is throw messages at objects and then throw more messages at whatever bounces off of what the first messages return.</div><div>So you can always substitute an object with similar behavior for another.</div><div><br></div><div>At meta-level, you can interrogate the object to look inside; what slots it has, etc.</div><div><br></div><div>This design confers reusability, eases deployment, proxying, etc. The paper Gilad and I wrote for OOPSLA 2004 (“Mirrors…”) explains this well.</div><div>I gave a talk on this just last Fall at OOPSLA -- the paper  received an award. (Gilad was great at explaining the benefits of mirrors.)</div><div><br></div><div>In keeping with this design, our (base-level) identity operator was just another message.</div><div><br></div><div>When I asked about why JS has ===, it was a completely serious question, hope it didn’t sound facetious: When === was put into JS, what was the motivation?</div><div>I really don’t know. I designed Self’s identity operator based on my perception of why ST had (and misdefined, IMO) its identity operator.</div><div><br></div><div>I apologize for belaboring the obvious.</div><div><br></div><div>From your response, it sounds as if == is non-overidable today. Is that right?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- David</div></font></span><div><div class="h5"><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On Jan 20, 2015, at 4:28 PM, Mark S. Miller <<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 20, 2015 at 3:22 PM, David Ungar <span dir="ltr"><<a href="mailto:ungar@mac.com" target="_blank">ungar@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Yes, Self does have an unspoofable one, but at reflective level, not base.<br>
<br>
<br>
In JS syntax:<br>
<br>
reflect(setA) == reflect(setB)  is an unspoofable identity test. In other words, equality of mirrors is identity of reflectees.<br></blockquote><div><br></div><div>Hi Dave, if your language also supports a reliable identity check, and if you don't think that was a mistake[1], then I don't understand your previous question:</div><div><br></div><div><div style="font-size:12.8000001907349px">> But on topic, the question in my mind would be: “Why does your language support === in the first place?”</div></div><div><br></div><div>JavaScript is about as far from doing greenfield design as can be imagined, so it is not an option to reconsider having === be the way we spell that identity check. We have a huge corpus of code -- the web -- that we must not break. As Crock points out, JavaScript successfully spans a greater range of expertise, from novice to expert, than any previous language has done at such scale. At the extremes</div><div><br></div><div>* Pages are created by people who don't really understand the code they are modifying, nor the semantics of the language it is written in. They simply keep fiddling with it until it no longer seems to be broken, and then ship it. I used to have more mixed feelings about this until I realized that it is *precisely* how I use LaTeX.</div><div><br></div><div>* Libraries are crafted by experts and extensively tested across browsers and versions of browsers, to be linked into and composed with code of many others, which itself likewise spans this spectrum of expertise. </div><div><br></div><div>The first category, by being an accidental snapshot of what worked at a moment in time, may depend on invariants that their authors were not consciously aware of and could not articulate, but vaguely perceived (or not!) as a possible regularity that happened to work.</div><div><br></div><div>For the second category, such library code must make use of language-wide invariants in order to successfully co-exist and intimately interact with the wide wide range of clients into which it is linked.</div><div><br></div><div><br></div><div>Nevertheless, in successive versions of the language starting with ES3.1 we considered breaking many invariants, we decided to break some, and did so successfully. I agreed to those consensuses (consensi?), and in retrospect still agree with most of those. We carefully weighed the above factors and chose carefully which invariants to break and which to keep.</div><div><br></div><div>Based on the history of what === meant, I'm certain that we can't ever break ===, even once we introduce a new (reflective if you wish) high integrity identity test such as <a href="http://Object.is" target="_blank">Object.is</a>.</div><div><br></div><div>But here's an example of an invariant that we might get away with breaking:</div><div><br></div><div>(typeof x === typeof y && x == y) iff x === y</div><div><br></div><div>Specifically, I can see allowing future value types being able to override == to implement alleged equivalence class checks less precise than equality.</div><div><br></div><div><br></div><div><br></div><div>[1] If you are not making those assumptions and are questioning whether a language should have any identity check, no matter how spelled, my real answer is </div><div><a href="http://www.erights.org/elib/equality/grant-matcher/" target="_blank">http://www.erights.org/elib/equality/grant-matcher/</a></div><div><a href="http://www.erights.org/elib/equality/grant-matcher/history.html" target="_blank">http://www.erights.org/elib/equality/grant-matcher/history.html</a><br></div><div><br></div><div>I don't think it is possible to write the escrow exchange agent of</div><div><a href="http://research.google.com/pubs/pub40673.html" target="_blank">http://research.google.com/pubs/pub40673.html</a><br></div>without using reliable identity in some form. Although James Noble and Sophia Drossopoulou have figured out how to do it without the form of distributed identity shown in that paper. This surprised me! (Anyone interested in how should let me know privately.)<br><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
- David<br>
</font></span><div><div><br>
<br>
> On Jan 20, 2015, at 3:13 PM, Brendan Eich <<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>> wrote:<br>
><br>
> Mark S. Miller wrote:<br>
>><br>
>><br>
>>    (2) can't be meta-programmed to spoof identity. But it doesn't<br>
>>    leave anything like nominal types as found in many languages lying<br>
>>    around as an attractive nuisance (and how, in Java!).<br>
>><br>
>><br>
>> What I think I remember hearing from Tom is that Dave's main point, and the main argument with Tom, was precisely allowing proxies to intercede on === checks, in which case you wouldn't even have that as a reliable indicator.<br>
><br>
> Hmm, maybe -- but does Self have a reference-identity equivalence-relation operator that can't be spoofed? Might help to ask David, but to abstract from that particular SPLASH 2011 Q&A, obviously we won't be enabling such fakery in JS.<br>
><br>
> /be<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>    Cheers,<br>    --MarkM</div>
</div></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">    Cheers,<br>    --MarkM</div>
</div>