>>>>> "Panu" == Panu Kalliokoski <xxxxxx@sange.fi> writes:

Panu> Sorry, I had somehow missed this.  But I disagree heavily with the
Panu> rationale represented there.  Basically, there are three arguments
Panu> presented there: [...]

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

I personally agree with their Jens's and Sebastian's choice.  (Even
though I agree their rationale doesn't hit all the sweet spots.)  I
think the benefits far outweight the costs.  I frequently want to use
the result of a comparison to influence the sign of something else,
which means I can just multiply by the output of SRFI 67's procedures.
This is also a mathematical convention that's in common use, and it's
just plain intuitive, at least for me.

More specifically, I believe that symbols would be an especially poor
replacement.  (I also don't believe that symbols are anywhere near the
top of my list of good things about Lisp/Scheme.)  Symbols get you all
the disadvantages of -1,0,1 that I can see (most importantly, no
distinct type for comparison outcomes) with none of the benefits.

An alternative would be to use a true disjoint type.  (For situations
like this, Scheme 48 offers a DEFINE-FINITE-TYPE form.)  But in this
specific context, I vote for -1,0,1.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla