Update boolean values article to new math delimiters
Signed-off-by: Danila Fedorin <danila.fedorin@gmail.com>
This commit is contained in:
		
							parent
							
								
									ffda1d3235
								
							
						
					
					
						commit
						e543904995
					
				| @ -48,7 +48,7 @@ _expression_ in a programming language (like those in the form `fact(n)`) | ||||
| or a value in that same programming language (like `5`). | ||||
| 
 | ||||
| Dealing with values is rather simple. Most languages have finite numbers, | ||||
| usually with \\(2^{32}\\) values, which have type `int`, | ||||
| 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 occasionally | ||||
| @ -129,20 +129,20 @@ terminate; that is the [halting problem](https://en.wikipedia.org/wiki/Halting_p | ||||
| 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\\). | ||||
| 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 | ||||
| possible values of `unsigned int` are \\(\\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`. | ||||
| possible values of `unsigned int` are \(\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 | ||||
| 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 | ||||
| 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: | ||||
| 
 | ||||
| @ -152,8 +152,8 @@ 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 | ||||
| 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 | ||||
| @ -187,7 +187,7 @@ 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 in [denotational semantics](https://en.wikipedia.org/wiki/Denotational_semantics) | ||||
| we _do_ extend types with \\(\\bot\\)). But denotational semantics are not | ||||
| we _do_ extend types with \(\bot\)). But denotational semantics are not | ||||
| the only place where types are implicitly extend with an extra value; | ||||
| let's look at Java. | ||||
| 
 | ||||
| @ -294,7 +294,7 @@ question. Its purpose can be one of two things: | ||||
| 
 | ||||
| * The interviewer expected a long-form response such as this one. | ||||
| This is a weird expectation for a software engineering candidate - | ||||
| how does knowing about \\(\\bot\\), `undefined`, or `null` help in | ||||
| how does knowing about \(\bot\), `undefined`, or `null` help in | ||||
| creating software, especially if this information is irrelevant | ||||
| to the company's language of choice? | ||||
| * The interviewer expected the simple answer. In that case, | ||||
|  | ||||
		Loading…
	
		Reference in New Issue
	
	Block a user