# Re: Naming, compare function return values

This page is part of the web mail archives of SRFI 67 from before July 7th, 2015. The new archives for SRFI 67 contain all messages, not just those from before July 7th, 2015.

```Panu Kalliokoski wrote:
```
```On Thu, May 05, 2005 at 07:37:21PM +0200, Jens Axel Søgaard wrote:

```
```symbols {less, equal, greater} (or {lt, eq, gt}).  The only reason to
use the nondescriptive values is AFAIU the possibility to add and
multiply values produced from compare functions, which easily leads to
ugly code.  So, is there some kind of rationale for the codomain of
compare functions?
```
```
See the section "How to represent the three cases?" in the
```
```
Sorry, I had somehow missed this.  But I disagree heavily with the
rationale represented there.  Basically, there are three arguments
presented there:

(1) numbers can directly be used in index computations (close to my
point about addition and multiplication).  In Python, where branch
expressions don't exist (they only have shortcutting and/or expressions
and an if statement), it is commonplace to use an idiom like

[false_value, true_value][test]

because most tests are guaranteed to return a value in {0,1}.  In my
not-so-humble opinion, getting rid of a comparable abomination would be
reason enough to use symbols instead of integers.  (Assignments in C are
also "handy", but few people deem this an advantage.)
```
```
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.

It is not the intention that an user of the srfi at the Scheme level
should inherit the Python idiom. In stead he should use the function
if3 (if=?, if<?, if>?, if<=?, if>=?, if-not=?) from section 4.6 "Using
Compare Functions":

<http://srfi.schemers.org/srfi-67/srfi-67.html#node_sec_4.6>

```
```(2) numbers are self-evaluating literals.  I don't know about your
feelings about Scheme or Lisp in general, but in my opinion the single
best thing about scheme is the symbol data type.  If the requirement of
quoting literal symbols is bad enough to favor numbers over symbols in
what is really, truly an enumeration and nothing like a count, metric or
index, there's something very wrong about the Scheme/Lisp syntax.  In my
opinion, Scheme/Lisp programmers should be proud of having real
descriptive tags, not shun them because they're not self-evaluating.

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.

```
```(3) (declared of minor importance) Scheme systems usually treat small
integers as unboxed values.  If the point is to say that integers have
less overhead because they need not be heap-allocated, the situation is
quite on the contrary: integers are not guaranteed to be unique but
symbols are, so there is at most one 'eq, at most one 'lt and at most
one 'gt.  So, if we want to _guarantee_ little overhead for the return
values, they should be symbols, not integers.
```
```
An instance of a symbol is typically represented as a pointer into a
symbol table. The pointer and the unboxed integer use the same amount
of space in most implementations.

```
```In summary, I think the rationale presents a view where the advantages
of the symbol data type are clearly underestimated if not misunderstood,
and where bad practices from other programming languages are favored
when we can do better.
```
```
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.

--
Jens Axel Søgaard

```