On Thu, 25 Mar 2004, soo wrote:

>R5RS says: If the written representation of a number has no exactness prefix,
>the constant may be either inexact or exact.  It is inexact if it contains a
>decimal point, an exponent, or a "#" character in the place of a digit,
>otherwise it is exact.

This is true, but a number such as #e1.234 is still an exact number.
It could also have been written 1234/10000.

In general, if you rely on implementations to do the "Right thing" with
exact vs. inexact numbers, you will be disappointed or wind up with
a nonportable library.  Some of them throw syntax errors on exactness
prefixes, some ignore exactness prefixes, some disallow decimal points
in exact numbers, some silently coerce to inexact even after reading an
exactness prefix if they encounter a decimal, etc.  The behavior described
in R5RS is fully implemented, alas, only by a very few.

> > (fmt 1/2 5 0)
> | "   1."            ; Huh?
>
> > (fmt -1 10 0)
> | "       -1."       ; Is this on purpose?
>
>Yes, it expresses that -1. is inexact number.

The problem here is that in both cases you should have an exact number.
You were given exact parameters, you had no need for inexact computations.
Why aren't the results exact?  What display ought to give you here would
be simply "1" and "-1".

>(fmt 1/2 5 2 #\space (fmt 10))           " 0.5010"
>(fmt 1/2 5 2)                            " 0.50"
>The default value of padding character is #\space.

In these cases people have given you exact numbers and asked for
decimal format.  The correct responses would be exact prefixes
followed by a decimal fractions, but I don't think the write procedure
of any known scheme will produce them. I'd need to pass my own write
procedure into FMT in order to get them, and FMT as specified doesn't
allow it.

				Bear