Re: Ann: SWI-Prolog 6.5.1

On 08/13/2013 12:21 PM, Abramo Bagnara wrote:
> Il 12/08/2013 22:43, Jan Wielemaker ha scritto:
>> Hi,
>>
>> I've uploaded SWI-Prolog 6.5.1.  There are a lot of changes.  Highlights:
>>
>>    - Detection of `semantic singletons' by the compiler.  This proofs
>>      to result in a quite high percentage of real bugs.  My rough
>>      estimate is about 1/3th!  And this is on established code!
>>    - Singleton detection with quasi quotations (do not claim a
>>      singleton of a QQ introduces a reference to the singleton
>>      in its expansion).
>>    - prolog_load_context/2 provides access to variable names.
>>    - term_expansion/4 and goal_expansion/4 to allow converting
>>      source layout information.  This goes through most of the
>>      compiler toplevel, but isn't actually used yet.
>>    - halt/0 can now be called from threads.  Various fixes to
>>      program termination, notably for xpce on Windows.
>>    - JPL dll hassle is hopefully resolved.
>>    - Cygwin port is updated.
>>    - Lots of small stuff and cleanup.
>>
>
> :- style_check(+var_branches).
>
> p :-
>      (s(A) ->
>          true
>      ;
>          fail
>      ),
>      write(A).
>
> Warning: /home/abramo/z.pl:3:
> 	Variable not introduced in all branches: A
>
> Should we consider this a false positive?

Yes.  There are many more of these.  I played with this warning.  Rough
statistics is that there were about 100 cases in the code loaded (Prolog
libs, ClioPatria, Prolog website).  I think I investigated about 20-30.
Found 2 real bugs and a few reminders to write the code more cleanly.
But, that concerns established code.  Possibly it more frequently
triggers during development and it might be possible to develop a
programming style where it is fruitful.  I left it in for now.  It
may be taken out in the future or it may become more precise, for
example by exploiting determinism information to decide that the
branches where the variable is not introduced will never complete
due to failure or exceptions.  Just checking fail might already
cover most cases where failure is intended.  Exceptions need something
more because in my experience raw usage of throw/1 is too much typing.
A significant number of the cases I found were

	(   Cond1(X)
	->  Var = ...
	;   Cond2(X)
	->  Var = ...
	;   {type/domain}_error(SomeType, X)
	).

	Cheers --- Jan