On 03.12.2013, at 22:09, Mark Miller <[email protected]> wrote:
>> ---------- >> From: Andreas Schlegel <[email protected]> >> Date: Tue, Dec 3, 2013 at 6:33 AM >> To: Tom Van Cutsem <[email protected]>, "Mark S. Miller" >> <[email protected]> >> Cc: Brendan Eich <[email protected]>, >> [email protected] >> >> >> Hello, >> >> yes you're right, the problem of the contracts researched by prof. Thiemann >> was, that the targets behind the proxies could not be compared by == and ===. >> >> How can I merge contracts of multiple proxies and represent them by just a >> single proxy, if I cannot compare them (or get the target)? >> >> We have discussed first an approach with new operators spezific to proxy >> comparism but this is not the way. >> If I can include a trap for asking the proxy if he's transparent or not, it >> is possible to use the same operators by asking the proxy. > > > Yes, for JS or any language where identity is based on an equality > *predicate*, it is too late: The conflict between contracts and identity > can't be fixed. Note that, through my lack of foresight about this issue, E > is among the languages that can't be fixed. Actually, I don't think it is too late. We have come up with a design where the proxy's handler can determine whether equality is opaque or transparent - this is what Andreas is currently trying to implement. This way, you may create proxies with different EQ semantics while still guaranteeing that EQ is an equivalence relation. > > For new languages or for subsets of an existing language, such as the > distributed portion of Dr. SES, a weaker equality primitive, join, could be > extended to be in bed with contract-membranes in ways that maintain most of > what is useful about object identity, as explained in the thread with Phil > and Jeremy. Not only is join compatible with contract-membranes, it enhances > them by providing a useful new contract combinator. I didn't have time, yet, to chase up all references that you gave in the email exchange, but it is not quite clear to me in what situation you want to apply the join operator. It seems it only makes sense to apply it to a pair of objects that (transitively via a proxy chain) refer to the same target object, but potentially imposing different constraints / contracts. In that case you want to impose both constraints on the joined object, right? So you'd have to check EQ-ness first? Otherwise you get an exception? > > An open question is how to arrange for the built-in join to be in bed with > user-extensible contract-membranes in a way that both preserves security > under mutual suspicion and provides the needed functionality. A good test > case is a local and a distributed implementation of Horton assuming mutually > suspicious machines. > > >> >> Best regards >> Andreas > > > > -- > Cheers, > --MarkM -Peter _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
