Re: pi seems not to be a constant

On 18/10/15 18:13, Don Cohen wrote:
> I should have remembered about pi being recomputed.
>
>    > Conformity could be restored by having CL:PI defined as a constant
>    > variable bound to double-float, and to have another variable EXT:PI
>    > bound to the changing long-float value.
>
>    Would still be not conforming.
>
> Although the suggestion above would not be strictly conforming, I
> think it would be an improvement in that (let (pi)) would signal an
> error and constantp would return the expected result.

It seems to me that (typep cl:pi 'long-float)
is more important to maintain than (constantp 'cl:pi).

Either case would introduce a small non-conformity of clisp.

The only way we could restore conformity would be to keep long-float 
fixed size (and therefore the value of cl:pi identical), and to rename 
extended long floats  ext:variable-precision-long-float (or something 
else) and have that distinct ext:pi variable.

(subtypep 'ext:variable-precision-long-float 'float)

AFAIK, introducing a new floating point subtype would be an acceptable 
extension that wouldn't introduce any obvious non-conformity.  But I 
would note that already programs can have difficulties dealing 
conformingly with the existing subtypes of float, eg. in a typedef:

    (declare (type float v))
    (typedef v
      (short-float 1)
      (single-float 2)
      (double-float 3)
      (long-float 4))

This form compiles with duplicate types warnings on implementations that 
coalesce some float subtypes.
It would also miss the case where v would be of a fifth float subtype. 
Using etypedef is not the point.
Granted, one could argue that a conforming program probably should not 
expect to have only at most 4 subtypes of float.  In practice, it means 
that IMO more code would break if we introduced a fifth float subtype.
(That said, if a maintained wanted to do that, it would be trivial 
enough to scan all the quicklisp libraries and a few major applications 
(eg. maxima), to check if it'd really be a problem).

So, we have to consider the complexity involved in introducing this 
fifth floating point type.  After all, most applications (and conforming 
code definitely) never set ext:long-float-digits, so for conforming 
applications, cl:pi never changes.

Furthermore, while clhs constantp seems to imply a specified list of 
constant values including cl:pi, I would argue that constantp can be 
considered more like an introspection operator telling the truth (as 
known by the implementation) rather than telling what's specified. The 
point here is that a conforming library would work correctly when 
processing an expression containing cl:pi with constantp returning NIL 
(and therefore, not "inlining" cl:pi, in the case of clisp, if some 
other code non-conforming changes the long-float-digits.  But it would 
break if constantp lied and returned T.


Therefore in my opinion, it's better to have constantp return nil for a 
non-constant cl:pi, since while it's nominaly non-conforming, allows 
more conforming programs to continue working correctly, and since it's 
much less complex than adding a fifth float subtype.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com/


------------------------------------------------------------------------------
_______________________________________________
clisp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-list