Isotopes and NaN (Not a Number)

[hostilefork]

@bradrn

Haven’t read the rest of the discussion, but these things (as well as the NaNs) shouldn’t be antiforms. They should be numbers — ordinary floating-point numbers, as defined by the relevant standards.

So you're saying Not-a-Number should be...a number? I thought you were all about logic and consistency in terminology.

red>> sqrt -1
== 1.#NaN

red>> number? sqrt -1
== true

@bradrn

Making them a different type will become an exercise in frustration, as floating-point numbers suddenly start turning into other types unexpectedly.

Well, I'm more intractably committed to the definitional error part than what the defused errors get turned into. But still feeling pretty confident about the worth of the antiform NaN...

• I like the clean notation.

• I like the falseyness.

• I like that you can't casually put NaN in blocks (but you have means to meta-represent them if you consciously need that...and it makes sense this handling would closely align to how ~null~ and ~void~ and ~ are dealt with).

• I like that functions which take floating point numbers wouldn't take these by default unless they said they did, e.g. arg [~NaN~ float!]

• I like that functions which don't specify return: [~NaN~ float!] can't return a NaN.

  • Currently we wouldn't be able to stop a function from returning the Signaling form of NaN. Because we do not limit the definitional errors that are legal for a function to return--any function can raise any error. But we should be enforcing contracts...and breaking the contract should trigger an abrupt "you broke the contract" failure. Maybe something like FENCE! in function specs could list the IDs of the errors that were legal? return: [float! {not-a-number}]

• I like that before you PRINT or WRITE or otherwise do anything to propagate these values, you get a little speedbump where you need to triage the antiform--because these are exceptional states that don't occur in 99% of correctly functioning Rebol programs.

• I like the idea that--as with historical Rebol--trying to LOAD a NaN float literal like 1.#NaN will give you an error, because 99% of the time that is likely representative of an unexpected condition upstream in your input vs. an intentional desire to give you a FLOAT!. It's another place where forcing triage is preferred. Once switched to a ~NaN~ quasiform it is no longer a FLOAT!, forcing conscious handling with UNMETA or DEGRADE.

Those attributes would not be accomplished with a floating point literal form and plowing along with other languages' status quo.

Anyway...we'll have to look at practical examples. I'm pretty sure my idea is a good path to take. Though as I say, I don't use Rebol for math (or really anything for math, the kinds of programs I tend to wind up working on don't need a whole lot of it).