🚀 go-pugleaf

In article <9209722.15242@mulga.cs.mu.OZ.AU>, lee@munta.cs.mu.OZ.AU (Lee Naish) writes:
> A couple of points raised by Richard's postings:
> >If it is possible to get a better approximation to solutions/3 without
> >coroutining, I would very much like to know how to do it.

> There are a couple of things:

> 1) Do quantifiers *properly*.  With code which has variables which should
> be local to the all solutions construct appearing elsewhere (eg
> 
> 	setof(X, ...), ...... X ...
> 
> ), either the different occurrences of X should be considered different
> variables or the compiler should generate an error.  At the very least,
> "style checkers" should COMPLAIN VERY LOUDLY.

Agreed.  David Scott Warren ran into this problem once, and was very
surprised.  Commercial Prologs are stuck with the backwards compatibility
issue:  the DEC-10 Prolog manual defined "X^p(X)" to be _exactly_ like
"p(X)" outside setof/bagof forms.  This overspecification was regrettable.
In fact the DEC-10 Prolog library treats existential quantifiers
specially inside not(_) as well, so that not(X^p(X)) is ok.

My preference would be for the compiler to rename existentially quantified
variables _and_ for the style checker to warn about it.

> 2) It wouldn't hurt to have versions of setof/3 which produced errors
> when called "outside their design envelope", rather than returning
> *something*.

The Quintus library contains bag_of_all/3 and set_of_all/3 which are
"safe" versions of findall/3.  If there are any free variables in the
Goal argument they report an error.  (This makes it safe for them to
return empty lists.)  I'll add
	safe_{bag_of,set_of,bag_of_all,set_of_all}/3
	safe_grouped_{bag_of,set_of}/4
that report an error if the list of solutions is non-ground.

-- 
I am writing a book on debugging aimed at 1st & 2nd year CS students using
C/Modula/Pascal-like languages.  Please send suggestions (other than "you
_must_ cite "C Traps and Pitfalls") to ok@goanna.cs.rmit.oz.au