> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports