Re: More extensive (variable) style checking

On 08/03/2013 04:14 AM, Richard A. O'Keefe wrote:
> 
> On 3/08/2013, at 6:55 AM, Alan Baljeu wrote:
> 
>>>     t :-
>>>       (   hello(X)
>>>       ;   world
>>>       ),
>>>       writeln(X).
> 
> [world might throw an exception, so the use of X in the last line
>  might not be reachable.]
> 
> I'm with Alan Baljeu on this one.  Before throw, I used to use 'abort'
> this way, although in the form
> 	( hello(X) -> true ; world ),
> 	write(X), nl.
> 
> (I find the Pascal-inspired 'writeln' horribly confusing,
> because it combines 'write' with 'nl', not with the nonexistent 'ln'.)
> 
> Ulrich Neumerkel has recently suggested that portable
> programs wanting to throw a standard error(Error_Term, Imp_Def)
> ball but unable, because Imp_Def is implementation defined, to
> provide any specific value for Imp_Def, should use _.  So one
> might have
> 
> hurl(Error_Term) :-
>     (  on_system_x -> system_x_imp_def(Imp_Def)
>     ;  on_system_y -> system_y_imp_def(Imp_Def)
>     ;  /* don't know what to do on other systems */
>     ),
>     throw(error(Error_Term, Imp_Def)).
> 
> might actually be reasonable code to write.

Yes, but also the sort of code where it might be nice to have
some construct that explicitly tells the system that you leave
the value unbound, such as Imp_Def=_

>>> I find spurious information to be deleterious to development
> 
> Here I _almost_ part company with Alan.
> I am willing to tolerate a small proportion of false positives
> from a checking tool *IF* I get a high rate of true positives.

I'm mostly experienced with C here.  gcc -Wall gives lots of
messages about things that are perfectly valid C, such as
if ( x = 42 ).  Most likely people used to do this quite a
lot (surely I did).  Currently, gcc wants to see if ( (x=42) ),
which is of course exactly the same, but as embracing the
assignment is not commonplace, this tell gcc you know what
you are doing.

Also in C, you get nested if-then that sets a variable in
most branches and not in some.  That will result in a
`possible not initialised' warning, which may be bogus
because the remainder of the logic ensures you only access
the variable if it is initialised.  Nevertheless, I'm
typically happy to put a bogus initialisation in the other
path(s), just to keep the message.

> What the example _does_ show is the weakness of a variable tracker
> that has no idea of what predicates other than a handful of
> built-in predicates actually do.

True.  Knowing more, would help.

> I'd quite like to be able to declare my intentions about predicates.
> (But not to be forced to declare them.)
> This predicate _must_ terminate by throwing,
> that predicate _must_ terminate by throwing or failing,
> this predicate may refer to at most these dynamic predicates,
> that predicate may alter at most those dynamic predicates,
> ...

Would be nice.  The Prolog community is struggling with this
for a long time :-(.

Needless to say, all these options will be turned on/off by
style_check/1.  Default for this one will surely be off.

Thanks for the input.

	Cheers --- Jan