UNSET! is not first class

It's important to understand the unset! datatype; otherwise, we run the risk of assuming that it is first class (assignable, passable, returnable) when it's really not intended for that kind of usage!

Unset comes into existence from the simple fact that a value slot in any context must be set to something -- it just can't contain random memory garbage.

The alternative to this method would be to mark the word slot as unset, but that's not a viable solution because we allow direct access to context value spaces with the get, set, values-of and other functions (e.g. in R3 with foreach.)

In addition, there's a benefit to unset! not being first class: it forces errors for appropriate conditions such as usage of uninitialized variables. We want that to happen.

With this in mind, it's not a good idea to allow unset! to pass innocently though most function interfaces. While we do provide a small number of very special exceptions such as get/any or defining it as an accepted type for a lit-word function argument (to make a mild level of console-based optional arguments possible, such as help.)

So, if you find I'm not enthusiastic about extending mezz functions to accept unset! values, you now know why. If you really think such a change is needed, you'll need to write a short explanation for why the exception is required. I'm pretty open minded, but just because we can do something does not mean we should do it.

4 Comments