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.
Upon further thought, it's not clear that specifying a NaN error-object is necessary or desirable; as in all cases it would appear preferable to signal a recoverable exception, upon which a default most-likely-useful value based on the context of the calculation is returned, or optional alternative action (potentially inclusive of a halting error) may be invoked if specified. Thereby alleviating any explicit need for a non-numerical error object itself. Where then default most-likely-useful numeral results may be specified if desired, or left implementation specific (whereby then an implementation may choose to explicitly represent a NaN error-object it so chooses, however not mandated to do so by the standard). Where then, an error-object may be independently specified as a proposed srfi independently, where by then such an object (such as <void> for the sake of argument), may be returned in lieu of an otherwise valid object as a result of any calculation, numeral or otherwise, as may be desired in lieu of a recoverable exception handler returning an otherwise more useful value. As just a thought.