-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/16/2011 11:41 AM, Peter Bex wrote:
> On Tue, Aug 16, 2011 at 12:55:29PM -0400, John Cowan wrote:

>> When the system of formats was removed from R4RS and the second
>> argument changed to a radix, the # numeric syntax was retained,
>> presumably so that old data files could still be read.

> Why not allows implementations to choose whether they want to be
> backwards compatible in this way?  If # is not specified in the
> standard it can still be supported by individual implementations,
> right?

Agreed, generally.

> By the way, I also noticed there's supposed to be support for exponent
> markers of various kinds: e, s, f, d and l (and their uppercase forms).
> The standard mentions something about short, single, double and long
> precision, but are there any Schemes that actually differentiate between
> these kinds of flonums?  How do these forms interact with the #e prefix?

In a very unfortunate way.  Short, Single, Double, and Long represent
different standards of precision, or suitable representation for
different types of inexact numbers.  It is not meaningful for them to
be separated, as the exponent-marker placement does, from the
exact/inexact distinction.

Also, the R5RS standard requires the result of operations on inexact
numbers to default to the "highest precision available" on the machine,
thus any operation on, eg, Short floats that fails to result in a Long
float is technically in violation of the standard. This makes all
precisions other than the "Long" effectively useless in that they can
save nothing other than a few bytes of code space in conformant
implementations.

> If there are no Schemes that differentiate, that's another bit of
> historical cruft that could be scheduled to be deleted.

I'm in agreement that these radix markers could be deleted from
the standard.  They are after all, widely non-supported.

But more importantly, If a distinction between float precision types is
to be permitted by the standard, then the verbiage about returning
results of the "highest precision available" ought to be replaced with
verbiage specifying that inexact results must have at least the same
precision as the least-precise argument to the operation that produces
them.

				Bear

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOS/BXAAoJEAOzWkqOibfNqh4H/i7y0pY2lvgpLf5/bRS7Ukfn
yZ4pz2/OeqoA3KokaoW3ShyKRIbyVykBmyEID0BcCfgjmqZpRt7z1OxC2gCwbNUC
s5w5xSoSZqa1DIP0IZvhN/tIkUTUEC5r8X15G+CRt/o9PyJlVUBt9lx8kQENtmu0
21zH/ArYN8pMEbaqfVQ9Zd4y6sZq/8WTR1Jz9FxWLLLqALjJLDql/sNFeO/KCuIx
eOlh39HiM/j2igUnbJvRb++bDqG5KC13Z7qaN+eN2aSJ6WTtke7NwQB5m9iUVgAz
7+OoWKEwBQDG3k/GtEW5HEsvuwq8tGfslfARsIkDLP4CWOVConxcoiz+fC6vFak=
=2o7L
-----END PGP SIGNATURE-----

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports