10 ms·

> I think NULL in SQL is very different from NULL in most PLs, and is much better behaved. It is on fact much closer to an Optional than to a 0 pointer. I beg

> I think NULL in SQL is very different from NULL in most PLs, and is much better behaved. It is on fact much closer to an Optional than to a 0 pointer. I beg to differ. Dereferencing NULL in C is generally well defined: SIGSEGV. Rust's unwrap() is a modest improvement on that, it reliably panics. Rust's main contribution it's type system forces you to acknowledge the possibly it might be null by making you to write unwrap(). I'd take that any day over what SQL does when you "dereference" a NULL, by say 1 < null. It just propagates the error so it poisons whatever expression contains it. I avoid nulls whenever possible to avoid that. If SQL was in fact closer to Rusts Option then an attempt to use a possibly null value/columns with an operator that can't handle null would produce a syntax error. So writing could_be_null > 0 would be illegal, you would have to write ifnull(could_be_null, 0) > 0.

rkangel 6y ago
Dereferencing Null in C when running on a hosted OS is fairly predictable. Don't forget that a lot of C (and increasingly a lot of Rust) is written for embedded targets where that is usually not true (sometimes address 0 is the start of flash). The only things you can rely on are what the C Spec says you can rely on, and that does not include the behaviour of address 0.
pjmlp 6y ago
That looks like a failure to use NVL and similar operators to me.
tsimionescu 6y ago
Dereferencing NULL in C is undefined behavior - it has no semantics in the C abstract machine. In practice, with a modern optimizing compiler, it can have very surprising behavior, including omitting further null checks after the dereference. While it's true that an explicit dereference is very likely to cause a SIGSEGV (these are Unix semantics, not C), dereferncing NULL + something is likely to lead to memory corruption (very ugly in v[length - 1] or v->field for v==NULL). Also, the recommended way of working with Maybe/Optional values is map() or do-notation, not unwrapping. And map/do have exactly the same semantics as most NULL-based operations in SQL.

rkangel 6y ago

Dereferencing Null in C when running on a hosted OS is fairly predictable. Don't forget that a lot of C (and increasingly a lot of Rust) is written for embedded targets where that is usually not true (sometimes address 0 is the start of flash). The only things you can rely on are what the C Spec says you can rely on, and that does not include the behaviour of address 0.

pjmlp 6y ago

That looks like a failure to use NVL and similar operators to me.

tsimionescu 6y ago

Dereferencing NULL in C is undefined behavior - it has no semantics in the C abstract machine. In practice, with a modern optimizing compiler, it can have very surprising behavior, including omitting further null checks after the dereference. While it's true that an explicit dereference is very likely to cause a SIGSEGV (these are Unix semantics, not C), dereferncing NULL + something is likely to lead to memory corruption (very ugly in v[length - 1] or v->field for v==NULL). Also, the recommended way of working with Maybe/Optional values is map() or do-notation, not unwrapping. And map/do have exactly the same semantics as most NULL-based operations in SQL.