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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
