> Please read the justification at
> <http://srfi.schemers.org/srfi-67/srfi-67.html#node_sec_Temp_15>.

Thanks for the link. I'm pleased to see that those SRFI authors gave
careful thought to this issue, and Alexey brought up some good practical
considerations. However that page actually strengthened my feeling that
comparators should return an enum.

I think one of Scheme's strongest points is that it consistently does
the right, coherent thing, even when that incurs some runtime overhead.
For example, supporting the full numeric tower with polymorphic
arithmetic operators has a cost, but it's the right thing to if the
"integer" type really does represent integers, and it prevents an entire
class of tricky overflow bugs. Scheme wisely evolved beyond the C idiom
of making int's synonymous with Boooleans, which also prevents a class
of subtle bugs at some small runtime cost. And R7RS sidestepped the C
idiom of representing EOF with the integer -1, instead using eof-object,
which again is cleaner yet a tiny bit heavier.

The -1, 0, 1 convention feels to me like another C idiom that, while
expedient, is not the cleanest way of representing the result of a
comparison. The by-the-book representation for such a finite set of
non-numeric elements is an enum, so we ought to use an enum.

With all that said, the proposed comparison syntax and high-level
procedures seem to do a good job of encapsulating these result values.
So the practical impact of this decision may be minor.

Kevin Wortman

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports