Steven D'Aprano steve at REMOVETHIS.cybersource.com.au
Sun Jun 14 15:25:20 CEST 2009

```John Yeung wrote:

> Paul LaFollette is probably thinking along the lines of formal logic
> or set theory.  It's a little bit confused because programming isn't
> quite the same as math, and so it's a common question when designing
> and implementing programming languages how far to take certain
> abstractions.  In some languages, nil, null, or none will try to
> behave as mathematically close to "nothing" (complete absence of
> anything) as possible, even though in reality they have to have some
> concrete implementation, such as perhaps being a singleton object.
> But mathematically speaking, it's intuitive that "nothing" would match
> any type.

I think you're wrong. Mathematically, you can't mix types like real numbers
and sets: while 1+0 = 1, you can't expect to get a sensible result from
1+{} or {1}∩0. (If that character between the set and zero ends up missing,
it's meant to be INTERSECTION u'\u2229'.)

Similarly, you can't add a scalar to a vector or matrix, even if one or the
other is null.

> I find that it's somewhat like the confusion that often occurs
> regarding the all() function.  Some people are surprised that all([])
> returns True, but it's the same logic behind the truth of the
> statement "every element of the empty set is an integer".  It's also
> true that every element of the empty set is a float.  Or an elephant.

So-called "vacuous truth". It's often useful to have all([]) return true,
but it's not *always* useful -- there are reasonable cases where the
opposite behaviour would be useful:

if all(the evidence points to the Defendant's guilt) then:
the Defendant is guilty
execute(the Defendant)

sadly means that if there is no evidence that a crime has been committed,
the person accused of committing the imaginary crime will be executed.

--
Steven

```