As is, the spec doesn't say what to do with complexes Jeronimo Pellegrini (14 Sep 2026 19:27 UTC)
Re: As is, the spec doesn't say what to do with complexes Peter McGoron (15 Sep 2026 05:43 UTC)

Re: As is, the spec doesn't say what to do with complexes Peter McGoron 15 Sep 2026 05:40 UTC

For round-away, ordered?, unordered?, and sign-negative?, the argument
in the procedure prototype is `x`. This SRFI uses the R7RS argument
convention, so if `x` is not a real number, it is "an error." A valid
implementation of this SRFI can do anything in response. This allows an
implementation flexibility to add extensions and to make those
extensions uniform.

The best thing to do, in my opinion, is to raise an exception. It is
allowable to return a value, but I don't know what the best value to
return for, say, rounding a complex number, or the sign of a complex
number. So these are left open for implementers to do whatever they want
with.

One reasonable extension to `round-away` would be to round each
component of a complex number to a gaussian integer (one would have to
fix how ties are broken, first by magnitude and then by the number
closest to a diagonal?). Another would be to raise errors on general
complex numbers, but round imaginary numbers like real numbers.

Similarly, ordered? and unordered? should raise exceptions when passed
complex numbers, because it is "an error" to pass a complex number to an
ordering procedure like <. However, if an implementation treats complex
numbers like NaNs for the purpose of the real comparison procedures
(i.e. (< 1+2i x) => #f for all numbers x), then ordered? and unordered?
should be extended to complex numbers, treating them like NaNs for the
purpose of the procedure. Another possible extension would be to answer
#t on ordered? and unordered?, and also offer lexicographic ordering for
non-NaN complex numbers.

I'm not sure what sign-negative? would return. However, one could return
#f for complex numbers with two non-negative components, #t for complex
numbers with two negative components, and the symbol "unknown"
otherwise. (This extends the domain to non-booleans, but this is also
allowed, as any extension is allowed).

For nonzero? and !=, these should work on complex numbers, but the
current spec is not written to support that. I will extend those to the
complex numbers in the next draft.

-- Peter McGoron