Bayle Shanks's website: proj-oot-old-150618-ootErrorThoughts

types of nils

i generally have the idea that instead of just having one 'nil' value, like Python's None, we'll have many, to disambiguate.

sentinel which is assigned to defaultable arguments which are not overridden, meaning 'use the default value for this argument if there is one'; can be explictly passed to eg allow a chain of functions that call each other with default values where the actual default value is only specified in the innermost function
what else? see below:

" The problem is that the null reference has been overloaded to mean at least seven different things:

    a semantic non-value, such as a property that is applicable to some objects but not others;
    a missing value, such as the result of looking up a key that is not present in a key-value store, or the input used to request deletion of a key;
    a sentinel representing the end of a sequence of values;
    a placeholder for an object that has yet to be initialized or has already been destroyed, and therefore cannot be used at this time;
    a shortcut for requesting some default or previous value;
    an invalid result indicating some exceptional or error condition;
    or, most commonly, just a special case to be tested for and rejected, or to be ignored and passed on where it will cause unpredictable problems somewhere else.

Since the null reference is a legitimate value of every object type as far as the language is concerned, the compiler has no way to distinguish between these different uses. The programmer is left with the responsibility to keep them straight, and it’s all too easy to occasionally slip up or forget. " -- Anders Kaseorg, http://qr.ae/CS2A6

i would also consider breaking the following into two: "a semantic non-value, such as a property that is applicable to some objects but not others;"; in true/false/nonsense, 'nonsense' is sort of a 'non-value', but this could sometimes be different from a property that is sometimes inapplicable?

also, true/false/maybe might be distinguished from true/false/don't know (eg dont know means i refuse to take any position, maybe means both are reasonable guesses), and true/false/nonsense, and true/false/neither (implying there is some other truth value besides true or false which is applicable here, eg in logics that admit other qualitatively different ones)

to deal with distributed systems:

maybe have two basic error conditions, for three result conditions in total:

(1) success (2) clean failure (3) success or failure unknown; also, partial success possible (4) corruption detected (eg ecc fail error)

so, if a side-effectful RPC was sent but there was a network failure that prevents us from knowing if the RPC request was received or not, (3) would be returned.

also, keep in mind:

http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-errors/ http://blog.ezyang.com/2011/08/8-ways-to-report-errors-in-haskell-revisited/ http://book.realworldhaskell.org/read/error-handling.html

am i making 'nil' into some sort of alternate Exception type? If so, maybe we should just merge it with proper Exceptions. And remember, i still want to have apostrophes converting between Maybe/Option types, Exceptions, nullable types, etc.

Syntax encouraging extensible exception handling

When someone is testing to see if an exception is of a certain type, the syntax should encourage them to do a test that later allows other types of exceptions to register as 'true' in that test via something like subclasses (or rather, implmenting an interface). I'm thinking of just using the word 'is', eg:

"if exc is NotImplementedException?"