Re: Naming, compare function return values

[Jens Axel Søgaard <jensaxel@xxxxxxxxxxxx>]

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