Ovid

So far the initial response to my three-value logic in Perl post has been great. Due to that response, on Reddit, Perlmonks, here and my RT queue has led to:

• Made sorting a bit more useful
• Contemplating removing stringification
• Plenty of strengthening of the documentation (including making it explicitly clear that the unknown logic is akin to SQL's NULL)

And then there's been some interesting rebuttals.

This is the snippet that I used to show that undef is broken while unknown offers a semantically correct guarantee:

foreach my $employee (@employees) {
    if ( $employee->salary < $threshold ) {
        increase_salary( $employee, 3_000 );
    }
}

One person seemed to think my example was wrong and offered what they referred to as a "sane" version:

foreach my $employee (@employees) {
    if ($employee->is_salaried) {
        if ($employee->salary and $employee->salary < $threshold) {
            increase_salary($employee,3000);
        }
    }
}

See the problem there? The is_salaried predicate determines if the person has a salary and the $employee->salary test determines if they have a salary set. This again shows the fragility of definedness because the dev forgot to check for it in the second if statement. It seems like it would be OK, but when you think about it, it's obvious that an undefined salary would be wrong, but what about a zero salary? That's less clear and thus, the above code is ambiguous (the problem is more stark if you're talking about prices and you're wondering about the difference between an item without a price and an item which is obviously free).

Another person posted this as a counter-example to my code:

if ( $salary < $threshold ) {
    increase_salary( $employee, 3_000);
}
else {
    decrease_salary( $employee, 3_000);
}

If $salary is undef, we take the first branch, but if it's unknown, we take the second branch. Ah ha! Gotcha! That's a bug!

Except that there's a very huge difference between the two. If you have an undef value, you probably call something like this:

$employee->salary( $employee->salary + $difference );

What happens if the salary is undefined? When you try to manipulate an undefined value, it coerces into a zero, an empty string or a false value. For the example above, we would be adding $difference to zero and probably corrupting our data. In fact, if this was the code:

$salary += $difference;

You wouldn't even get a warning about the potential data corruption and that's documented behavior! Surprise!

What happens if salary is unknown? You'd probably be ultimately calling something like this:

$employee->salary( $employee->salary + $difference );

Except, as documented, that will confess(). You get a useful error message and a stack trace. This is because unknown values, unlike undef values, are specifically designed for comparison, not manipulation. If you forget to check if a value is unknown, it will confess() rather than allowing you to corrupt the data.

The only argument I heard which has some merit was: what if you take a bad branch? With an unknown value, you might silently take a different branch in your code and that branch may do something undesirable that doesn't impact the unknown value. I have to admit that this is a problem, but I counter that this is a problem even if you use undef values. The difference is that with an undef value, you can enable fatal warnings. Perhaps I should look at doing that for unknown? I'm unsure.

One thing I did that I may regret is that I overloaded stringification to print [unknown]. I now think that may be a mistake (imagine embedding it in JSON). I think I should remove that and only allow boolean comparisons.

Three-value logic, like any logic, is not perfect, but I do think it maps better to the real world and solves more problems than it causes, but a few replies of various forums is hardly a compelling case. So far this has been an interesting experiment.

Go to your favorite projects and see about replacing undef with unknown and see what happens. It might be interesting. As always, you can download the latest version on github.

It's also been pointed out that salary() should always be defined and that increase_salary() should also check for sanity. The latter is definitely correct, but unknown offers a useful fallback if devs forget. The former (salary is always defined) is desirable, but we can't always guarantee that we have this information because maybe:

• It's not applicable (volunteers don't have salaries)
• It's not known (new employee whose salary is not yet implemented)
• It's not available (the 'salary service' is down)
• It's restricted (you don't have permissions)
• It was fetched via an outer join (ooh! A common source of undef values!)
• Something else I haven't thought of

Do you really want to kill that six hour batch job after five hours because you're missing one salary? The smaller the system the easier it is to handle cases like that, but as you deal with extremely large-scale systems, it's often better to make them more intelligently handle the cases where you're missing data. That way, your code doesn't die and you can come back later and correct the missing data (if that's appropriate). Don't automatically assume that your "data must always be defined" belief is correct. Using words like "all" or "never" tends to be a code smell in reasoning.