On Fri, Jun 24, 2011 at 2:23 AM, Robert Goldman rpgoldman@sift.info wrote:
I was going to compare, e.g., MOST-POSITIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT and MOST-POSITIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT (at compile time) to attempt to determine if SHORT-FLOAT and SINGLE-FLOAT are the same on the current implementation and possibly conditionally-compile away the SINGLE-FLOAT type, and similarly for DOUBLE- and LONG-....
I would not be checking the numeric values of the number at run-time, but the bounds on the types at compile time. Would that not work?
Ah, yes, now I see. But then you might just write it straightforwardly as (subtypep 'short-float 'single-float), or vice versa. Since subtypes of float are either disjoint or synonymous, subtypep in this context effectively tests the types for equality.
Still, I doubt the intended effect is worth the trouble. Having superfluous clauses in typecase is explicitly allowed: ‘[...] is permissible for more than one clause to specify a matching type’ (CLHS 5.3, definition of TYPECASE et al.) In fact, by trying to get rid of them beforehand we would be (re)doing the compiler's job. E. g., CCL eliminates them right there at macro expansion time:
(macroexpand '(typecase foo (short-float #\S) (long-float #\L) (single-float #\F) (double-float #\D))) ⇒ (LET ((#:G4 FOO)) (DECLARE (IGNORABLE #:G4)) (COND ((TYPEP #:G4 'SHORT-FLOAT) NIL #\S) ((TYPEP #:G4 'LONG-FLOAT) NIL #\L)))
Are we going to such lengths just in order to get rid of annoying warnings in a single implementation?
Yours, - B. Sm.