Re: GBBOpen

David McClain wrote:
> Hi Gary, and all...
> 
> GBBopen looks very interesting. I'll check it out.
> 
> And I did discover that the input forms n.nnF+-nn and n.nnD+-nn seem to
> parse as these infinities and NaN's. And indeed they could be tested by
> EQL as in MEMBER. This is interesting, but possibly non-portable?

Definitely not portable.  A few years ago, I proposed that the LW reader
syntax be adopted more widely (even providing reader/printer extension
patches for SBCL, CMUCL, and OpenMCL).  There was a strongly mixed
response to this, with some very strongly negative opinions--but
unfortunately no widely agreeable alternative approach was suggested for
addressing the issue of allowing infinite values to be portably
exchanged among CL implementations that support IEEE 754.  (We backed
off the native reader/printer extension approach with GBBopen and now
use a macro-dispatch representation instead (#@single-float-infinity,
#@double-float-negative-infinity, etc.)

For the record, I found the LW representations readable and intuitive.
Here is a brief excerpt from some of the objections/discussion:

>> 1e++0 and -1e++0 seem like really bad representations for +-inf, as
>> they are completely meaningless to most anyone who might see one.

The 1e++0 representation has the advantage of being compact, adding
little overhead to the reader, and unlikely to collide
with anyone's symbol names.  I was thinking along the lines of 1e+inf
and -1e+inf until I learned of the Lispworks
scheme.  Since my goal is to facilitate portable exchange of infinity
values, I went with the Lispworks scheme in my
proposed patches rather than introducing another one.

>> That 1e+-0 is the representation for NaN doesn't make things any
>> better. And what's with only outputting the trapping-ness of the NaN
 >> in a comment? That's kinda weird. Following the examples of the
>> above, surely a trapping NaN should be -1e+-0. Ugh. Of course,
>> outputting a comment after every NaN does help with the "what the
>> hell is this" problem.

Lispworks doesn't distinguish trapping/non-trapping NaNs, so again I
stayed compatible.  I think that 1e--0 is more noticable than 1e+-0 (and
is still read in as NAN), but again I didn't change from what Lispworks
uses.  Using -e+-0 for trapping NaN is read compatible with Lispworks,
but Lispworks would treat it as equivalent to e+-0.

My goal is to have a *some* solution that is better (and less dangerous)
than incompatible #.(form) print-readable representations.