This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
| Date: Mon, 24 Oct 2005 03:25:09 -0500 | From: Alan Watson <a.watson@xxxxxxxxxxxxxxxx> | | NaNs are atoms -- they have no context or stucture, just a single | value. In an implementation which boxes flonums, NaNs aren't a single value; EQ? and EQV? are *not* guaranteed to return #t given two NaNs. [Read-sytnax for singular objects is useful because it allows those objects to be put in CASE clauses. But this works only for objects which match under EQV?.] | With the understandable exception of the eof object (and as has | been noted, this is exception is not universal), Lisps and Schemes | tranditionally provide read syntax for atoms. Closures and continuations are atomic; R5RS provides no way to deconstruct them. Yet every implementation I have encountered has a write syntax without a corresponding read syntax for them. | So, tradition suggests that we should have a read syntax for NaNs. Are you suggesting a single NaN or multiple distinct NaNs? To support existing IEEE-754 hardware, R6RS must not mandate multiple distinct NaNs. But specifying a singular NaN prevents implementations from fully supporting IEEE-754 in the future. Thus R6RS should declare that NaNs are numerical error-objects [or condition-objects, whatever], and leave the rest to implementations. We worked through this issue in SRFI-70. I think SRFI-70's treatment is Schemely, compatible with IEEE-754, and doesn't unnecessarily constrain implementations: The notation 0/0 is used within this report to designate a numerical error-object. A numerical function may return such an object when no other number (including real infinities) is the correct value. An implementation may report a violation of an implementation restriction in any calculation for which the result would be 0/0.