Re: More extensive (variable) style checking

On Fri, Aug 2, 2013 at 9:41 AM, Jan Wielemaker <[email protected]> wrote:

> I first applied that to compiled BIPs, now =/2, ==/2, \==/2,
> var/1, nonvar/1 (more will follow).  So, if you do
>
>         t :- var(X), writeln(X).
>
> It will tell you that var(X) is always true. Similar, it tells you X==Y
> is always false in this:
>
>         t(X) :- X == Y, writeln(Y).
>
> So far, so good. The next one is probably also meaningful because it is
> also used by ECLiPSe: singleton detection in disjunctive branches. So
>
>         t :-
>             (   hello(X)
>             ;   world(X)
>             ).
>
> will tell you that X is a singleton.


These will be quite helpful.


> The next one is less clear. A user complained to often initialise
> variables in one branch, forgetting to do so in another one. The check
> verifies that variables introduced in a disjunction and used after it
> are introduced in both branches. Thus,
>
>         t :-
>             (   hello(X)
>             ;   world
>             ),
>             writeln(X).
>
> is considered something to warn about. This gives some warnings on the
> SWI-Prolog libraries. Most of them concern indeed ugly code, but not
> errornous. The question is whether this a meaningful warning?


I'd prefer not to have warnings in this case.  I think compilers should
only complain if they have very high certainty that code is wrong;
otherwise, they should trust the developer.

Opinions? Other useful checks we can do at this level without a complete
> mode system?


Can this system eliminate the false singleton warning on Query in a
quasiquote like {|uri||/path?$Query|} ?  Those have become a bit of a thorn
in my side :-)

Is it possible to warn about unreachable code?  For example,

    t :-
        ( ground(X) -> unreachable ; do_stuff ).

That makes "failure slice" debugging generate warnings, but I think that's
acceptable.

-- 
Michael
-------------- next part --------------
HTML attachment scrubbed and removed