Re: [Xsb-development] Question on term comparison

[Kostis S. <ko...@cs...>]

Hi Bart,

 > I don't have to bet: I know about their disappointment and horror when
 > the implementation dependent feature suddenly blew their code, I know
 > it took quite some time to figure out what was happening, I know PLAI
 > suddenly got sprinkled with many more sort/2 calls "just to make sure
 > this list is still in order". I bet that if they had known in advance
 > they would have avoided order of free variables as the plague.

Fine, but it seems to me that what you are describing above, although
related, is a slightly different angle of the issue we are discussing.

I think we agree that sort/2 (that works on non-ground terms) is handy
to have for duplicate elimination only but there is no guarantee (in
SICStus there is, but with `plain' copying GC there is not) that once
one has created a sorted list:

	[X1,X2,X3]

with X1 @< X2 @< X3 the list will remain sorted when she is about to
use it one or two calls later, is there?

Similarly, there is no guarantee that:
	[p(X1),p(X2),p(X3)]
will remain "sorted", right?

So I guess the issue is not whether @< should work with variables or not,
but whether the user can later rely on its result.  She obviously CANNOT
and she should be educated about it.  But I do not see how this is
different than educating them on not relying on the result of doing a
sort/2 on a list of non-ground terms.

I do not know exactly why, but somehow this different treatement of @<
with variables (throw exception) and sort/2 with variables (OK but one
cannot rely on the list being sorted) seems to me a bit inconsistent.

Perhaps I would feel differently if either sort/2 was allowed to work
only on ground terms (throwing an exception on terms where comparison
of variables was needed) or if it was simply renamed remove_duplicates/2
instead.

Cheers,
- Kostis.