From ok@atlas.otago.ac.nz  Fri Aug 11 02:48:46 2000
Received: from atlas.otago.ac.nz (atlas.otago.ac.nz [139.80.32.250])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id CAA12203
	for <prolog@swi.psy.uva.nl>; Fri, 11 Aug 2000 02:48:44 +0200 (MET DST)
Received: (from ok@localhost)
	by atlas.otago.ac.nz (8.9.3/8.9.3) id MAA01698;
	Fri, 11 Aug 2000 12:48:37 +1200 (NZST)
Date: Fri, 11 Aug 2000 12:48:37 +1200 (NZST)
From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
Message-Id: <200008110048.MAA01698@atlas.otago.ac.nz>
To: p.singleton@keele.ac.uk, prolog@swi.psy.uva.nl
Subject: Re:  runtime detection of singleton variables

	I could lash up an ad hoc notation for "don't bother getting this attribute"
	but it wouldn't be relational, nor readily amenable to being mechanically
	generated, nor very satisfying...
	
I suggest that a declarative way of getting the attributes that you
want is to explicitly SAY which attributes you want, rather than use
exotic machinery to try and guess.

The really really obvious thing (I blush to suggest it) is to
design a little language and use term_expansion/2 to transform it
to something less obvious.

For example,

    :- db(ext(date,owner,+key,big,val,huge,gross)).

    foo(Key, Val) if_db
	ext(_, _, Key, _, Val, _, _),
	Val > 28.

might turn into

    foo(Key, Val) :-
	(   var(Key) ->
	    select([Key=key,Val=val], ext, [val>28])
	;   nonvar(Key),
	    select([Val=val], ext, [key=Key,val>28])
	).

Here "select([Var1=id1,...,Varn=idn], Rel, [cond,...,cond])"
selects tuples from Rel that satisfy each condition cond and then
bind Prolog variables Var1...Varn to the values of the corresponding
attributes.

	What I think I *really* want is a new metalogical built-in
	predicate to detect singleton variables in a goal (there are
	fourteen in the example above) so my code can avoid wasting
	effort instantiating them.

If you could ask, they wouldn't be singletons.  We did put some thought
into this at Quintus, because some other Prolog implementors had come
up with a tagging scheme where singletones got a special tag, but
*at that time* and *for the applications we considered* it really was
a lot of effort just to make things slower, so we didn't do it.
Something of the sort could be important for garbage collection and
especially for concurrency.  But if you could mention the things in
order to ask, they really wouldn't be singletons any more.

	I guess there may be problems identifying all variables whose
	instantiation can serve no purpose, and there may even be
	problems formalising this requirement, but a
	"sound-but-incomplete"/"fail-safe" test for e.g. easy-to-spot cases
	could be of value.

Well, in one guise, it's just "garbage collection".

