[Harmony Proxies] Proposal: Property fixing

David Bruant david.bruant at labri.fr
Wed May 11 06:26:03 PDT 2011

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)


More information about the es-discuss mailing list