3 ms·
I'm sure they know a lot more about language design than I do, but the use of what is essentially SQL's NULL for boolean false doesn't feel like a good idea at
by benji-york 4y ago
I'm sure they know a lot more about language design than I do, but the use of what is essentially SQL's NULL for boolean false doesn't feel like a good idea at first blush.
- qayxc 4y agoI didn't understand "false?" as a NULL value but more of a "Nothing"/"None" in the context of a Maybe monad. Since the language doesn't even have a Boolean equivalent, it makes sense to introduce a value for a failed condition or zero values. The problem with SQL's NULL are its properties (comparison and arithmetic in particular), which doesn't seem to apply here (e.g. "42 + false? === false?, just as with monadic function composition and Maybe monads).
- benji-york 4y agoI don't quite follow the second paragraph. You say > The problem with SQL's NULL are its properties (comparison and arithmetic in particular) [...] Which I follow, then you say that those unfortunate properties don't apply and give a counterexample (I think it is intended as a counterexample) of > 42 + false? === false? But that seems to be the same as SQL's NULL: benji=# \pset null NULL Null display is "NULL". benji=# select 1 + NULL; ?column? ---------- NULL (1 row) Which leaves me confused.
- qayxc 4y agoThe problem with SQL is that this behaviour is inconsistent when it comes to NULL values. Consider a column with values (10, 20, NULL, 30). In SQL the AVG() function would return 20, i.e. ignoring the NULL value entirely. COUNT(*) on a table, however, would happily include NULL values, whereas COUNT(col_name) wouldn't. The behaviour is all over the place, especially when different dialects and settings are considered.
- benji-york 4y agoThanks for taking the time to respond. I appreciate it.