We may still do something useful with long-floats. That type is currently equivalent to double-float, but there's nothing that makes the situation necessary. IIRC, CLISP's long floats are arbitrary precision. I'm not completely sure what that means for standard compliance, but I'm also somewhat open to interpreting the standard loosely if the looseness only affects long float values.Stephan Frank wrote:
but wouldn't a library with bindings to MPFR (using CFFI) not make more
sense? Maxima (and I suppose matlisp as well) have to implement their
own bigfloats data type anyway whereas the GMP integration has the
chance of being tightly and transparently integrated with the underlying
bignum implementation of SBCL. I could only see an advantage when
tightly coupling it with CMUCL's quad-floats.
However, integrating MPFR for long floats is likely to be more work than plugging GMP in SBCL's bignums. We'd have to re-create a long-float type, likely fiddle with numeric bounds propagation, and (this final part is much more easy) define a concrete representation for long floats and tell the GC about.