[Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem tomvc.be at gmail.com
Thu May 12 06:20:51 PDT 2011


@David: One area of related work is that of Kiczales' metaobject protocols
and more generally, "open implementations". Kiczales used the terminology of
"rules of behavior" rather than "invariants". All of this work originated in
dynamic languages (various flavors of Lisp in particular).

As for the conflicting issues of run-time enforcement and performance, in
the MOP literature, a trick that is often applied is to use partial
evaluation where possible. The use of partial evaluation makes a distinction
between "load-time" and "run-time", allowing expensive conformance checks to
be moved to "load-time". While this works great for structural invariants
(e.g. ensuring that an inheritance graph is loop-free), it probably is no
help at all for enforcing behavioral invariants (such as those associated
with non-configurable properties).

(BTW, passing a function proxy's prototype as an argument to
Proxy.createFunction ahead of time, and testing at proxy creation time
whether it inherits from Function.prototype is one example of this
technique. If one would opt for a getPrototypeOf trap, the check would need
to be performed time and time again, at "run-time", so to speak).

Cheers,
Tom

2011/5/11 David Bruant <david.bruant at labri.fr>

> Le 11/05/2011 08:41, Allen Wirfs-Brock a écrit :
>
>  I think we are dancing around one of the key differences between static
>> languages and dynamic languages.  Static languages make guarantees about a
>> set of potentially complex invariants  (for example, subtype conformance).
>> They can do this because the necessary work to detect violations of those
>> invariants is performed ahead of time before the program is allowed to
>> execute.  Dynamic languages do most invariant validation as the program runs
>> and hence generally restrict themselves to guaranteeing simple invariants
>> (for example, memory safety) that can be cheaply performed many times as the
>> program runs.  Dynamic languages generally avoid expense checking of complex
>> invariants and instead assume that any critical violation of complex
>> invariants will ultimately manifest  themselves as violations of the simple
>> invariants that are checked.
>>
>> A related difference is that a static language generally rejects programs
>> when it proves the set of all possible program inputs produces some states
>> that violate the language's invariants.  The program is rejected, even if
>> the input states that produce the invariant violations will never occur in
>> practice.  This is a conservative (or pessimistic) approach -- if a program
>> might fail, we assume it will fail.  Dynamic languages generally only reject
>> programs (at runtime) when the actual data values used by the program
>> violates the language's invariants.  This is a permissive (or optimistic)
>> approach -- if a program might work, we give it the benefit of the doubt and
>> let it run up to the point it begins to misbehave.
>>
>> The configurability restrictions on Proxies seems to be trying to apply a
>> static language perspective to the very dynamic ES language.  They are based
>> upon a complex invariant (what can/cannot be assumed after  observing the
>> state of a configurable attribute).  Because, there is at best difficult to
>> guarantee that user written proxy handlers will correctly enforce the
>> invariants associated with of configurable:false it is forbidden for a proxy
>> to set configurable to that state.  It is pessimistic, it says that because
>> somebody might write a buggy proxy setting configurable we won't let them
>> write any proxy that sets configurable.  An alternative that has been
>> proposed is to try to dynamically enforce the configurable invariants.  But
>> that is an example, of moving expensive (and probably highly redundant)
>>  complex invariants checks into runtime.  While it would catch buggy
>> programs, but has the potential of imposing a significant runtime
>> performance penalty on valid programs.
>>  The normal dynamic language approach to this sort of problem is to be
>> optimistic about the validity of the program while continuing to guarantee
>> memory safety, and depending upon conventional testing procedure to detect
>> more complex error conditions.
>>
> I understand the rationale that leads to the difference you describe in
> static/dynamic languages design. I understand it and I think these are good
> reasons. However, I can't help asking you some sort of proof. Has some
> research been done in the area?
> Are there dynamic languages that tried to enforce invariants at run-time?
> What lessons did they learn from that experience?
> Was the cost on valid program big enough to question these checks?
> Are there examples of dynamic languages interpreter with static analysis
> that were able to diminish this cost? Diminishing the cost to make the
> program "as fast in the long term"? (I quote, because I know that "as fast"
> and "in the long term" are vague notions)
>
> David
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110512/63bfd1b0/attachment-0001.html>


More information about the es-discuss mailing list