[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Naming, compare function return values
>>>>> "Panu" == Panu Kalliokoski <atehwa@xxxxxxxx> 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