Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!rutgers!njin!uupsi!sunic!enea!helios!kim
From: kim@helios.enea.se (Kim Wald`n)
Newsgroups: comp.lang.eiffel
Subject: Re: Errors in COMPARABLE and PART_COMPAR
Message-ID: <KIM.90May9154638@helios.enea.se>
Date: 9 May 90 13:46:38 GMT
References: <KIM.90May5032047@helios.enea.se> <325@eiffel.UUCP>
Sender: kim@enea.se
Organization: Enea Data AB, Sweden
Lines: 91
In-reply-to: stephan@eiffel.UUCP's message of 7 May 90 23:19:45 GMT

In article <325@eiffel.UUCP> stephan@eiffel.UUCP (Philippe Stephan) writes:

>	   1) The forthcoming version of the compiler allows circularly
>   defined assertions: when assertion checking involves a call to a
>   routine, no assertion check is made on the called routine. What's
>   pointed out is actually a bug in 2.2.

Seems reasonable.

>	   2) The function `equal' from ANY is redefinable. Its default
>   behavior is to do a field by field comparison, but why not?
>   The freight capacity of a truck can of course be the only criterion
>   for a sort, if you want so.

You are missing the point.

First, class COMPARABLE implements a total order relation.
In a total order relation, strict order and equality are not independent.

	a > b   is identical to   b < a 

and

	a = b   is identical to   ( not a < b  and  not a > b )

BY  DEFINITION.

Any other implementation of "=" breaks the deepest meaning of the class,
as fundamental properties, like

	"For all pairs, exactly one of 
		a < b
		a > b
		a = b
	is true"

will no longer hold.  This is the worst that can happen to a class.

So the current implementation of COMPARABLE is plain wrong, and can
easily cause subtle bugs in applications using it.

It can only be correct by accident, in cases when ``equal'',
whether redefined or not, HAPPENS to coincide with the definition above.

Worse still, only "<=" in COMPARABLE uses ``equal'', while ">=" has the
correct implementation
	Result := not (Current < other)
so the meanings of the "=" parts in "<=" and ">=" are not even the same!

(I'm using "=" as a simple notation for the corresponding concept in
order relations here.  It is not to be confused with the non-redefineable
reserved Eiffel operator "=".)

The correct thing is to implement "<=" as
	Result := not (other < Current)
in accordance with the definition of total order relations (as in ">=").

There is no reason whatsoever to involve ``equal'' from ANY, which is 
a feature to check object identity.  The equality concept wanted as part
of an order relation is something else.

When you are ordering trucks by freight capacity, it seems reasonable to
consider a yellow 2 ton truck as neither greater nor smaller than a
green 2 ton truck. If you get a freight order for 2 tons, any one will do.

But you still want a way to distinguish between them, should you ever need 
to smuggle 2 tons of whisky through the green forrest at the frontier,
where a yellow truck is much too conspicuous.

Second, class PART_COMPART implements a partial order relation, which means
that for some pairs neither of 
	a < b
	a > b
	a = b
may hold.

Therefore, the meaning of "=" cannot be inferred from "<", but their semantics 
are still closely linked, so a descendant class should define both for
consistency.  This means that one of "<=" and ">=" should also be deferred.

As should be clear from the argumentation above, using ``equal'' from ANY 
in a default implementation of "<=", even if it is redefineable, is 
plain wrong for class COMPARABLE, and ad hoc and confusing at best 
for class PART_COMPAR.

This may be corrected by applying the diffs from my previous article.


-- Kim Walden
Enea Data, Sweden
kim@enea.se