Re: Ann: SWI-Prolog 6.5.1

On 08/13/2013 10:59 AM, Abramo Bagnara wrote:
> A similar issue comes from the following:
>
> goal_expansion(nofail(G),
>                 (G *->
>                     true
>                 ;
>                     print_message(error, assumption_failed(G)),
>                     trace,
>                     G
>                 )).
>
> f1(In) :-
>      nofail(p(In, _Out)).
>
> f2(In) :-
>      nofail(p(In, Out)).
>
> f3(In) :-
>      nofail(p(In, _)).
>
>
> Both f1 and f2 gives warnings, f3 does not give any warnings, but asks
> to me to reduce code readability.

Yes.  That is a fairly realistic example.  To be honest, I don't know
what to do about it.  The alternative is to do all this purely at the
syntactic level, but that things such as below won't do the job
correctly (comes from SICStus compatibility layer).

	goal_expansion(if(If,Then,Else), (If *-> Then; Else)).

I started this at the compiler level for two reasons:

   - To make cases as the if/3 above work
   - The compiler has to analyse the variable status anyway, so
     doing it from there avoids duplicate work.

Here is a case where you want to do the analysis prior to expansion :-(

Of course, we could make the variable analysis of the compiler
available as a separate functionality and use it before goal/term
expansion on the input.

An alternative is to stop complaining about _X being used multiple
times.  That would be really easy.

Another alternative might be to do (limited) mode analysis. I expect
that mode analysis will show a large overlap in errors, while it is not
important how a variable is called.  The problem is that this gets us
into the whole discussion of typing languages, mode systems, assertion
languages, etc.

	Cheers --- Jan