parent
8368283a3e
commit
6f0667bb28
@ -0,0 +1,220 @@ |
||||
--- |
||||
title: "How Many Values Does a Boolean Have?" |
||||
date: 2020-08-20T18:37:50-07:00 |
||||
draft: ["Java", "Haskell"] |
||||
--- |
||||
|
||||
A friend of mine recently had an interview for a software |
||||
engineering position. They later recounted to me the content |
||||
of the techical questions that they had been asked. Some had |
||||
been pretty standard: |
||||
|
||||
* __"What's the difference between concurrency |
||||
and parallelism?"__ -- a reasonable question given that Go was |
||||
the company's language of choice. |
||||
* __"What's the difference between a method and a function?"__ -- |
||||
a little more strange, in my opinion, since the difference |
||||
is of little _practical_ use. |
||||
|
||||
But then, they recounted a rather interesting question: |
||||
|
||||
> How many values does a bool have? |
||||
|
||||
Innocous at first, isn't it? Probably a bit simpler, in fact, |
||||
than the questions about methods and functions, concurrency |
||||
and parallelism. It's plausible that a programmer |
||||
has not done much concurrent or parallel programming in their |
||||
life, or that they came from a language in which functions |
||||
were rare and methods were ubiquitous. It's not plausible, |
||||
on the other hand, that a candidate applying to a software |
||||
engineering position has not encountered booleans. |
||||
|
||||
If you're genuinely unsure about the answer to the question, |
||||
I think there's no reason for me to mess with you. The |
||||
simple answer to the question -- as far as I know -- is that a boolean |
||||
has two values. They are `true` and `false` in Java, or `True` and `False` |
||||
in Haskell, and `1` and `0` in C. A boolean value is either true or false. |
||||
|
||||
So, what's there to think about? There are a few things, _ackshually_. |
||||
Let's explore them, starting from the theoretical perspective. |
||||
|
||||
### What's a Type, Anyway? |
||||
Boolean, or `bool`, is a type. Broadly speaking, a type |
||||
is a property of _something_ that defines what the _something_ |
||||
means and what you can do with it. That _something_ can be |
||||
several things; for our purposes, it can either be an |
||||
_expression_ in a programming language (in the form of `fact(n)`) |
||||
or a value in that same programming langauge (like `5`). |
||||
|
||||
Dealing with values is rather simple. Most languages have finite numbers, |
||||
usually with \\(2^{32}\\) values, which have type `int`, |
||||
`i32`, or something in a similar vein. Most languages also have |
||||
strings, of which there are as many as you have memory to contain, |
||||
and which have the type `string`, `String`, or occasianlly |
||||
the more confusing `char*`. Most languages also have booleans, |
||||
as we discussed above. |
||||
|
||||
The deal with expressions is a more interesting. Presumably |
||||
expressions evaluate to values, and the type of an expression |
||||
is then the type of values it can yield. Consider the following |
||||
snippet in C++: |
||||
|
||||
```C |
||||
int square(int x) { |
||||
return x * x; |
||||
} |
||||
``` |
||||
|
||||
Here, the expression `x` is known to have type `int` from |
||||
the type signature provided by the user. Multiplication |
||||
of integers yields an integer, and so the type of `x*x` is also |
||||
of type `int`. Since `square(x)` returns `x*x`, it is also |
||||
of type `int`. So far, so good. |
||||
|
||||
Okay, how about this: |
||||
|
||||
```C++ |
||||
int meaningOfLife() { |
||||
return meaningOfLife(); |
||||
} |
||||
``` |
||||
|
||||
No, wait, doesn't say "stack overflow" just yet. That's no fun. |
||||
And anyway, this is technically a tail call, so maybe our |
||||
C++ compiler can avoid growing the stack And indeed, |
||||
flicking on the `-O2` flag in this [compiler explorer example](https://godbolt.org/z/9cv4nY), |
||||
we can see that no stack growth is necessary: it's just |
||||
an infinite loop. But `meaningOfLife` will never return a value. One could say |
||||
this computation _diverges_. |
||||
|
||||
Well, if it diverges, just throw the expression out of the window! That's |
||||
no `int`! We only want _real_ `int`s! |
||||
|
||||
And here, we can do that. But what about the following: |
||||
|
||||
```C++ |
||||
inf_int collatz(inf_int x) { |
||||
if(x == 1) return 1; |
||||
if(x % 2 == 0) return collatz(x/2); |
||||
return collatz(x * 3 + 1); |
||||
} |
||||
``` |
||||
|
||||
Notice that I've used the fictitious type |
||||
`inf_int` to represent integers that can hold |
||||
arbitrarily large integer values, not just the 32-bit ones. |
||||
That is important for this example, and I'll explain why shortly. |
||||
|
||||
The code in the example is a simulation of the process described |
||||
in the [Collatz conjecture](https://en.wikipedia.org/wiki/Collatz_conjecture). |
||||
Given an input number `x`, if the number is even, it's divided in half, |
||||
and the process continues with the halved number. If, on the other |
||||
hand, the number is odd, it's multiplied by 3, 1 is added to it, |
||||
and the process continues with _that_ number. The only way for the |
||||
process to terminate is for the computation to reach the value 1. |
||||
|
||||
Why does this matter? Because as of right now, __nobody knows__ |
||||
whether or not the process terminates for all possible input numbers. |
||||
We have a strong hunch that it does; we've checked a __lot__ |
||||
of numbers and found that the process terminates for them. |
||||
This is why 32-bit integers are not truly sufficient for this example; |
||||
we know empirically that the function will terminate for them. |
||||
|
||||
But why does _this_ matter? Well, it matters because we don't know |
||||
whether or not this function will diverge, and thus, we can't |
||||
'throw it out of the window' like we wanted to with `meaningOfLife`! |
||||
In general, it's _impossible to tell_ whether or not a program will |
||||
terminate; that is the [halting prorblem](https://en.wikipedia.org/wiki/Halting_problem). |
||||
So, what do we do? |
||||
|
||||
It turns out to be convenient -- formally -- to treat the result of a diverging computation |
||||
as its own value. This value is usually called 'bottom', and written as \\(\\bot\\). |
||||
Since in most programming languages, you can write a nonterminating expression or |
||||
function of any type, this 'bottom' is included in _all_ types. So in fact, the |
||||
set of possible values for `unsigned int`: \\(\\bot, 0, 1, 2, ...\\) and so on. |
||||
As you may have by now guessed, the same is true for a boolean: we have \\(\\bot\\), `true`, and `false`. |
||||
|
||||
### Haskell and Bottom |
||||
You may be thinking: |
||||
|
||||
> Now he's done it; he's gone off the deep end with all that programming language |
||||
theory. Tell me, Daniel, where the heck have you ever encountered \\(\\bot\\) in |
||||
code? This question was for a software engineering interview, after all! |
||||
|
||||
You're right; I haven't _specifically_ seen the symbol \\(\\bot\\) in my time |
||||
programming. But I have frequently used an equivalent notation for the same idea: |
||||
`undefined`. In fact, here's a possible definition of `undefined` in Haskell: |
||||
|
||||
``` |
||||
undefined = undefined |
||||
``` |
||||
|
||||
Just like `meaningOfLife`, this is a divergent computation! What's more is that |
||||
the type of this computation is, in Haskell, `a`. More explicitly -- and retreating |
||||
to more mathematical notation -- we can write this type as: \\(\\forall \\alpha . \\alpha\\). |
||||
That is, for any type \\(\\alpha\\), `undefined` has that type! This means |
||||
`undefined` can take on _any_ type, and so, we can write: |
||||
|
||||
```Haskell |
||||
myTrue :: Bool |
||||
myTrue = True |
||||
|
||||
myFalse :: Bool |
||||
myFalse = False |
||||
|
||||
myBool :: Bool |
||||
myBool = undefined |
||||
``` |
||||
|
||||
In Haskell, this is quite useful. For instance, if one's in the middle |
||||
of writing a complicated function, and wants to check their work so far, |
||||
they can put 'undefined' for the part of the function they haven't written. |
||||
They can then compile their program; the typechecker will find any mistakes |
||||
they've made so far, but, since the type of `undefined` can be _anything_, |
||||
that part of the program will be accepted without second thought. |
||||
|
||||
The language `Idris` extends this practice with the idea of typed holes, |
||||
where you can leave fragments of your program unwritten, and ask the |
||||
compiler what kind of _thing_ you need to write to fill that hole. |
||||
|
||||
### Java and `null` |
||||
Now you may be thinking: |
||||
|
||||
> This whole deal with Haskell's `undefined` is beside the point; it doesn't |
||||
really count as a value, since it's just a nonterminating |
||||
expression. What you're doing is a kind of academic autofellatio. |
||||
|
||||
Alright, I can accept this criticism. Perhaps just calling a nonterminating |
||||
function a value _is_ far-fetched (even though denotational semantics |
||||
_do_ extend types with \\(\\bot\\)). But denotational semantics is not |
||||
the only place where types are implcitily extend with an extra value; |
||||
let's look at Java. |
||||
|
||||
In Java, we have `null`. At the |
||||
core language level, any function or method that accepts a class can also take `null`; |
||||
if `null` is not to that function or method's liking, it has to |
||||
explicitly check for it using `if(x == null)`. |
||||
|
||||
Java's booleans are not, at first glance, classes. Unlike classes, which you have |
||||
to allocate using `new`, you can just throw around `true` and `false` as you see |
||||
fit. Also unlike classes, you can't assign `null` to a boolean value. |
||||
The trouble is, the _generics_ part of Java, which allows you to write |
||||
polymorphic functions, can't handle 'primitives' like `bool`. If you want to have an `ArrayList` |
||||
of something, that something _must_ be a class. |
||||
|
||||
But what if you really _do_ want an `ArrayList` of booleans? Java solves this problem by introducing |
||||
'boxed' booleans: they're primitives wrapped in a class, called `Boolean`. This class |
||||
can then be used for generics. |
||||
|
||||
But see, this is where `null` has snuck in again. By allowing `Boolean` to be a class |
||||
(thereby granting it access to generics), we've also given it the ability to be null. |
||||
This example is made especially compelling because Java supports something |
||||
they call [autoboxing](https://docs.oracle.com/javase/tutorial/java/data/autoboxing.html): |
||||
you can directly assign a primitive to a variable of the corresponding boxed type. |
||||
Consider the example: |
||||
|
||||
```Java |
||||
Boolean myTrue = true; |
||||
Boolean myFalse = false; |
||||
Boolean myBool = null; |
||||
``` |
Loading…
Reference in new issue