Re: compare function return values Panu A Kalliokoski (10 May 2005 16:41 UTC)
Re: compare function return values bear (04 Jun 2005 18:07 UTC)
Re: compare function return values Panu Kalliokoski (06 Jun 2005 08:24 UTC)
Re: compare function return values Panu Kalliokoski (06 Jun 2005 09:22 UTC)
Re: compare function return values bear (06 Jun 2005 22:55 UTC)
Re: compare function return values Per Bothner (07 Jun 2005 00:00 UTC)

Re: compare function return values Panu A Kalliokoski 10 May 2005 16:41 UTC

Sorry for bugging you so much over such a minor issue... (however, I
hope this will be changed and not left as is just for "not
bothering"...)

On Sun, May 08, 2005 at 10:25:28PM +0200, Jens Axel Søgaard wrote:
> The "numbers can be used in index computations" also refer to the fact
> that one at the assembly level can dispatch to the proper branch by
> doing a simple table lookup based upon the return value of a compare
> function.

This can't possibly lead to any performance gain, because in the general
case, the compiler will have to bound-check the integer returned by the
compare function, which leads to two checks - the same number of
comparisons as caused by checking which symbol it is.

> >Besides, enumerations are generally handled in a "case" clause, where
> >symbols are automatically quoted:
> >
> >(case (compare x y)
> >  ((eq) ...)
> >  ((lt) ...)
> >  ((gt) ...))
>
> The user of the srfi should write:
>
>   (if3 (compare x y)
>     (...)
>     (...)
>     (...))
>
> The control operators provided ought to support all uses of compare
> functions.

True.  I acknowledge the fact that most of the time users will not need
deal with the return values of compare functions at all.  However, in
the case that they do, I would like them to be something descriptive.
For example, if a student writes in a REPL,

(compare "asia" "antecedent")

it would be IMO more intuitive if the answer was > (or gt), not 1.

> The overall idea is to provide enough constructs such that the user
> of this srfi never needs to know the underlying represention of the
> three cases. Thus the user is ought not to use bad practices from other
> languages.

Yes.  So, my argument boils down to this:

(1) there are no good reasons for using integers as the return values.
(2) bad code should be discouraged. (eg. using compare values for
indexing, addition etc.)
(3) using symbols would lead to more descriptive user experience.
-> ergo, the return values of compare functions should be symbols.

Panu

--
personal contact: xxxxxx@iki.fi, +35841 5323835, +3589 85619369
work contact: xxxxxx@ling.helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/