[+tdisney, +cormac] On Fri, Dec 27, 2013 at 4:47 AM, Philip Wadler <wad...@inf.ed.ac.uk<https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=wad...@inf.ed.ac.uk> > wrote:
> This thread has gone dead. I am excited at the prospect that JavaScript > might support proxies for contracts if a suitably expressive 'sublanguage > of projections' can be isolated. Is there any progress? How can I help > carry this forward? Yours, -- P > > > . \ Philip Wadler, Professor of Theoretical Computer Science > . /\ School of Informatics, University of Edinburgh > . / \ http://homepages.inf.ed.ac.uk/wadler/ > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > The more I think about it, the more I think the work on Temporal Contracts < http://users.soe.ucsc.edu/~cormac/papers/icfp11.pdf> by Tim and Cormac (cc'ed) is relevant. Tim and Cormac, our normal notion of a contract is that it should be a projection, i.e., that the contract may only cause rejection or non-termination but may not otherwise change the observable behavior of the system to which they are added. However, the other contract frameworks we've discussed so far on this thread are not able to enforce that the contracts that parameterize the framework may only be projections. IIUC, because your contracts are predicates on event sequences, the contract framework need only provide the contracts with information about the computation, and need not ever provide direct access to the mutable objects engaging in the computation of interest. The contracts need only be provided with these event sequences as input, and need only be provided with the ability to signal acceptance or rejection as an output channel. Given a system that can enforce confinement, the contracts need not be given any further access to the world outside themselves. If all this is true. then this becomes a meaningful context in which to explore the object identity issues of the title. I'll separately forward you the messages of this thread to date for background. -- Cheers, --MarkM _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
