The idiom is usually use to implement comparable types is to provide lessp (and aequalis if need be), so I am not as familiar with using the compare operator. However, my concern is that making lessp and friends regular functions would not allow users to provide optimized versions of those functions as specialized methods. Is a good implementation of compare fast enough?
Matt
Though a less conservative addition than aequalis/compare, you could also provide:
Standard Generic Function COMPARE-OP Syntax: COMPARE-OP op a b &optional recursive-p &rest keys &key &allow-other-keys ⇒ generalized-boolean
Default methods specialized on (op (eql '<)), (op (eql '>)), and (op (eql '=)) could delegate to compare. Lessp, and friends could delegate to compare-op, and a no-applicable-method would indicate values are incomparable.
Matt
On 02/27/2011 12:19 PM, Matthew D. Swank wrote:
The idiom is usually use to implement comparable types is to provide lessp (and aequalis if need be), so I am not as familiar with using the compare operator. However, my concern is that making lessp and friends regular functions would not allow users to provide optimized versions of those functions as specialized methods. Is a good implementation of compare fast enough?
Matt
On 02/27/2011 03:29 PM, Matthew D. Swank wrote:
and a no-applicable-method would indicate values are incomparable.
Well, I suppose if the the default is to delegate to compare that would only happen if compare didn't default to returning '<> (or '/= ? I've seen both in doc). It would be better to say if you didn't want to specify an error type you could use the built-in CLOS machinery to indicate non-comparability.
-
Matthew D. Swank