The protected arithmetic rules in Beads are mostly a copy of the proven-to-be-useful protected arithmetic of Excel. Instead of using #UNDEF and #ERROR, those 2 meta values, are abbreviated U and ERR in Beads.

``` 3 * ERR yields ERR 3 * U yields U (3 times undefined yields an undefined value) ```

The mathematical truth tables are in the appendix of the reference manual.

It is quite useful in a language to have a universal bottom value (undefined) and a universal top value (error). The key point is to avoid undefined behavior

Doesn't honestly seem that different from 'undefined' and 'NaN' in javascript and I think the fact that your 'NaN' is called 'ERR' is making people who think of errors as exceptions recoil.

(I'm not necessarily sure I like the trade-off you've chosen here, but I think the viscerally negative responses people are having are because of that, rather than thinking through the trade-off on its own merits)

In practice any JS programmer will find that the use of the undefined value is very familiar. In Beads it is abbreviated to U as it is used constantly, because the default value of something in the graph data structures is U.

For symmetry reasons, the error and undefined values work across all types, which cleans up one of the messes in JS, where you have undefined, NaN, null, and goodness knows what else. That we have a uniform error value for nodes is a very minor point; it is almost impossible to generate an error value in the protected arithmetic world of Beads. Square root of -1 is one of the only ways I can think of.

There is no try/except in Beads, there are no exceptions as all functions are total, and all arithmetic closed (like Excel).