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" == 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