Numbers with mantissa width are not read properly

In reverse order:

On Jul 30, 2009, at 7:28 PM, Göran Weinholt wrote:

> Public bug reported:
>
> Here's another "interesting" side-effect of all this:
>> #!r6rs (+ 1 1.1|53)
>
>>
>

This was actually due to not raising the proper &lexical condition
which I fixed in revision 1834. So, you now get the more informative
error:

 > #!r6rs (+ 1 1.1|53)
Unhandled exception
  Condition components:
    1. &lexical
    2. &message: "|symbol| syntax is invalid in #!r6rs mode"
    3. &source-position:
        file-name: *stdin*
        character: 17
 > ^D

> The reader also seems to treat `|' like a delimiter:
>> 1.1|53
> 1.1
>> |
> Unhandled exception
> Condition components:
> 1. &undefined
> 2. &who: eval
> 3. &message: "unbound variable"
> 4. &irritants: (\x35;3\xA;)

Yes, I've turned it into a delimiter 3 revisions ago in order to
let the scribble reader be able to read @{@|bar|.} without error.
I don't think it's a big violation of R6RS to treat | as delimiter
and this is regardless of the number syntax (e.g., it will not be
treated as a delimiter inside numbers just like it's not one inside
strings).

And now the real issue:

> Numbers of the form x|p aren't handled by string->number:
> Ikarus Scheme version 0.0.4-rc1+, 64-bit (revision 1833, build
> 2009-07-30)
> Copyright (c) 2006-2009 Abdulaziz Ghuloum
>
>> (string->number "1.1|53")
> #f
>>

This is correct. The short answer is: I don't know what to do with
the mantissa width, so, I can either go the route of the other
implementations (i.e., read it and ignore it) which does not sound
like the right thing to do, or, since no one does it correctly, be
the scapegoat and not support it at all. Don't know what's the
best action for this.

Aziz,,,

The robustness principle: be conservative in what you do; be liberal in what you accept from others.

If it was up to me I'd handle the mantissa width without error, even if the width is ignored. It might not make any difference in how the number is read, but it's part of R6RS's lexical syntax so authors of portable programs would expect it to work. The mantissa width might also be part of an R6RS implementation's put-datum output:

"Note: When the underlying floating-point representation is
IEEE double precision, the |p suffix should not always be omit-
ted: Denormalized floating-point numbers have diminished pre-
cision, and therefore their external representations should carry
a |p suffix with the actual width of the significand."

I'm not sure what you mean by "no one does it correctly". Have the vertical bar make the number inexact and ignore the mantissa width. This is allowed by R6RS:

"Implementations that use binary floating-point representa-
tions of real number objects should represent x|p using a
p-bit significand if practical, or by a greater precision if a
p-bit significand is not practical, or by the largest available
precision if p or more bits of significand are not practical
within the implementation."

Fixed in 1838. Thanks.

And now I am the only scapegoat left. I think I better follow the hurd :-)

On Aug 2, 2009, at 2:59 PM, leppie wrote:

> And now I am the only scapegoat left. I think I better follow the hurd
> :-)

I know! It's like the most useless piece of syntax that everyone
has to support (by processing and ignoring it).

Aziz,,,

Hmm, I suppose you wouldn't ignore it if you were to implement immediate flonums? On a 64-bit machine you can fit a single precision real inside an immediate (though I have no idea how useful that is). Then there would be a difference between 1.1|24 and 1.1|53 (but you could always argue that the s/f/d/l exponent markers will suffice).
At least it's useful if you want to have arbitrary precision reals like GNU bc. :)

Found something you missed :)

> #e0.0e-0
0

> #e.0|0
0

> #e0.|0
Unhandled exception
 Condition components:
   1. &undefined
   2. &who: eval
   3. &message: "unbound variable"
   4. &irritants: (\x30;\xA;\x23;e0.)

> 0.
0.0

> #e0.
0

> 0.|0
0.0
>