[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