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.)
(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) ...))
(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.
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.
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/
