On Wed, Dec 4, 2013 at 11:01 AM, Peter Thiemann
<[email protected]> wrote:
> On 12/4/13 2:48 PM, Brendan Eich wrote:
>>
>> Peter Thiemann wrote:
>>>
>>> 1. Contracts implemented using proxies. Adding a contract to a program
>>> should never change the semantics of contract-abiding code - if the contract
>>> is violated, it is of course fine to crash.
>>
>>
>> Meaning throw an exception, which could be caught? That seems like it
>> could require a program change.
>
>
> Ideally, it should be an exception that cannot be caught by the code under
> contract.
> AFAIK, current implementations rely on user exceptions. I don't know what
> Racket does.
Racket throws user-level exceptions. I've never seen this change the
behavior of a Racket program, though.
Swamy et al's recent TS* paper intentionally exhausts the stack to
prevent the exception from being handled.
>>> Also, adding a contract to a program should not force you to change
>>> something else in your program: a very useful pattern is to impose a
>>> contract on code loaded at run time, say, a mashup. In this case, it is very
>>> cumbersome to patch up this code to use a different equalp (intercept the
>>> load, parse everything, rewrite the parse tree, etc) and it has to be done
>>> for eval, too.
>>
>>
>> Mashups seem content with identity-preserving membranes, but I defer to
>> Mark.
>>
>>> 2. Monitoring implemented using proxies. Here, you'd use the proxy to
>>> record all gets and sets applied to an object, for example, to create a
>>> replayable mock object. Again, adding monitoring should not change the
>>> meaning of the program and you should not be forced to change the code.
>>
>>
>> I would think such monitoring wrappers (I've written them) want only the
>> mock and never the object it wraps to escape to code that tests o === o.
>> Identity-preserving membrane, with the monitored object only on one side,
>> the mock only on the other.
>
>
> That sounds fine if you apply the wrapper globally, but what if you apply it
> locally in the scope of an interesting function? In that case, there is no
> clear boundary of what's left or right of the membrane, so that the wrapped
> object could be compared with its unwrapped target.
In general, membranes require a global level of control that contract
systems typically do not have. A contract system usually features a
form like this:
applyContract(contract, value)
There's no guarantee that the value isn't already used in other
places, and those other references should _not_ be affected by the
contract.
Sam
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
