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.
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: atehwa@xxxxxx, +35841 5323835, +3589 85619369 work contact: pkalliok@xxxxxxxxxxxxxxxx, +35850 3678003 kotisivu (henkkoht): http://www.iki.fi/atehwa/ homepage (technical): http://sange.fi/~atehwa/