On Tue, Dec 3, 2013 at 3:11 PM, Mark Miller <[email protected]> wrote:
> On Tue, Dec 3, 2013 at 2:11 PM, Shriram Krishnamurthi > <[email protected]>wrote: > >> I think I too would appreciate a quick summary of this join proposal, >> rather than chasing down that entire thread... Joe and I have >> essentially left === out of Pyret due to the issues with membranes, so >> we're very eager for someone else to tell us what to do. (-: >> > > In the absence of concerns about concurrency, > > var z = join(x, y) > > means that z designates what both x and y designate. If there is nothing > that both x and y designate, then the operation fails. The key thing about > the precise definition of "designate" is: > > Given that Alice got x from Bob and Alice got y from Carol, if Alice uses > z where Bob would have expected Alice to use x, and Alice uses z where > Carol would have expected Alice to use y, then neither Bob nor Carol should > have any cause for complaint. > > Leveraging this notion to extend join for contract-membranes, if x > represents access to Dave as attenuated by Bob, and y represents access to > Dave as attenuated by Carol, then it should be acceptable to Bob for Alice > to use z where he expects Alice to use x, and it should be acceptable to > Carol for Alice to use z where she expects Carol to use y. > Should be "... where she expects Alice to use y." > > > Of the references I gave, if you're going to read just one, it should be "the > use of join in figure [2] of < > http://research.google.com/pubs/pub40673.html> together with the > explanation of the security purpose it serves". Please do see that figure. > I copy the relevant text below: > > The definition of join on page 6: > > Q.join(xP,yP) takes two promises and returns a promise for the one object > they both designate. Q.join is our eventual equality operation. Any > messages sent to the joined promise are only delivered if xP and yP eventually > come to designate the same target. In this case, all messages are > eventually delivered to that target and the joined promise itself > eventually becomes fulfilled to designate that target. Otherwise, all these > messages are discarded with the usual rejected promise contagion. > > The explanation of the security purpose it serves in the escrow exchange > agent code of Figure 2: > > If the escrow contract simply asks Alice’s purse for a new empty purse > (srcPurseP > ! makePurse()), Alice could return a dishonest purse that acknowledges > deposit without transferring anything. Alice would then obtain Bob’s stock > for free. If it simply asks Bob’s purse, then Bob could steal Alice’s money > during phase 1. Instead, it checks if their makePurse methods have the > same object identity by using Q.join on promises for these two methods. > This is why, on lines 3 and 7 of Figure 1, all purses of the same currency > at the same bank share the same function as their makePurse method. If > the Q.join of these two methods fails, then either Alice was dishonest, > Bob was dishonest, or they simply didn’t have prior agreement on the same > currency at the same money issuer. > > > -- > > Cheers, > --MarkM > -- Text by me above is hereby placed in the public domain Cheers, --MarkM _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
