[resending] On Tue, Jan 20, 2015 at 4:44 PM, David Ungar <[email protected]> wrote:
> Oh, the troubles with email. > > I’ll try again: > > 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. > 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. > So you can always substitute an object with similar behavior for another. > > At meta-level, you can interrogate the object to look inside; what slots > it has, etc. > > This design confers reusability, eases deployment, proxying, etc. The > paper Gilad and I wrote for OOPSLA 2004 (“Mirrors…”) explains this well. > 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.) > > In keeping with this design, our (base-level) identity operator was just > another message. > > 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? > 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. > > I apologize for belaboring the obvious. > > From your response, it sounds as if == is non-overidable today. Is that > right? > > - David > > > > > > > On Jan 20, 2015, at 4:28 PM, Mark S. Miller <[email protected]> wrote: > > On Tue, Jan 20, 2015 at 3:22 PM, David Ungar <[email protected]> wrote: > >> Yes, Self does have an unspoofable one, but at reflective level, not base. >> >> >> In JS syntax: >> >> reflect(setA) == reflect(setB) is an unspoofable identity test. In other >> words, equality of mirrors is identity of reflectees. >> > > 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: > > > But on topic, the question in my mind would be: “Why does your language > support === in the first place?” > > 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 > > * 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. > > * 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. > > 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. > > 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. > > > 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. > > 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 Object.is. > > But here's an example of an invariant that we might get away with breaking: > > (typeof x === typeof y && x == y) iff x === y > > Specifically, I can see allowing future value types being able to override > == to implement alleged equivalence class checks less precise than equality. > > > > [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 > http://www.erights.org/elib/equality/grant-matcher/ > http://www.erights.org/elib/equality/grant-matcher/history.html > > I don't think it is possible to write the escrow exchange agent of > http://research.google.com/pubs/pub40673.html > 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.) > > > >> - David >> >> >> > On Jan 20, 2015, at 3:13 PM, Brendan Eich <[email protected]> wrote: >> > >> > Mark S. Miller wrote: >> >> >> >> >> >> (2) can't be meta-programmed to spoof identity. But it doesn't >> >> leave anything like nominal types as found in many languages lying >> >> around as an attractive nuisance (and how, in Java!). >> >> >> >> >> >> 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. >> > >> > 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. >> > >> > /be >> >> > > > -- > Cheers, > --MarkM > > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
