[cl-json-devel] Encoding DOUBLE-FLOAT

[Boris Smilga]

On Fri, Jun 24, 2011 at 2:23 AM, Robert Goldman <rpgoldman at 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.