This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 65: Precision indicators

2012-10-05 00:51:19
WG1 - Core
alexshinn
major
cowan
fixed
source
closed
2010-05-03 11:59:41
defect

R5RS requires that Scheme support five indicators for the precision of floating-point values, not only the default e but also s, f, d, and l. Only a few Schemes actually support more than one precision, so this is mostly noise. Shall we make it an optional feature?

The WG voted to make the precision indicators optional.

resolutionfixed
statusnewclosed
resolutionfixed
statusclosedreopened
owneralexshinn
statusreopenedassigned
statusassigneddecided
owneralexshinn
statusdecidedwriting

There's nothing in particular to change here - the standard already states:

Although Scheme allows a variety of written notations for numbers, any particular implementation may support only some of them.

I considered making the optionality more clear in the section on precision indicators, but it already uses "may" for everything. But it's a lot of text for something almost all implementations ignore - suggestions welcome.

The "may"s in 6.2.4 are not RFC 2119; they express what the user can do to achieve a certain result. Since the purpose of a standard is to define the agreement between users and implementers, the whole thing should be recast in terms of what implementations MUST, SHOULD, or MAY do. I just filed a ticket for RFC 2119 compliance.

Here's my suggestion:

In systems with inexact numbers of varying precisions it may be useful to specify the precision of a constant. For this purpose, implementations MAY accept numerical constants written with an exponent marker s, f, d, or l in place of e. The effect of these markers is implementation-defined.

resolutionfixed
statuswritingclosed