[PEAK] Adding early ambiguity warnings to PEAK-Rules?
P.J. Eby
pje at telecommunity.com
Thu Aug 19 10:56:21 EDT 2010
At 03:17 PM 8/19/2010 +0300, Ðиколай wrote:
>Wild idea: use something like
>
>when(f, (A,B), delaycheck)(...)
>when(f, (B,A), delaycheck)(...)
>
>del delaycheck
>
>and trigger check when delaycheck is collected or at first call f() to
>warn about missing 'del delaycheck'. If no delaycheck is provided do
>checks normal way
I actually thought of:
with delayed_checking(f):
when(...)
when(...)
But really, the problem with *any* explicitly deferred checking is
that it's making you work harder to do things in the most desirable
sequence (i.e. general-to-specific). The system should encourage you
to do things the right way.
I think that at least in the first official release, I will just go
with improving the error message, e.g.:
"""
Method ambiguity in function foo.bar between:
Around value(False) defined at some.module:81
condition1 and condition2 and condition3
Around some_name defined at other.module:27
condition1 and condition2 and condition4
A rule is probably missing for:
condition1 and condition2 and condition3 and
condition4
"""
In the specific case of the A/B example, if you forgot B, B you'd see:
"""
Method ambiguity in function foo.bar between:
Around value(False) defined at some.module:81
(somemodule.B, somemodule.A)
Around some_name defined at other.module:27
(somemodule.A, somemodule.B)
A rule is probably missing for:
(somemodule.B, somemodule.B)
"""
The hardest part of this is going to be implementing a pretty-printer
for condition expressions, although tracking all the original
locations, etc. is no picnic either. (Ironically, generating the
suggested-missing rule is trivial, since it's just the intersect() of
the ambiguous rules' conditions.)
More information about the PEAK
mailing list