More extensive (variable) style checking

Hi,

The traditional singleton checking is extremely useful, but also
a bit limited.  I've been asked to enhance that, and messages from
the compiler in general.  So, I've established a -still quite
experimental- infrastructure to provide the compiler with
variable name information and term layout and infrastructure to
print messages from the compiler.

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. Unlike ECLiPSe (AFAIK), this is not
checked at the syntactical level by read/1, but by the compiler which
discovers that X is not a real singleton, but semantically it a named
variable that plays no role in communication. At that moment it will
issue a warning.

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? And, if
so, how one can avoid the warning after validating that the code is
correct? One option for the latter is

	t :-
	    (   hello(X)
	    ;   world,
		X=_
	    ),
	    writeln(X).

Now, only the compiler will complain that X=_ is pointless, which in
itself is good because it will replace it with the VM instruction TRUE.
The open question is how to silence this though ...

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

	Cheers --- Jan