Created
May 2, 2019 22:48
-
-
Save tonystubblebine/9415ff6616a4db45e9b23a051296ecda to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <div data-post-id="31535030616b" data-source="post_page" data-collection-id="d0b105d10f0a" data-tracking-context="postPage" data-scroll="native"> | |
| <section> | |
| <div> | |
| <div> | |
| <p>When we were getting ready to launch <a href="http://medium.com/better-programming" target="_blank" data-href="http://medium.com/better-programming">Better Programming</a>, I reached out to someone I consider a master of programming, <a href="http://raganwald.com/" target="_blank" rel="nofollow noopener" data-href="http://raganwald.com/">Reginald Braithwaite</a> (known as <a href="https://twitter.com/raganwald" target="_blank" rel="nofollow noopener" data-href="https://twitter.com/raganwald">Raganwald</a> in many quarters). What I wanted to know is if he’d contribute a sample chapter from his book <a href="https://leanpub.com/javascriptallongesix" target="_blank" rel="nofollow noopener" data-href="https://leanpub.com/javascriptallongesix">JavaScript Allongé, the “Six” Edition</a>.</p> | |
| <p>His reaction, instead, was simply to change the copyright terms on his book to Creative Commons: Attribution/Share-alike and tell me to run wild with it. (Maybe wild is an overstatement).</p> | |
| <p>So below is a section of the book, a very long section, that I found valuable in a very particular way. There are lots of javascript tutorials for people who’ve never programmed before. But I’ve programmed forever, at least since 1994 (or even the 80s if you count moving an on-screen turtle with Logo).</p> | |
| <p>However, when the programming world jumped to Javascript, I got a little lost. It took me a while to realize why, although it’s obvious in hindsight. I never really understood the fundamentals of the Javascript language. I’d previously always had the experience of languages being similar enough that I was mostly just looking up the occasional syntax detail. For example, I shipped my first PHP and Rails projects with a mental model that was based on Perl web development. Javascript was just a bit too different though, and so I find myself needing to go back and study the fundamentals.</p> | |
| <p>That’s where Reginald’s book comes in. I find his writing to be pedantic in ways that remind me of my computer science professors. And that’s exactly what I’m looking for — this isn’t a tutorial for first-time programmers. Plus, I imagine that Reginald would say that having pedantically detailed knowledge of your programming languages is pragmatic — you’ll work faster and make fewer mistakes.</p> | |
| <p>The tutorial below does start with the extreme basics: values and then variables. I found it valuable to get that refresher. But the real meat came when he gets into functions.</p> | |
| <p>I read the below in Chrome with my Javascript console on like so. That way I could test my own versions of the code as I went.</p> | |
| <figure> | |
| <div> | |
| <div data-image-id="1*JgwCpVJgIazqXPhXhUkfdQ.png" data-width="2866" data-height="1486" data-action="zoom" data-action-value="1*JgwCpVJgIazqXPhXhUkfdQ.png" data-scroll="native"><canvas width="75" height="38"></canvas><img src="https://cdn-images-1.medium.com/max/1600/1*JgwCpVJgIazqXPhXhUkfdQ.png" alt="" data-src="https://cdn-images-1.medium.com/max/1600/1*JgwCpVJgIazqXPhXhUkfdQ.png" /></div> | |
| </div> | |
| <figcaption>Open the Javascript console by right clicking > Inspect > Console</figcaption> | |
| </figure> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h3>Prelude: Values and Expressions over Coffee</h3> | |
| <p><em>The following material is extremely basic, however like most stories, the best way to begin is to start at the very beginning.</em></p> | |
| <p>Imagine we are visiting our favourite coffee shop. They will make for you just about any drink you desire, from a short, intense espresso ristretto through a dry cappuccino, up to those coffee-flavoured desert concoctions featuring various concentrated syrups and milks. (You tolerate the existence of sugary drinks because they provide a sufficient profit margin to the establishment to finance your hanging out there all day using their WiFi and ordering a $3 drink every few hours.)</p> | |
| <p>You express your order at one end of their counter, the folks behind the counter perform their magic, and deliver the coffee you value at the other end. This is exactly how the JavaScript environment works for the purpose of this book. We are going to dispense with web servers, browsers, and other complexities and deal with this simple model: You give the computer an expression, and it returns a value, just as you express your wishes to a barista and receive a coffee in return.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>values are expressions</h4> | |
| <p>All values are expressions. Say you hand the barista a café Cubano. Yup, you hand over a cup with some coffee infused through partially caramelized sugar. You say, “I want one of these.” The barista is no fool, she gives it straight back to you, and you get exactly what you want. Thus, a café Cubano is an expression (you can use it to place an order) and a value (you get it back from the barista).</p> | |
| <p>Let’s try this with something the computer understands easily:</p> | |
| <pre><code>42</code></pre> | |
| <p>Is this an expression? A value? Neither? Or both?</p> | |
| <p>The answer is, this is both an expression <em>and</em> a value. The way you can tell that it’s both is very easy: When you type it into JavaScript, you get the same thing back, just like our café Cubano:</p> | |
| <pre><code>42</code> <br /><code>//=> 42</code></pre> | |
| <p>All values are expressions. That’s easy! Are there any other kinds of expressions? Sure! let’s go back to the coffee shop. Instead of handing over the finished coffee, we can hand over the ingredients. Let’s hand over some ground coffee plus some boiling water.</p> | |
| <p>Astute readers will realize we’re omitting something. Congratulations! Take a sip of espresso. We’ll get to that in a moment.</p> | |
| <p>Now the barista gives us back an espresso. And if we hand over the espresso, we get the espresso right back. So, boiling water plus ground coffee is an expression, but it isn’t a value. Boiling water is a value. Ground coffee is a value. Espresso is a value. Boiling water plus ground coffee is an expression.</p> | |
| <p>Let’s try this as well with something else the computer understands easily:</p> | |
| <pre><code>"JavaScript"</code> <code>+</code> <code>" "</code> <code>+</code> <code>"Allonge"</code> <br /><code>//=> "JavaScript Allonge"</code></pre> | |
| <p>Now we see that “strings” are values, and you can make an expression out of strings and an operator <code>+</code>. Since strings are values, they are also expressions by themselves. But strings with operators are not values, they are expressions. Now we know what was missing with our “coffee grounds plus hot water” example. The coffee grounds were a value, the boiling hot water was a value, and the “plus” operator between them made the whole thing an expression that was not a value.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>values and identity</h4> | |
| <p>In JavaScript, we test whether two values are identical with the <code>===</code> operator, and whether they are not identical with the <code>!==</code> operator:</p> | |
| <pre><code>2</code> <code>===</code> <code>2</code> <br /><code>//=> true</code> </pre> | |
| <pre><code>'hello'</code> <code>!==</code> <code>'goodbye'</code> <br /><code>//=> true</code></pre> | |
| <p>How does <code>===</code> work, exactly? Imagine that you’re shown a cup of coffee. And then you’re shown another cup of coffee. Are the two cups “identical?” In JavaScript, there are four possibilities:</p> | |
| <p>First, sometimes, the cups are of different kinds. One is a demitasse, the other a mug. This corresponds to comparing two things in JavaScript that have different <em>types</em>. For example, the string <code>"2"</code> is not the same thing as the number <code>2</code>. Strings and numbers are different types, so strings and numbers are never identical:</p> | |
| <pre><code>2</code> <code>===</code> <code>'2'</code> <br /><code>//=> false</code> </pre> | |
| <pre><code>true</code> <code>!==</code> <code>'true'</code> <br /><code>//=> true</code></pre> | |
| <p>Second, sometimes, the cups are of the same type–perhaps two espresso cups–but they have different contents. One holds a single, one a double. This corresponds to comparing two JavaScript values that have the same type but different “content.” For example, the number <code>5</code> is not the same thing as the number <code>2</code>.</p> | |
| <pre><code>true</code> <code>===</code> <code>false</code> <br /><code>//=> false</code> </pre> | |
| <pre><code>2</code> <code>!==</code> <code>5</code> <br /><code>//=> true</code> </pre> | |
| <pre><code>'two'</code> <code>===</code> <code>'five'</code> <br /><code>//=> false</code></pre> | |
| <p>What if the cups are of the same type <em>and</em> the contents are the same? Well, JavaScript’s third and fourth possibilities cover that.</p> | |
| <h4>value types</h4> | |
| <p>Third, some types of cups have no distinguishing marks on them. If they are the same kind of cup, and they hold the same contents, we have no way to tell the difference between them. This is the case with the strings, numbers, and booleans we have seen so far.</p> | |
| <pre><code>2</code> <code>+</code> <code>2</code> <code>===</code> <code>4</code> <br /><code>//=> true</code> </pre> | |
| <pre><code>(2</code> <code>+</code> <code>2</code> <code>===</code> <code>4)</code> <code>===</code> <code>(2</code> <code>!==</code> <code>5)</code> <br /><code>//=> true</code></pre> | |
| <p>Note well what is happening with these examples: Even when we obtain a string, number, or boolean as the result of evaluating an expression, it is identical to another value of the same type with the same “content.” Strings, numbers, and booleans are examples of what JavaScript calls “value” or “primitive” types. We’ll use both terms interchangeably.</p> | |
| <p>We haven’t encountered the fourth possibility yet. Stretching the metaphor somewhat, some types of cups have a serial number on the bottom. So even if you have two cups of the same type, and their contents are the same, you can still distinguish between them.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>reference types</h4> | |
| <p>So what kinds of values might be the same type and have the same contents, but not be considered identical to JavaScript? Let’s meet a data structure that is very common in contemporary programming languages, the <em>Array</em> (other languages sometimes call it a List or a Vector).</p> | |
| <p>An array looks like this: <code>[1, 2, 3]</code>. This is an expression, and you can combine <code>[]</code> with other expressions. Go wild with things like:</p> | |
| <pre><code>[2-1,</code> <code>2,</code> <code>2+1]</code> <br /><code>[1,</code> <code>1+1,</code> <code>1+1+1]</code></pre> | |
| <p>Notice that you are always generating arrays with the same contents. But are they identical the same way that every value of <code>42</code> is identical to every other value of <code>42</code>? Try these for yourself:</p> | |
| <pre><code>[2-1,</code> <code>2,</code> <code>2+1]</code> <code>===</code> <code>[1,2,3]</code> <br /><code>[1,2,3]</code> <code>===</code> <code>[1,</code> <code>2,</code> <code>3]</code> <br /><code>[1,</code> <code>2,</code> <code>3]</code> <code>===</code> <code>[1,</code> <code>2,</code> <code>3]</code></pre> | |
| <p>How about that! When you type <code>[1, 2, 3]</code> or any of its variations, you are typing an expression that generates its own <em>unique</em> array that is not identical to any other array, even if that other array also looks like <code>[1, 2, 3]</code>. It’s as if JavaScript is generating new cups of coffee with serial numbers on the bottom.</p> | |
| <p>They look the same, but if you examine them with <code>===</code>, you see that they are different. Every time you evaluate an expression (including typing something in) to create an array, you’re creating a new, distinct value even if it <em>appears</em> to be the same as some other array value. As we’ll see, this is true of many other kinds of values, including <em>functions</em>, the main subject of this book.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>A Rich Aroma: Basic Numbers</h4> | |
| <blockquote>In computer science, a literal is a notation for representing a fixed value in source code. Almost all programming languages have notations for atomic values such as integers, floating-point numbers, and strings, and usually for booleans and characters; some also have notations for elements of enumerated types and compound values such as arrays, records, and objects. An anonymous function is a literal for the function type. — <a href="https://en.wikipedia.org/wiki/Literal_%28computer_programming%29" target="_blank" rel="nofollow noopener" data-href="https://en.wikipedia.org/wiki/Literal_(computer_programming)">Wikipedia</a></blockquote> | |
| <p>JavaScript, like most languages, has a collection of literals. We saw that an expression consisting solely of numbers, like <code>42</code>, is a literal. It represents the number forty-two, which is 42 base 10. Not all numbers are base ten. If we start a literal with a zero, it is an octal literal. So the literal <code>042</code> is 42 base 8, which is actually 34 base 10.</p> | |
| <p>Internally, both <code>042</code> and <code>34</code> have the same representation, as <a href="http://en.wikipedia.org/wiki/Double-precision_floating-point_format" target="_blank" rel="nofollow noopener" data-href="http://en.wikipedia.org/wiki/Double-precision_floating-point_format">double-precision floating point</a> numbers. A computer’s internal representation for numbers is important to understand. The machine’s representation of a number almost never lines up perfectly with our understanding of how a number behaves, and thus there will be places where the computer’s behaviour surprises us if we don’t know a little about what it’s doing “under the hood.”</p> | |
| <p>For example, the largest integer JavaScript can safely handle is <code>9007199254740991</code>, or <code>2^53 - 1</code>. Like most programming languages, JavaScript does not allow us to use commas to separate groups of digits.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>floating</h4> | |
| <p>Most programmers never encounter the limit on the magnitude of an integer. But we mentioned that numbers are represented internally as floating point, meaning that they need not be just integers. We can, for example, write <code>1.5</code>or <code>33.33</code>, and JavaScript represents these literals as floating point numbers.</p> | |
| <p>It’s tempting to think we now have everything we need to do things like handle amounts of money, but as the late John Belushi would say, “<a href="https://www.youtube.com/watch?v=4Q4JfaHjAng" target="_blank" rel="nofollow noopener" data-href="https://www.youtube.com/watch?v=4Q4JfaHjAng">Nooooooooooooooooooooo.</a>” A computer’s internal representation for a floating point number is binary, while our literal number was in base ten. This makes no meaningful difference for integers, but it does for fractions, because some fractions base 10 do not have exact representations base 2.</p> | |
| <p>One of the most oft-repeated examples is this:</p> | |
| <pre><code>1.0</code> <br /><code>//=> 1</code> </pre> | |
| <pre><code>1.0</code> <code>+</code> <code>1.0</code> <br /><code>//=> 2</code> </pre> | |
| <pre><code>1.0</code> <code>+</code> <code>1.0</code> <code>+</code> <code>1.0</code> <br /><code>//=> 3</code></pre> | |
| <p>However:</p> | |
| <pre><code>0.1</code> <br /><code>//=> 0.1</code> </pre> | |
| <pre><code>0.1</code> <code>+</code> <code>0.1</code> <br /><code>//=> 0.2</code> </pre> | |
| <pre><code>0.1</code> <code>+</code> <code>0.1</code> <code>+</code> <code>0.1</code> <br /><code>//=> 0.30000000000000004</code></pre> | |
| <p>This kind of “inexactitude” can be ignored when performing calculations that have an acceptable deviation. For example, when centering some text on a page, as long as the difference between what you might calculate longhand and JavaScript’s calculation is less than a pixel, there is no observable error.</p> | |
| <p>But as a rule, if you need to work with real numbers, you should have more than a nodding acquaintance with the <a href="https://en.wikipedia.org/wiki/IEEE_floating_point" target="_blank" rel="nofollow noopener" data-href="https://en.wikipedia.org/wiki/IEEE_floating_point">IEEE Standard for Floating-Point Arithmetic</a>. Professional programmers almost never use floating point numbers to represent monetary amounts. For example, “$43.21” will nearly always be presented as two numbers: <code>43</code> for dollars and <code>21</code> for cents, not <code>43.21</code>. In this book, we need not think about such details, but outside of this book, we must.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>operations on numbers</h4> | |
| <p>As we’ve seen, JavaScript has many common arithmetic operators. We can create expressions that look very much like mathematical expressions, for example, we can write <code>1 + 1</code> or <code>2 * 3</code> or <code>42 - 34</code> or even <code>6 / 2</code>. These can be combined to make more complex expressions, like <code>2 * 5 + 1</code>.</p> | |
| <p>In JavaScript, operators have an order of precedence designed to mimic the way humans typically parse written arithmetic. So:</p> | |
| <pre><code>2</code> <code>*</code> <code>5</code> <code>+</code> <code>1</code> <br /><code>//=> 11</code> </pre> | |
| <pre><code>1</code> <code>+</code> <code>5</code> <code>*</code> <code>2</code> <br /><code>//=> 11</code></pre> | |
| <p>JavaScript treats the expressions as if we had written <code>(2 * 5) + 1</code> and <code>1 + (5 * 2)</code>, because the <code>*</code> operator has a <em>higher precedence</em> than the <code>+</code> operator. JavaScript has many more operators. In a sense, they behave like little functions. If we write <code>1 + 2</code>, this is conceptually similar to writing <code>plus(1, 2)</code> (assuming we have a function that adds two numbers bound to the name <code>plus</code>, of course).</p> | |
| <p>In addition to the common <code>+</code>, <code>-</code>, <code>*</code>, and <code>/</code>, JavaScript also supports modulus, <code>%</code>, and unary negation, <code>-</code>:</p> | |
| <pre><code>-(457</code> <code>%</code> <code>3)</code> <br /><code>//=> -1</code></pre> | |
| <p>There are lots and lots more operators that can be used with numbers, including bitwise operators like <code>|</code> and <code>&</code> that allow you to operate directly on a number’s binary representation, and a number of other operators that perform assignment or logical comparison that we will look at later.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h3>As Little As Possible About Functions, But No Less</h3> | |
| <p>In JavaScript, functions are values, but they are also much more than simple numbers, strings, or even complex data structures like trees or maps. Functions represent computations to be performed. Like numbers, strings, and arrays, they have a representation. Let’s start with the second simplest possible function. In JavaScript, it looks like this:</p> | |
| <pre><code>()</code> <code>=></code> <code>0</code></pre> | |
| <p>This is a function that is applied to no values and returns <code>0</code>. Let’s verify that our function is a value like all others:</p> | |
| <pre><code>(()</code> <code>=></code> <code>0)</code> <br /><code>//=> [Function]</code></pre> | |
| <p>What!? Why didn’t it type back <code>() => 0</code> for us? This <em>seems</em> to break our rule that if an expression is also a value, JavaScript will give the same value back to us. What’s going on? The simplest and easiest answer is that although the JavaScript interpreter does indeed return that value, displaying it on the screen is a slightly different matter. <code>[Function]</code> is a choice made by the people who wrote Node.js, the JavaScript environment that hosts the JavaScript REPL. If you try the same thing in a browser, you may see something else.</p> | |
| <p>I’d prefer something else, but I must accept that what gets typed back to us on the screen is arbitrary, and all that really counts is that it is somewhat useful for a human to read. But we must understand that whether we see <code>[Function]</code> or <code>() => 0</code>, internally JavaScript has a full and proper function.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>functions and identities</h4> | |
| <p>You recall that we have two types of values with respect to identity: Value types and reference types. Value types share the same identity if they have the same contents. Reference types do not.</p> | |
| <p>Which kind are functions? Let’s try them out and see. For reasons of appeasing the JavaScript parser, we’ll enclose our functions in parentheses:</p> | |
| <pre><code>(()</code> <code>=></code> <code>0)</code> <code>===</code> <code>(()</code> <code>=></code> <code>0)</code> <br /><code>//=> false</code></pre> | |
| <p>Like arrays, every time you evaluate an expression to produce a function, you get a new function that is not identical to any other function, even if you use the same expression to generate it. “Function” is a reference type.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>applying functions</h4> | |
| <p>Let’s put functions to work. The way we use functions is to <em>apply</em> them to zero or more values called <em>arguments</em>. Just as <code>2 + 2</code> produces a value (in this case <code>4</code>), applying a function to zero or more arguments produces a value as well.</p> | |
| <p>Here’s how we apply a function to some values in JavaScript: Let’s say that <em>fn_expr</em> is an expression that when evaluated, produces a function. Let’s call the arguments <em>args</em>. Here’s how to apply a function to some arguments:</p> | |
| <pre><em>fn_expr</em><code>(</code><em>args</em><code>)</code></pre> | |
| <p>Right now, we only know about one such expression: <code>() => 0</code>, so let’s use it. We’ll put it in parentheses to keep the parser happy, like we did above: <code>(() => 0)</code>. Since we aren’t giving it any arguments, we’ll simply write <code>()</code> after the expression. So we write:</p> | |
| <pre><code>(()</code> <code>=></code> <code>0)()</code> <br /><code>//=> 0</code></pre> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>functions that return values and evaluate expressions</h4> | |
| <p>We’ve seen <code>() => 0</code>. We know that <code>(() => 0)()</code> returns <code>0</code>, and this is unsurprising. Likewise, the following all ought to be obvious:</p> | |
| <pre><code>(()</code> <code>=></code> <code>1)()</code> <br /><code>//=> 1</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>"Hello, JavaScript")()</code> <br /><code>//=> "Hello, JavaScript"</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>Infinity)()</code> <br /><code>//=> Infinity</code></pre> | |
| <p>Well, the last one’s a doozy, but still, the general idea is this: We can make a function that returns a value by putting the value to the right of the arrow.</p> | |
| <p>In the prelude, we looked at expressions. Values like <code>0</code> are expressions, as are things like <code>40 + 2</code>. Can we put an expression to the right of the arrow?</p> | |
| <pre><code>(()</code> <code>=></code> <code>1</code> <code>+</code> <code>1)()</code> <br /><code>//=> 2</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>"Hello, "</code> <code>+</code> <code>"JavaScript")()</code> <br /><code>//=> "Hello, JavaScript"</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>Infinity</code> <code>*</code> <code>Infinity)()</code> <br /><code>//=> Infinity</code></pre> | |
| <p>Yes, we can. We can put any expression to the right of the arrow. For example, <code>(() => 0)()</code> is an expression. Can we put it to the right of an arrow, like this: <code>() => (() => 0)()</code>?</p> | |
| <p>Let’s try it:</p> | |
| <pre><code>(()</code> <code>=></code> <code>(()</code> <code>=></code> <code>0)())()</code> <br /><code>//=> 0</code></pre> | |
| <p>Yes, we can! Functions can return the value of evaluating another function.</p> | |
| <p>When dealing with expressions that have a lot of the same characters (like parentheses), you may find it helpful to format the code to make things stand out. So we can also write:</p> | |
| <pre><code>(()</code> <code>=></code><br /> <code>(()</code> <code>=></code> <code>0</code><br /> <code>)()</code><br /><code>)()</code><br /><code>//=> 0</code></pre> | |
| <p>It evaluates to the same thing, <code>0</code>.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>commas</h4> | |
| <p>The comma operator in JavaScript is interesting. It takes two arguments, evaluates them both, and itself evaluates to the value of the right-hand argument. In other words:</p> | |
| <pre><code>(1,</code> <code>2)</code> <br /><code>//=> 2</code> </pre> | |
| <pre><code>(1</code> <code>+</code> <code>1,</code> <code>2</code> <code>+</code> <code>2)</code> <br /><code>//=> 4</code></pre> | |
| <p>We can use commas with functions to create functions that evaluate multiple expressions:</p> | |
| <pre><code>(()</code> <code>=></code> <code>(1</code> <code>+</code> <code>1,</code> <code>2</code> <code>+</code> <code>2))()</code> <br /><code>//=> 4</code></pre> | |
| <p>This is useful when trying to do things that might involve <em>side-effects</em>, but we’ll get to that later. In most cases, JavaScript does not care whether things are separated by spaces, tabs, or line breaks. So we can also write:</p> | |
| <pre><code>()</code> <code>=></code> <br /> <code>(1</code> <code>+</code> <code>1,</code> <code>2</code> <code>+</code> <code>2)</code></pre> | |
| <p>Or even:</p> | |
| <pre><code>()</code> <code>=></code> <code>(</code> <br /> <code>1</code> <code>+</code> <code>1,</code> <br /> <code>2</code> <code>+</code> <code>2</code> <br /><code>)</code></pre> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>the simplest possible block</h4> | |
| <p>There’s another thing we can put to the right of an arrow, a <em>block</em>. A block has zero or more <em>statements</em>, separated by semicolons.</p> | |
| <p>So, this is a valid function:</p> | |
| <pre><code>()</code> <code>=></code> <code>{}</code></pre> | |
| <p>It returns the result of evaluating a block that has no statements. What would that be? Let’s try it:</p> | |
| <pre><code>(()</code> <code>=></code> <code>{})()</code> <br /><code>//=> undefined</code></pre> | |
| <p>What is this <code>undefined</code>?</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4><code>undefined</code></h4> | |
| <p>In JavaScript, the absence of a value is written <code>undefined</code>, and it means there is no value. It will crop up again. <code>undefined</code> is its own type of value, and it acts like a value type:</p> | |
| <pre><code>undefined</code> <br /><code>//=> undefined</code></pre> | |
| <p>Like numbers, booleans and strings, JavaScript can print out the value <code>undefined</code>.</p> | |
| <pre><code>undefined</code> <code>===</code> <code>undefined</code> <br /><code>//=> true</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>{})()</code> <code>===</code> <code>(()</code> <code>=></code> <code>{})()</code> <br /><code>//=> true</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>{})()</code> <code>===</code> <code>undefined</code> <br /><code>//=> true</code></pre> | |
| <p>No matter how you evaluate <code>undefined</code>, you get an identical value back. <code>undefined</code> is a value that means “I don’t have a value.” But it’s still a value :-)</p> | |
| <p>You might think that <code>undefined</code> in JavaScript is equivalent to <code>NULL</code> in SQL. No. In SQL, two things that are <code>NULL</code> are not equal to nor share the same identity, because two unknowns can’t be equal. In JavaScript, every <code>undefined</code> is identical to every other <code>undefined</code>.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>void</h4> | |
| <p>We’ve seen that JavaScript represents an undefined value by typing <code>undefined</code>, and we’ve generated undefined values in two ways:</p> | |
| <ol> | |
| <li>By evaluating a function that doesn’t return a value <code>(() => {})()</code>, and;</li> | |
| <li>By writing <code>undefined</code> ourselves.</li> | |
| </ol> | |
| <p>There’s a third way, with JavaScript’s <code>void</code> operator. Behold:</p> | |
| <pre><code>void</code> <code>0</code> <br /><code>//=> undefined</code> </pre> | |
| <pre><code>void</code> <code>1</code> <br /><code>//=> undefined</code> </pre> | |
| <pre><code>void</code> <code>(2</code> <code>+</code> <code>2)</code> <br /><code>//=> undefined</code></pre> | |
| <p><code>void</code> is an operator that takes any value and evaluates to <code>undefined</code>, always. So, when we deliberately want an undefined value, should we use the first, second, or third form? The answer is, use <code>void</code>. By convention, use <code>void 0</code>.</p> | |
| <p>The first form works but it’s cumbersome. The second form works most of the time, but it is possible to break it by reassigning <code>undefined</code> to a different value. The third form is guaranteed to always work, so that’s what we will use.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>back on the block</h4> | |
| <p>Back to our function. We evaluated this:</p> | |
| <pre><code>(()</code> <code>=></code> <code>{})()</code> <br /><code>//=> undefined</code></pre> | |
| <p>We said that the function returns the result of evaluating a <em>block</em>, and we said that a block is a (possibly empty) list of JavaScript <em>statements</em> separated by semicolons.</p> | |
| <p>Something like: <code>{</code> statement1<code>;</code> statement2<code>;</code> statement3<code>; ... ;</code>statementn <code>}</code></p> | |
| <p>We haven’t discussed these <em>statements</em>. What’s a statement?</p> | |
| <p>There are many kinds of JavaScript statements, but the first kind is one we’ve already met. An expression is a JavaScript statement. Although they aren’t very practical, these are valid JavaScript functions, and they return <code>undefined</code> when applied:</p> | |
| <pre><code>()</code> <code>=></code> <code>{</code> <code>2</code> <code>+</code> <code>2</code> <code>}</code> </pre> | |
| <pre><code>()</code> <code>=></code> <code>{</code> <code>1</code> <code>+</code> <code>1;</code> <code>2</code> <code>+</code> <code>2</code> <code>}</code></pre> | |
| <p>As we saw with commas above, we can rearrange these functions onto multiple lines when we feel its more readable that way:</p> | |
| <pre><code>()</code> <code>=></code> <code>{</code> <br /> <code>1</code> <code>+</code> <code>1;</code> <br /> <code>2</code> <code>+</code> <code>2</code> <br /><code>}</code></pre> | |
| <p>But no matter how we arrange them, a block with one or more expressions still evaluates to <code>undefined</code>:</p> | |
| <pre><code>(()</code> <code>=></code> <code>{</code> <code>2</code> <code>+</code> <code>2</code> <code>})()</code> <br /><code>//=> undefined</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>{</code> <code>1</code> <code>+</code> <code>1;</code> <code>2</code> <code>+</code> <code>2</code> <code>})()</code> <br /><code>//=> undefined</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>{</code> <br /> <code>1</code> <code>+</code> <code>1;</code> <br /> <code>2</code> <code>+</code> <code>2</code> <br /><code>})()</code> <br /><code>//=> undefined</code></pre> | |
| <p>As you can see, a block with one expression does not behave like an expression, and a block with more than one expression does not behave like an expression constructed with the comma operator:</p> | |
| <pre><code>(()</code> <code>=></code> <code>2</code> <code>+</code> <code>2)()</code> <br /><code>//=> 4</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>{</code> <code>2</code> <code>+</code> <code>2</code> <code>})()</code> <br /><code>//=> undefined</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>(1</code> <code>+</code> <code>1,</code> <code>2</code> <code>+</code> <code>2))()</code> <br /><code>//=> 4</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>{</code> <code>1</code> <code>+</code> <code>1;</code> <code>2</code> <code>+</code> <code>2</code> <code>})()</code> <br /><code>//=> undefined</code></pre> | |
| <p>So how do we get a function that evaluates a block to return a value when applied? With the <code>return</code> keyword and any expression:</p> | |
| <pre><code>(()</code> <code>=></code> <code>{</code> <code>return</code> <code>0</code> <code>})()</code> <br /><code>//=> 0</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>{</code> <code>return</code> <code>1</code> <code>})()</code> <br /><code>//=> 1</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>{</code> <code>return</code> <code>'Hello '</code> <code>+</code> <code>'World'</code> <code>})()</code> <br /><code>// 'Hello World'</code></pre> | |
| <p>The <code>return</code> keyword creates a <em>return statement</em> that immediately terminates the function application and returns the result of evaluating its expression. For example:</p> | |
| <pre><code>(()</code> <code>=></code> <code>{</code> <br /> <code>1</code> <code>+</code> <code>1;</code> <br /> <code>return</code> <code>2</code> <code>+</code> <code>2</code> <br /><code>})()</code> <br /><code>//=> 4</code></pre> | |
| <p>And also:</p> | |
| <pre><code>(()</code> <code>=></code> <code>{</code> <br /> <code>return</code> <code>1</code> <code>+</code> <code>1;</code> <br /> <code>2</code> <code>+</code> <code>2</code> <br /><code>})()</code> <br /><code>//=> 2</code></pre> | |
| <p>The return statement is the first statement we’ve seen, and it behaves differently than an expression. For example, you can’t use one as the expression in a simple function, because it isn’t an expression:</p> | |
| <pre><code>(()</code> <code>=></code> <code>return</code> <code>0)()</code> <br /><code>//=> ERROR</code></pre> | |
| <p>Statements belong inside blocks and only inside blocks. Some languages simplify this by making everything an expression, but JavaScript maintains this distinction, so when learning JavaScript we also learn about statements like function declarations, for loops, if statements, and so forth. We’ll see a few more of these later.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>functions that evaluate to functions</h4> | |
| <p>If an expression that evaluates to a function is, well, an expression, and if a return statement can have any expression on its right side… <em>Can we put an expression that evaluates to a function on the right side of a function expression?</em></p> | |
| <p>Yes:</p> | |
| <pre><code>()</code> <code>=></code> <code>()</code> <code>=></code> <code>0</code></pre> | |
| <p>That’s a function! It’s a function that when applied, evaluates to a function that when applied, evaluates to <code>0</code>. So we have <em>a function, that returns a function, that returns zero</em>. Likewise:</p> | |
| <pre><code>()</code> <code>=></code> <code>()</code> <code>=></code> <code>true</code></pre> | |
| <p>That’s a function, that returns a function, that returns <code>true</code>:</p> | |
| <pre><code>(()</code> <code>=></code> <code>()</code> <code>=></code> <code>true)()()</code> <br /><code>//=> true</code></pre> | |
| <p>We could, of course, do the same thing with a block if we wanted:</p> | |
| <pre><code>()</code> <code>=></code> <code>()</code> <code>=></code> <code>{</code> <code>return</code> <code>true;</code> <code>}</code></pre> | |
| <p>But we generally don’t.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <p>Well. We’ve been very clever, but so far this all seems very abstract.</p> | |
| <p>Diffraction of a crystal is beautiful and interesting in its own right, but you can’t blame us for wanting to be shown a practical use for it, like being able to determine the composition of a star millions of light years away. So… In the next section, we’ll see how to make functions practical.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h3>Ah. I’d Like to Have an Argument, Please.</h3> | |
| <p>Up to now, we’ve looked at functions without arguments. We haven’t even said what an argument <em>is</em>, only that our functions don’t have any.</p> | |
| <p>Most programmers are perfectly familiar with arguments (often called “parameters”). Secondary school mathematics discusses this. So you know what they are, and I know that you know what they are, but please be patient with the explanation!</p> | |
| <p>Let’s make a function with an argument:</p> | |
| <pre><code>(room)</code> <code>=></code> <code>{}</code></pre> | |
| <p>This function has one argument, <code>room</code>, and an empty body. Here’s a function with two arguments and an empty body:</p> | |
| <pre><code>(room,</code> <code>board)</code> <code>=></code> <code>{}</code></pre> | |
| <p>I’m sure you are perfectly comfortable with the idea that this function has two arguments, <code>room</code>, and <code>board</code>. What does one do with the arguments? Use them in the body, of course. What do you think this is?</p> | |
| <pre><code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>3.14159265</code></pre> | |
| <p>It’s a function for calculating the circumference of a circle given the diameter. I read that aloud as “When applied to a value representing the diameter, this function <em>returns</em> the diameter times 3.14159265.”</p> | |
| <p>Remember that to apply a function with no arguments, we wrote <code>(() => {})()</code>. To apply a function with an argument (or arguments), we put the argument (or arguments) within the parentheses, like this:</p> | |
| <pre><code>((diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>3.14159265)(2)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>You won’t be surprised to see how to write and apply a function to two arguments:</p> | |
| <pre><code>((room,</code> <code>board)</code> <code>=></code> <code>room</code> <code>+</code> <code>board)(800,</code> <code>150)</code> <br /><code>//=> 950</code></pre> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>a quick summary of functions and bodies</h4> | |
| <p>How arguments are used in a body’s expression is probably perfectly obvious to you from the examples, especially if you’ve used any programming language (except for the dialect of BASIC–which I recall from my secondary school–that didn’t allow parameters when you called a procedure).</p> | |
| <p>Expressions consist either of representations of values (like <code>3.14159265</code>, <code>true</code>, and <code>undefined</code>), operators that combine expressions (like <code>3 + 2</code>), some special forms like <code>[1, 2, 3]</code> for creating arrays out of expressions, or <code>function (</code><em>arguments</em><code>) {</code><em>body-statements</em><code>}</code> for creating functions.</p> | |
| <p>One of the important possible statements is a return statement. A return statement accepts any valid JavaScript expression.</p> | |
| <p>This loose definition is recursive, so we can intuit (or use our experience with other languages) that since a function can contain a return statement with an expression, we can write a function that returns a function, or an array that contains another array expression. Or a function that returns an array, an array of functions, a function that returns an array of functions, and so forth:</p> | |
| <pre><code>()</code> <code>=></code> <code>()</code> <code>=></code> <code>{};</code> </pre> | |
| <pre><code>()</code> <code>=></code> <code>[</code> <code>1,</code> <code>2,</code> <code>3];</code> </pre> | |
| <pre><code>[1,</code> <code>[2,</code> <code>3],</code> <code>4];</code> </pre> | |
| <pre><code>()</code> <code>=></code> <code>[</code> <br /> <code>()</code> <code>=></code> <code>1,</code> <br /> <code>()</code> <code>=></code> <code>2,</code> <br /> <code>()</code> <code>=></code> <code>3</code> <br /><code>];</code></pre> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>call by value</h4> | |
| <p>Like most contemporary programming languages, JavaScript uses the “call by value” evaluation strategy. That means that when you write some code that appears to apply a function to an expression or expressions, JavaScript evaluates all of those expressions and applies the functions to the resulting value(s).</p> | |
| <p>So when you write:</p> | |
| <pre><code>((diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>3.14159265)(1</code> <code>+</code> <code>1)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>What happened internally is that the expression <code>1 + 1</code> was evaluated first, resulting in <code>2</code>. Then our circumference function was applied to <code>2</code>.</p> | |
| <p>We’ll see below that while JavaScript always calls by value, the notion of a “value” has additional subtlety. But before we do, let’s look at variables.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>variables and bindings</h4> | |
| <p>Right now everything looks simple and straightforward, and we can move on to talk about arguments in more detail. And we’re going to work our way up from <code>(diameter) => diameter * 3.14159265</code> to functions like:</p> | |
| <pre><code>(x)</code> <code>=></code> <code>(y)</code> <code>=></code> <code>x</code></pre> | |
| <p><code>(x) => (y) => x</code> just looks crazy, as if we are learning English as a second language and the teacher promises us that soon we will be using words like <em>antidisestablishmentarianism</em>. Besides a desire to use long words to sound impressive, this is not going to seem attractive until we find ourselves wanting to discuss the role of the Church of England in 19th-century British politics.</p> | |
| <p>But there’s another reason for learning the word <em>antidisestablishmentarianism</em>: We might learn how prefixes and postfixes work in English grammar. It’s the same thing with <code>(x) => (y) => x</code>. It has a certain important meaning in its own right, and it’s also an excellent excuse to learn about functions that make functions, environments, variables, and more.</p> | |
| <p>In order to talk about how this works, we should agree on a few terms (you may already know them, but let’s check-in together and “synchronize our dictionaries”). The first <code>x</code>, the one in <code>(x) => ...</code>, is an <em>argument</em>. The <code>y</code>in <code>function (y) ...</code> is another argument. The second <code>x</code>, the one in <code>=> x</code>, is not an argument, <em>it’s an expression referring to a variable</em>. Arguments and variables work the same way whether we’re talking about <code>(x) => (y) => x</code> or just plain <code>(x) => x</code>.</p> | |
| <p>Every time a function is invoked (“invoked” means “applied to zero or more arguments”), a new <em>environment</em> is created. An environment is a (possibly empty) dictionary that maps variables to values by name. The <code>x</code> in the expression that we call a “variable” is itself an expression that is evaluated by looking up the value in the environment.</p> | |
| <p>How does the value get put in the environment? Well for arguments, that is very simple. When you apply the function to the arguments, an entry is placed in the dictionary for each argument. So when we write:</p> | |
| <pre><code>((x)</code> <code>=></code> <code>x)(2)</code> <br /><code>//=> 2</code></pre> | |
| <p>What happens is this:</p> | |
| <ol> | |
| <li>JavaScript parses this whole thing as an expression made up of several sub-expressions.</li> | |
| <li>It then starts evaluating the expression, including evaluating sub-expressions</li> | |
| <li>One sub-expression, <code>(x) => x</code> evaluates to a function.</li> | |
| <li>Another, <code>2</code>, evaluates to the number 2.</li> | |
| <li>JavaScript now evaluates applying the function to the argument <code>2</code>. Here’s where it gets interesting…</li> | |
| <li>An environment is created.</li> | |
| <li>The value ‘2’ is bound to the name ‘x’ in the environment.</li> | |
| <li>The expression ‘x’ (the right side of the function) is evaluated within the environment we just created.</li> | |
| <li>The value of a variable when evaluated in an environment is the value bound to the variable’s name in that environment, which is ‘2’</li> | |
| <li>And that’s our result.</li> | |
| </ol> | |
| <p>When we talk about environments, we’ll use an <a href="http://json.org/" target="_blank" rel="nofollow noopener" data-href="http://json.org/">unsurprising syntax</a> for showing their bindings: <code>{x: 2, ...}</code>. meaning, that the environment is a dictionary, and that the value <code>2</code> is bound to the name <code>x</code>, and that there might be other stuff in that dictionary we aren’t discussing right now.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>call by sharing</h4> | |
| <p>Earlier, we distinguished JavaScript’s <em>value types</em> from its <em>reference types</em>. At that time, we looked at how JavaScript distinguishes objects that are identical from objects that are not. Now it is time to take another look at the distinction between value and reference types.</p> | |
| <p>There is a property that JavaScript strictly maintains: When a value–any value–is passed as an argument to a function, the value bound in the function’s environment must be identical to the original.</p> | |
| <p>We said that JavaScript binds names to values, but we didn’t say what it means to bind a name to a value. Now we can elaborate: When JavaScript binds a value-type to a name, it makes a copy of the value and places the copy in the environment. As you recall, value types like strings and numbers are identical to each other if they have the same content. So JavaScript can make as many copies of strings, numbers, or booleans as it wishes.</p> | |
| <p>What about reference types? JavaScript does not place copies of reference values in any environment. JavaScript places <em>references</em> to reference types in environments, and when the value needs to be used, JavaScript uses the reference to obtain the original.</p> | |
| <p>Because many references can share the same value, and because JavaScript passes references as arguments, JavaScript can be said to implement “call by sharing” semantics. Call by sharing is generally understood to be a specialization of call by value, and it explains why some values are known as value types and other values are known as reference types.</p> | |
| <p>And with that, we’re ready to look at <em>closures</em>. When we combine our knowledge of value types, reference types, arguments, and closures, we’ll understand why this function always evaluates to <code>true</code> no matter what argument you apply it to:</p> | |
| <pre><code>(value)</code> <code>=></code> <code>((ref1,</code> <code>ref2)</code> <code>=></code> <code>ref1</code> <code>===</code> <code>ref2)(value,</code> <code>value)</code></pre> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h3>Closures and Scope</h3> | |
| <p>It’s time to see how a function within a function works:</p> | |
| <pre><code>((x)</code> <code>=></code> <code>(y)</code> <code>=></code> <code>x)(1)(2)</code> <br /><code>//=> 1</code></pre> | |
| <p>First off, let’s use what we learned above. Given <code>(</code><em>some function</em><code>)(</code><em>some argument</em><code>)</code>, we know that we apply the function to the argument, create an environment, bind the value of the argument to the name, and evaluate the function’s expression. So we do that first with this code:</p> | |
| <pre><code>((x)</code> <code>=></code> <code>(y)</code> <code>=></code> <code>x)(1)</code> <br /><code>//=> [Function]</code></pre> | |
| <p>The environment belonging to the function with signature <code>(x) => ...</code>becomes <code>{x: 1, ...}</code>, and the result of applying the function is another function value. It makes sense that the result value is a function, because the expression for <code>(x) => ...</code>’s body is:</p> | |
| <pre><code>(y)</code> <code>=></code> <code>x</code></pre> | |
| <p>So now we have a value representing that function. Then we’re going to take the value of that function and apply it to the argument <code>2</code>, something like this:</p> | |
| <pre><code>((y)</code> <code>=></code> <code>x)(2)</code></pre> | |
| <p>So we seem to get a new environment <code>{y: 2, ...}</code>. How is the expression <code>x</code>going to be evaluated in that function’s environment? There is no <code>x</code> in its environment, it must come from somewhere else.</p> | |
| <p>This, by the way, is one of the great defining characteristics of JavaScript and languages in the same family: Whether they allow things like functions to nest inside each other, and if so, how they handle variables from “outside” of a function that are referenced inside a function. For example, here’s the equivalent code in Ruby:</p> | |
| <pre><code>lambda</code> <code>{</code> <code>|x|</code> <code>lambda</code> <code>{</code> <code>|y|</code> <code>x</code> <code>}</code> <code>}[1][2]</code> <br /><code>#=> 1</code></pre> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>if functions without free variables are pure, are closures impure?</h4> | |
| <p>The function <code>(y) => x</code> is interesting. It contains a <em>free variable</em>, <code>x</code>. A free variable is one that is not bound within the function. Up to now, we’ve only seen one way to “bind” a variable, namely by passing in an argument with the same name. Since the function <code>(y) => x</code> doesn’t have an argument named <code>x</code>, the variable <code>x</code> isn’t bound in this function, which makes it “free.”</p> | |
| <p>Now that we know that variables used in a function are either bound or free, we can bifurcate functions into those with free variables and those without:</p> | |
| <ul> | |
| <li>Functions containing no free variables are called <em>pure functions</em>.</li> | |
| <li>Functions containing one or more free variables are called <em>closures</em>.</li> | |
| </ul> | |
| <p>Pure functions are easiest to understand. They always mean the same thing wherever you use them. Here are some pure functions we’ve already seen:</p> | |
| <pre><code>()</code> <code>=></code> <code>{}</code> <br /><code>(x)</code> <code>=></code> <code>x</code> <br /><code>(x)</code> <code>=></code> <code>(y)</code> <code>=></code> <code>x</code></pre> | |
| <p>The first function doesn’t have any variables, therefore doesn’t have any free variables. The second doesn’t have any free variables, because its only variable is bound. The third one is actually two functions, one inside the other. <code>(y) => ...</code> has a free variable, but the entire expression refers to <code>(x) => ...</code>, and it doesn’t have a free variable: The only variable anywhere in its body is <code>x</code>, which is certainly bound within <code>(x) => ...</code>.</p> | |
| <p>From this, we learn something: A pure function can contain a closure.</p> | |
| <p>If pure functions can contain closures, can a closure contain a pure function? Using only what we’ve learned so far, attempt to compose a closure that contains a pure function. If you can’t, give your reasoning for why it’s impossible.</p> | |
| <p>Pure functions always mean the same thing because all of their “inputs” are fully defined by their arguments. Not so with a closure. If I present to you this pure function <code>(x, y) => x + y</code>, we know exactly what it does with <code>(2, 2)</code>. But what about this closure: <code>(y) => x + y</code>? We can’t say what it will do with argument <code>(2)</code> without understanding the magic for evaluating the free variable <code>x</code>.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>it’s always the environment</h4> | |
| <p>To understand how closures are evaluated, we need to revisit environments. As we’ve said before, all functions are associated with an environment. We also hand-waved something when describing our environment. Remember that we said the environment for <code>((x) => (y) => x)(1)</code> is <code>{x: 1, ...}</code> and that the environment for <code>((y) => x)(2)</code> is <code>{y: 2, ...}</code>? Let’s fill in the blanks!</p> | |
| <p>The environment for <code>((y) => x)(2)</code> is <em>actually</em> <code>{y: 2, '..': {x: 1, ...}}</code>. <code>'..'</code> means something like “parent” or “enclosure” or “super-environment.” It’s <code>(x) => ...</code>’s environment, because the function <code>(y) => x</code>is within <code>(x) => ...</code>’s body. So whenever a function is applied to arguments, its environment always has a reference to its parent environment.</p> | |
| <p>And now you can guess how we evaluate <code>((y) => x)(2)</code> in the environment <code>{y: 2, '..': {x: 1, ...}}</code>. The variable <code>x</code> isn’t in <code>(y) => ...</code>’s immediate environment, but it is in its parent’s environment, so it evaluates to <code>1</code> and that’s what <code>((y) => x)(2)</code> returns even though it ended up ignoring its own argument.</p> | |
| <p><code>(x) => x</code> is called the I Combinator, or the <em>Identity Function</em>. <code>(x) => (y) => x</code> is called the K Combinator, or <em>Kestrel</em>. Some people get so excited by this that they write entire books about them, some are <a href="http://www.amzn.com/0192801422?tag=raganwald001-20" target="_blank" rel="nofollow noopener" data-href="http://www.amzn.com/0192801422?tag=raganwald001-20">great</a>, some — how shall I put this — are <a title="Kestrels, Quirky Birds, and Hopeless Egocentricity" href="https://leanpub.com/combinators" target="_blank" rel="nofollow noopener" data-href="https://leanpub.com/combinators">interesting</a> if you use Ruby.</p> | |
| <p>Functions can have grandparents too:</p> | |
| <pre><code>(x)</code> <code>=></code> <code>(y)</code> <code>=></code> <code>(z)</code> <code>=></code> <code>x</code> <code>+</code> <code>y</code> <code>+</code> <code>z</code></pre> | |
| <p>This function does much the same thing as:</p> | |
| <pre><code>(x,</code> <code>y,</code> <code>z)</code> <code>=></code> <code>x</code> <code>+</code> <code>y</code> <code>+</code> <code>z</code></pre> | |
| <p>Only you call it with <code>(1)(2)(3)</code> instead of <code>(1, 2, 3)</code>. The other big difference is that you can call it with <code>(1)</code> and get a function back that you can later call with <code>(2)(3)</code>.</p> | |
| <p>The first function is the result of <a href="https://en.wikipedia.org/wiki/Currying" target="_blank" rel="nofollow noopener" data-href="https://en.wikipedia.org/wiki/Currying">currying</a> the second function. Calling a curried function with only some of its arguments is sometimes called <a href="https://en.wikipedia.org/wiki/Partial_application" target="_blank" rel="nofollow noopener" data-href="https://en.wikipedia.org/wiki/Partial_application">partial application</a>. Some programming languages automatically curry and partially evaluate functions without the need to manually nest them.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>shadowy variables from a shadowy planet</h4> | |
| <p>An interesting thing happens when a variable has the same name as an ancestor environment’s variable. Consider:</p> | |
| <pre><code>(x)</code> <code>=></code> <code>(x,</code> <code>y)</code> <code>=></code> <code>x</code> <code>+</code> <code>y</code></pre> | |
| <p>The function <code>(x, y) => x + y</code> is a pure function, because its <code>x</code> is defined within its own environment. Although its parent also defines an <code>x</code>, it is ignored when evaluating <code>x + y</code>. JavaScript always searches for a binding starting with the functions own environment and then each parent in turn until it finds one. The same is true of:</p> | |
| <pre><code>(x)</code> <code>=></code> <br /> <code>(x,</code> <code>y)</code> <code>=></code> <br /> <code>(w,</code> <code>z)</code> <code>=></code> <br /> <code>(w)</code> <code>=></code> <br /> <code>x</code> <code>+</code> <code>y</code> <code>+</code> <code>z</code></pre> | |
| <p>When evaluating <code>x + y + z</code>, JavaScript will find <code>x</code> and <code>y</code> in the great-grandparent scope and <code>z</code> in the parent scope. The <code>x</code> in the great-great-grandparent scope is ignored, as are both <code>w</code>s. When a variable has the same name as an ancestor environment’s binding, it is said to <em>shadow</em> the ancestor.</p> | |
| <p>This is often a good thing.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>which came first, the chicken or the egg?</h4> | |
| <p>This behaviour of pure functions and closures has many, many consequences that can be exploited to write software. We are going to explore them in some detail as well as look at some of the other mechanisms JavaScript provides for working with variables and mutable state.</p> | |
| <p>But before we do so, there’s one final question: Where does the ancestry start? If there’s no other code in a file, what is <code>(x) => x</code>’s parent environment?</p> | |
| <p>JavaScript always has the notion of at least one environment we do not control: A global environment in which many useful things are bound such as libraries full of standard functions. So when you invoke <code>((x) => x)(1)</code>in the REPL, its full environment is going to look like this: <code>{x: 1, '..': </code><em>global environment</em><code>}</code>.</p> | |
| <p>Sometimes, programmers wish to avoid this. If you don’t want your code to operate directly within the global environment, what can you do? Create an environment for them, of course. Many programmers choose to write every JavaScript file like this:</p> | |
| <pre><code>// top of the file</code> </pre> | |
| <pre><code>(()</code> <code>=></code> <code>{</code> <br /> <code>// ... lots of JavaScript ...</code> <br /><code>})();</code> </pre> | |
| <pre><code>// bottom of the file</code></pre> | |
| <p>The effect is to insert a new, empty environment in between the global environment and your own functions: <code>{x: 1, '..': {'..': </code><em>global environment</em><code>}}</code>. his helps to prevent programmers from accidentally changing the global state that is shared by all code in the program.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h3>That Constant Coffee Craving</h3> | |
| <p>Up to now, all we’ve really seen are <em>anonymous functions</em>, functions that don’t have a name. This feels very different from programming in most other languages, where the focus is on naming functions, methods, and procedures. Naming things is a critical part of programming, but all we’ve seen so far is how to name arguments.</p> | |
| <p>There are other ways to name things in JavaScript, but before we learn some of those, let’s see how to use what we already have to name things. Let’s revisit a very simple example:</p> | |
| <pre><code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>3.14159265</code></pre> | |
| <p>What is this “3.14159265” number? <a href="https://en.wikipedia.org/wiki/Pi" target="_blank" rel="nofollow noopener" data-href="https://en.wikipedia.org/wiki/Pi">PI</a>, obviously. We’d like to name it so that we can write something like:</p> | |
| <pre><code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI</code></pre> | |
| <p>In order to bind <code>3.14159265</code> to the name <code>PI</code>, we’ll need a function with a parameter of <code>PI</code> applied to an argument of <code>3.14159265</code>. If we put our function expression in parentheses, we can apply it to the argument of <code>3.14159265</code>:</p> | |
| <pre><code>((PI)</code> <code>=></code> <br /><code>// ????</code> <br /><code>)(3.14159265)</code></pre> | |
| <p>What do we put inside our new function that binds <code>3.14159265</code> to the name <code>PI</code> when evaluated? Our circumference function, of course:</p> | |
| <pre><code>((PI)</code> <code>=></code> <br /> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI</code> <br /><code>)(3.14159265)</code></pre> | |
| <p>This expression, when evaluated, returns a function that calculates circumferences. That sounds bad, but when we think about it, <code>(diameter) => diameter * 3.14159265</code> is also an expression, that when evaluated, returns a function that calculates circumferences. All of our “functions” are expressions. This one has a few more moving parts, that’s all. But we can use it just like <code>(diameter) => diameter * 3.14159265</code>.</p> | |
| <p>Let’s test it:</p> | |
| <pre><code>((diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>3.14159265)(2)</code> <br /><code>//=> 6.2831853</code> </pre> | |
| <pre><code>((PI)</code> <code>=></code> <br /> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI</code> <br /><code>)(3.14159265)(2)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>That works! We can bind anything we want in an expression by wrapping it in a function that is immediately invoked with the value we want to bind.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>inside-out</h4> | |
| <p>There’s another way we can make a function that binds <code>3.14159265</code> to the name <code>PI</code> and then uses that in its expression. We can turn things inside-out by putting the binding inside our diameter calculating function, like this:</p> | |
| <pre><code>(diameter)</code> <code>=></code> <br /> <code>((PI)</code> <code>=></code> <br /> <code>diameter</code> <code>*</code> <code>PI)(3.14159265)</code></pre> | |
| <p>It produces the same result as our previous expressions for a diameter-calculating function:</p> | |
| <pre><code>((diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>3.14159265)(2)</code> <br /><code>//=> 6.2831853</code> </pre> | |
| <pre><code>((PI)</code> <code>=></code> <br /> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI</code> <br /><code>)(3.14159265)(2)</code> <br /><code>//=> 6.2831853</code> </pre> | |
| <pre><code>((diameter)</code> <code>=></code> <br /> <code>((PI)</code> <code>=></code> <br /> <code>diameter</code> <code>*</code> <code>PI)(3.14159265))(2)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>Which one is better? Well, the first one seems simplest, but a half-century of experience has taught us that names matter. A “magic literal” like <code>3.14159265</code>is anathema to sustainable software development.</p> | |
| <p>The third one is easiest for most people to read. It separates concerns nicely: The “outer” function describes its parameters:</p> | |
| <pre><code>(diameter)</code> <code>=></code> <code>// ...</code></pre> | |
| <p>Everything else is encapsulated in its body. That’s how it should be, naming <code>PI</code> is its concern, not ours. The other formulation:</p> | |
| <pre><code>((PI)</code> <code>=></code> <code>// ...</code> <code>)(3.14159265)</code></pre> | |
| <p>“Exposes” naming <code>PI</code> first, and we have to look inside to find out why we care. So, should we always write this?</p> | |
| <pre><code>(diameter)</code> <code>=></code> <br /> <code>((PI)</code> <code>=></code> <br /> <code>diameter</code> <code>*</code> <code>PI)(3.14159265)</code></pre> | |
| <p>Well, the wrinkle with this is that typically, invoking functions is considerably more expensive than evaluating expressions. Every time we invoke the outer function, we’ll invoke the inner function. We could get around this by writing</p> | |
| <pre><code>((PI)</code> <code>=></code> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI</code> <code>)(3.14159265)</code></pre> | |
| <p>But then we’ve obfuscated our code, and we don’t want to do that unless we absolutely have to.</p> | |
| <p>What would be very nice is if the language gave us a way to bind names inside of blocks without incurring the cost of a function invocation. And JavaScript does.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>const</h4> | |
| <p>Another way to write our “circumference” function would be to pass <code>PI</code> along with the diameter argument, something like this:</p> | |
| <pre><code>(diameter,</code> <code>PI)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI</code></pre> | |
| <p>And we could use it like this:</p> | |
| <pre><code>((diameter,</code> <code>PI)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI)(2,</code> <code>3.14159265)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>This differs from our example above in that there is only one environment, rather than two. We have one binding in the environment representing our regular argument, and another our “constant.” That’s more efficient, and it’s <em>almost</em> what we wanted all along: A way to bind <code>3.14159265</code> to a readable name.</p> | |
| <p>JavaScript gives us a way to do that, the <code>const</code> keyword. We’ll learn a lot more about <code>const</code> in future sections, but here’s the most important thing we can do with <code>const</code>:</p> | |
| <pre><code>(diameter)</code> <code>=></code> <code>{</code> <br /> <code>const</code> <code>PI</code> <code>=</code> <code>3.14159265;</code> </pre> | |
| <pre><code> return</code> <code>diameter</code> <code>*</code> <code>PI</code> <br /><code>}</code></pre> | |
| <p>The <code>const</code> keyword introduces one or more bindings in the block that encloses it. It doesn’t incur the cost of a function invocation. That’s great. Even better, it puts the symbol (like <code>PI</code>) close to the value (<code>3.14159265</code>). That’s much better than what we were writing.</p> | |
| <p>We use the <code>const</code> keyword in a <em>const statement</em>. <code>const</code> statements occur inside blocks, we can’t use them when we write a fat arrow that has an expression as its body.</p> | |
| <p>It works just as we want. Instead of:</p> | |
| <pre><code>((diameter)</code> <code>=></code> <br /> <code>((PI)</code> <code>=></code> <br /> <code>diameter</code> <code>*</code> <code>PI)(3.14159265))(2)</code></pre> | |
| <p>Or:</p> | |
| <pre><code>((diameter,</code> <code>PI)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI)(2,</code> <code>3.14159265)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>We write:</p> | |
| <pre><code>((diameter)</code> <code>=></code> <code>{</code> <br /> <code>const</code> <code>PI</code> <code>=</code> <code>3.14159265;</code> <br /> <br /> <code>return</code> <code>diameter</code> <code>*</code> <code>PI</code> <br /><code>})(2)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>We can bind any expression. Functions are expressions, so we can bind helper functions:</p> | |
| <pre><code>(d)</code> <code>=></code> <code>{</code> <br /> <code>const</code> <code>calc</code> <code>=</code> <code>(diameter)</code> <code>=></code> <code>{</code> <br /> <code>const</code> <code>PI</code> <code>=</code> <code>3.14159265;</code> </pre> | |
| <pre><code> return</code> <code>diameter</code> <code>*</code> <code>PI</code> <br /> <code>};<br /></code> <br /> <code>return</code> <code>"The circumference is "</code> <code>+</code> <code>calc(d)</code> <br /><code>}</code></pre> | |
| <p>Notice <code>calc(d)</code>? This underscores what we’ve said: if we have an expression that evaluates to a function, we apply it with <code>()</code>. A name that’s bound to a function is a valid expression evaluating to a function.</p> | |
| <p>Amazing how such an important idea–naming functions–can be explained <em>en passant</em> in just a few words. That emphasizes one of the things JavaScript gets really, really right: Functions as “first class entities.” Functions are values that can be bound to names like any other value, passed as arguments, returned from other functions, and so forth.</p> | |
| <p>We can bind more than one name-value pair by separating them with commas. For readability, most people put one binding per line:</p> | |
| <pre><code>(d)</code> <code>=></code> <code>{</code> <br /> <code>const</code> <code>PI</code> <code>=</code> <code>3.14159265,</code> <br /> <code>calc</code> <code>=</code> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI;</code> </pre> | |
| <pre><code> return</code> <code>"The circumference is "</code> <code>+</code> <code>calc(d)</code> <br /><code>}</code></pre> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>nested blocks</h4> | |
| <p>Up to now, we’ve only ever seen blocks we use as the body of functions. But there are other kinds of blocks. One of the places you can find blocks is in an <code>if</code> statement. In JavaScript, an <code>if</code> statement looks like this:</p> | |
| <pre><code>(n)</code> <code>=></code> <code>{</code> <br /> <code>const</code> <code>even</code> <code>=</code> <code>(x)</code> <code>=></code> <code>{</code> <br /> <code>if</code> <code>(x</code> <code>===</code> <code>0)</code> <br /> <code>return</code> <code>true;</code> <br /> <code>else</code> <br /> <code>return</code> <code>!even(x</code> <code>-</code> <code>1);</code> <br /> <code>}</code> <br /> <code>return</code> <code>even(n)</code> <br /><code>}</code></pre> | |
| <p>And it works for fairly small numbers:</p> | |
| <pre><code>((n)</code> <code>=></code> <code>{</code> <br /> <code>const</code> <code>even</code> <code>=</code> <code>(x)</code> <code>=></code> <code>{</code> <br /> <code>if</code> <code>(x</code> <code>===</code> <code>0)<br /></code> <code>return</code> <code>true;<br /></code> <code>else<br /></code> <code>return</code> <code>!even(x</code> <code>-</code> <code>1);<br /></code> <code>}<br /></code> <code>return</code> <code>even(n)</code> <br /><code>})(13)</code> <code>//=> false</code></pre> | |
| <p>The <code>if</code> statement is a statement, not an expression (an unfortunate design choice), and its clauses are statements or blocks. So we could also write something like:</p> | |
| <pre><code>(n)</code> <code>=></code> <code>{</code> <br /> <code>const</code> <code>even</code> <code>=</code> <code>(x)</code> <code>=></code> <code>{</code> <br /> <code>if</code> <code>(x</code> <code>===</code> <code>0)</code> <br /> <code>return</code> <code>true;</code> <br /> <code>else</code> <code>{</code> <br /> <code>const</code> <code>odd</code> <code>=</code> <code>(y)</code> <code>=></code> <code>!even(y);<br /></code> <code>return</code> <code>odd(x</code> <code>-</code> <code>1);</code> <br /> <code>}</code> <br /> <code>}<br /></code> <code>return</code> <code>even(n)</code> <br /><code>}</code></pre> | |
| <p>And this also works:</p> | |
| <pre><code>((n)</code> <code>=></code> <code>{<br /></code> <code>const</code> <code>even</code> <code>=</code> <code>(x)</code> <code>=></code> <code>{<br /></code> <code>if</code> <code>(x</code> <code>===</code> <code>0)<br /></code> <code>return</code> <code>true;<br /></code> <code>else</code> <code>{<br /></code> <code>const</code> <code>odd</code> <code>=</code> <code>(y)</code> <code>=></code> <code>!even(y);<br /></code> <code>return</code> <code>odd(x</code> <code>-</code> <code>1);<br /></code> <code>}<br /></code> <code>}<br /></code> <code>return</code> <code>even(n)<br /></code> <code>})(42)</code> <code>//=> true</code></pre> | |
| <p>We’ve used a block as the <code>else</code> clause, and since it’s a block, we’ve placed a <code>const</code> statement inside it.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>const and lexical scope</h4> | |
| <p>This seems very straightforward, but alas, there are some semantics of binding names that we need to understand if we’re to place <code>const</code> anywhere we like. The first thing to ask ourselves is, what happens if we use <code>const</code>to bind two different values to the “same” name?</p> | |
| <p>Let’s back up and reconsider how closures work. What happens if we use parameters to bind two different values to the same name?</p> | |
| <p>Here’s the second formulation of our diameter function, bound to a name using an IIFE:</p> | |
| <pre><code>((diameter_fn)</code> <code>=><br /></code> <code>// ...<br />)(<br /></code> <code>((PI)</code> <code>=><br /></code> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI<br /></code> <code>)(3.14159265)</code> <code>)</code></pre> | |
| <p>It’s more than a bit convoluted, but it binds <code>((PI) => (diameter) => diameter * PI)(3.14159265)</code> to <code>diameter_fn</code> and evaluates the expression that we’ve elided. We can use any expression in there, and that expression can invoke <code>diameter_fn</code>. For example:</p> | |
| <pre><code>((diameter_fn)</code> <code>=><br /></code> <code>diameter_fn(2)</code> <code>)(<br /></code> <code>((PI)</code> <code>=><br /></code> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI<br /></code> <code>)(3.14159265)<br />)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>We know this from the section on closures, but even though <code>PI</code> is not bound when we invoke <code>diameter_fn</code> by evaluating <code>diameter_fn(2)</code>, <code>PI</code> <em>is</em> bound when we evaluated <code>(diameter) => diameter * PI</code>, and thus the expression <code>diameter * PI</code> is able to access values for <code>PI</code> and <code>diameter</code> when we evaluate <code>diameter_fn</code>.</p> | |
| <p>This is called <a href="https://en.wikipedia.org/wiki/Scope_%28computer_science%29#Lexical_scope_vs._dynamic_scope" target="_blank" rel="nofollow noopener" data-href="https://en.wikipedia.org/wiki/Scope_(computer_science)#Lexical_scope_vs._dynamic_scope">lexical scoping</a>, because we can discover where a name is bound by looking at the source code for the program. We can see that <code>PI</code> is bound in an environment surrounding <code>(diameter) => diameter * PI</code>, we don’t need to know where <code>diameter_fn</code> is invoked.</p> | |
| <p>We can test this by deliberately creating a “conflict:”</p> | |
| <pre><code>((diameter_fn)</code> <code>=><br /></code> <code>((PI)</code> <code>=><br /></code> <code>diameter_fn(2)<br /></code> <code>)(3)<br /></code> <code>)(<br /></code> <code>((PI)</code> <code>=><br /></code> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI<br /></code> <code>)(3.14159265)<br />)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>Although we have bound <code>3</code> to <code>PI</code> in the environment surrounding <code>diameter_fn(2)</code>, the value that counts is <code>3.14159265</code>, the value we bound to <code>PI</code> in the environment surrounding (diameter) ⇒ diameter * PI.</p> | |
| <p>That much we can carefully work out from the way closures work. Does <code>const</code> work the same way? Let’s find out:</p> | |
| <pre><code>((diameter_fn)</code> <code>=></code> <code>{<br /></code> <code>const</code> <code>PI</code> <code>=</code> <code>3;<br /></code> <code>return</code> <code>diameter_fn(2)<br />})(<br /></code> <code>(()</code> <code>=></code> <code>{<br /></code> <code>const</code> <code>PI</code> <code>=</code> <code>3.14159265;<br /></code> <code>return</code> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI<br /></code> <code>})()<br />)<br />//=> 6.2831853</code></pre> | |
| <p>Yes. Binding values to names with <code>const</code> works just like binding values to names with parameter invocations, it uses lexical scope.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>are consts also from a shadowy planet?</h4> | |
| <p>We just saw that values bound with <code>const</code> use lexical scope, just like values bound with parameters. They are looked up in the environment where they are declared. And we know that functions create environments. Parameters are declared when we create functions, so it makes sense that parameters are bound to environments created when we invoke functions.</p> | |
| <p>But <code>const</code> statements can appear inside blocks, and we saw that blocks can appear inside of other blocks, including function bodies. So where are <code>const</code>variables bound? In the function environment? Or in an environment corresponding to the block?</p> | |
| <p>We can test this by creating another conflict. But instead of binding two different variables to the same name in two different places, we’ll bind two different values to the same name, but one environment will be completely enclosed by the other.</p> | |
| <p>Let’s start, as above, by doing this with parameters. We’ll start with:</p> | |
| <pre><code>((PI)</code> <code>=><br /></code> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI</code> <code>)(3.14159265)</code></pre> | |
| <p>And gratuitously wrap it in another IIFE so that we can bind <code>PI</code> to something else:</p> | |
| <pre><code>((PI)</code> <code>=><br /></code> <code>((PI)</code> <code>=><br /></code> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI<br /></code> <code>)(3.14159265)<br /></code> <code>)(3)</code></pre> | |
| <p>This still evaluates to a function that calculates diameters:</p> | |
| <pre><code>((PI)</code> <code>=><br /></code> <code>((PI)</code> <code>=><br /></code> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI<br /></code> <code>)(3.14159265)<br /></code> <code>)(3)(2)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>And we can see that our <code>diameter * PI</code> expression uses the binding for <code>PI</code> in the closest parent environment. but one question: Did binding <code>3.14159265</code> to <code>PI</code> somehow change the binding in the “outer” environment? Let’s rewrite things slightly differently:</p> | |
| <pre><code>((PI)</code> <code>=></code> <code>{<br /></code> <code>((PI)</code> <code>=></code> <code>{})(3);<br /></code> <code>return</code> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI;<br /></code> <code>})(3.14159265)</code></pre> | |
| <p>Now we bind <code>3</code> to <code>PI</code> in an otherwise empty IIFE inside of our IIFE that binds <code>3.14159265</code> to <code>PI</code>. Does that binding “overwrite” the outer one? Will our function return <code>6</code> or <code>6.2831853</code>? This is a book, you’ve already scanned ahead, so you know that the answer is <strong>no</strong>, the inner binding does not overwrite the outer binding:</p> | |
| <pre><code>((PI)</code> <code>=></code> <code>{<br /></code> <code>((PI)</code> <code>=></code> <code>{})(3);<br /></code> <code>return</code> <code>(diameter)</code> <code>=></code> <code>diameter</code> <code>*</code> <code>PI;<br /></code> <code>})(3.14159265)(2)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>We say that when we bind a variable using a parameter inside another binding, the inner binding <em>shadows</em> the outer binding. It has effect inside its own scope, but does not affect the binding in the enclosing scope.</p> | |
| <p>So what about <code>const</code>. Does it work the same way?</p> | |
| <pre><code>((diameter)</code> <code>=></code> <code>{<br /></code> <code>const</code> <code>PI</code> <code>=</code> <code>3.14159265;<br /></code> <br /> <code>(()</code> <code>=></code> <code>{<br /></code> <code>const</code> <code>PI</code> <code>=</code> <code>3;<br /></code> <code>})();<br /></code> <br /> <code>return</code> <code>diameter</code> <code>*</code> <code>PI;<br /></code> <code>})(2)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>Yes, names bound with <code>const</code> shadow enclosing bindings just like parameters. But wait! There’s more!!!</p> | |
| <p>Parameters are only bound when we invoke a function. That’s why we made all these IIFEs. But <code>const</code> statements can appear inside blocks. What happens when we use a <code>const</code> inside of a block?</p> | |
| <p>We’ll need a gratuitous block. We’ve seen <code>if</code> statements, what could be more gratuitous than:</p> | |
| <pre><code>if</code> <code>(true)</code> <code>{</code> <code>// an immediately invoked block statement (IIBS)</code> <code>}</code></pre> | |
| <p>Let’s try it:</p> | |
| <pre><code>((diameter)</code> <code>=></code> <code>{<br /></code> <code>const</code> <code>PI</code> <code>=</code> <code>3;</code></pre> | |
| <pre> <code>if</code> <code>(true)</code> <code>{<br /></code> <code>const</code> <code>PI</code> <code>=</code> <code>3.14159265;</code> <br /> <code>return</code> <code>diameter</code> <code>*</code> <code>PI;<br /></code> <code>}<br /></code> <code>})(2)<br />//=> 6.2831853</code> </pre> | |
| <pre><code>((diameter)</code> <code>=></code> <code>{<br /></code> <code>const</code> <code>PI</code> <code>=</code> <code>3.14159265;<br /></code> <br /> <code>if</code> <code>(true)</code> <code>{<br /></code> <code>const</code> <code>PI</code> <code>=</code> <code>3;<br /></code> <code>}<br /></code> <code>return</code> <code>diameter</code> <code>*</code> <code>PI;<br /></code> <code>})(2)</code> <br /><code>//=> 6.2831853</code></pre> | |
| <p>Ah! <code>const</code> statements don’t just shadow values bound within the environments created by functions, they shadow values bound within environments created by blocks!</p> | |
| <p>This is enormously important. Consider the alternative: What if <code>const</code> could be declared inside of a block, but it always bound the name in the function’s scope. In that case, we’d see things like this:</p> | |
| <pre><code>((diameter)</code> <code>=></code> <code>{<br /></code> <code>const</code> <code>PI</code> <code>=</code> <code>3.14159265;<br /></code> <code>if</code> <code>(true)</code> <code>{<br /> </code> <code>const</code> <code>PI</code> <code>=</code> <code>3;<br /> </code> <code>}<br /></code> <code>return</code> <code>diameter</code> <code>*</code> <code>PI;</code> <code>})(2)</code> </pre> | |
| <pre><code>//=> would return 6 if const had function scope</code></pre> | |
| <p>If <code>const</code> always bound its value to the name defined in the function’s environment, placing a <code>const</code> statement inside of a block would merely rebind the existing name, overwriting its old contents. That would be super-confusing. And this code would “work:”</p> | |
| <pre><code>((diameter)</code> <code>=></code> <code>{<br /></code> <code>if</code> <code>(true)</code> <code>{<br /></code> <code>const</code> <code>PI</code> <code>=</code> <code>3.14159265;<br /></code> <code>}<br /></code> <code>return</code> <code>diameter</code> <code>*</code> <code>PI;<br /></code> <code>})(2)</code> <br /><code>//=> would return 6.2831853 if const had function scope</code></pre> | |
| <p>Again, confusing. Typically, we want to bind our names as close to where we need them as possible. This design rule is called the <a href="https://en.wikipedia.org/wiki/Principle_of_least_privilege" target="_blank" rel="nofollow noopener" data-href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">Principle of Least Privilege</a>, and it has both quality and security implications. Being able to bind a name inside of a block means that if the name is only needed in the block, we are not “leaking” its binding to other parts of the code that do not need to interact with it.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>rebinding</h4> | |
| <p>By default, JavaScript permits us to <em>rebind</em> new values to names bound with a parameter. For example, we can write:</p> | |
| <pre><code>const</code> <code>evenStevens</code> <code>=</code> <code>(n)</code> <code>=></code> <code>{<br /></code> <code>if</code> <code>(n</code> <code>===</code> <code>0)</code> <code>{<br /></code> <code>return</code> <code>true;<br /></code> <code>}<br /></code> <code>else</code> <code>if</code> <code>(n</code> <code>==</code> <code>1)</code> <code>{<br /></code> <code>return</code> <code>false;<br /></code> <code>}<br /></code> <code>else</code> <code>{<br /></code> <code>n</code> <code>=</code> <code>n</code> <code>-</code> <code>2;<br /></code> <code>return</code> <code>evenStevens(n);<br /></code> <code>}<br /></code> <code>}</code></pre> | |
| <pre> <code>evenStevens(42)</code> <code>//=> true</code></pre> | |
| <p>The line <code>n = n - 2;</code> <em>rebinds</em> a new value to the name <code>n</code>. Let’s try a similar thing with a name bound using <code>const</code>. We’ve already bound <code>evenStevens</code>using <code>const</code>, let’s try rebinding it:</p> | |
| <pre><code>evenStevens</code> <code>=</code> <code>(n)</code> <code>=></code> <code>{<br /></code> <code>if</code> <code>(n</code> <code>===</code> <code>0)</code> <code>{<br /></code> <code>return</code> <code>true;<br /></code> <code>}<br /></code> <code>else</code> <code>if</code> <code>(n</code> <code>==</code> <code>1)</code> <code>{<br /></code> <code>return</code> <code>false;<br /></code> <code>}<br /></code> <code>else</code> <code>{<br /></code> <code>return</code> <code>evenStevens(n</code> <code>-</code> <code>2);<br /></code> <code>}<br />}</code> <br /><code>//=> ERROR, evenStevens is read-only</code></pre> | |
| <p>JavaScript does not permit us to rebind a name that has been bound with <code>const</code>. We can <em>shadow</em> it by using <code>const</code> to declare a new binding with a new function or block scope, but we cannot rebind a name that was bound with <code>const</code> in an existing scope.</p> | |
| <p>This is valuable, as it greatly simplifies the analysis of programs to see at a glance that when something is bound with <code>const</code>, we need never worry that its value may change.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h3>Naming Functions</h3> | |
| <p>Let’s get right to it. This code does <em>not</em> name a function:</p> | |
| <pre><code>const</code> <code>repeat</code> <code>=</code> <code>(str)</code> <code>=></code> <code>str</code> <code>+</code> <code>str</code></pre> | |
| <p>It doesn’t name the function “repeat” for the same reason that <code>const answer = 42</code> doesn’t name the number <code>42</code>. This syntax binds an anonymous function to a name in an environment, but the function itself remains anonymous.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>the <code>function</code> keyword</h4> | |
| <p>JavaScript <em>does</em> have a syntax for naming a function, we use the <code>function</code>keyword. Until ECMAScript 2015 was created, <code>function</code> was the usual syntax for writing functions.</p> | |
| <p>Here’s our <code>repeat</code> function written using a “fat arrow”</p> | |
| <pre><code>(str)</code> <code>=></code> <code>str</code> <code>+</code> <code>str</code></pre> | |
| <p>And here’s (almost) the exact same function written using the <code>function</code>keyword:</p> | |
| <pre><code>function</code> <code>(str)</code> <code>{</code> <code>return</code> <code>str</code> <code>+</code> <code>str</code> <code>}</code></pre> | |
| <p>Let’s look at the obvious differences:</p> | |
| <ol> | |
| <li>We introduce a function with the <code>function</code> keyword.</li> | |
| <li>Something else we’re about to discuss is optional.</li> | |
| <li>We have arguments in parentheses, just like fat arrow functions.</li> | |
| <li>We do not have a fat arrow, we go directly to the body.</li> | |
| <li>We always use a block, we cannot write <code>function (str) str + str</code>. This means that if we want our functions to return a value, we always need to use the <code>return</code> keyword</li> | |
| </ol> | |
| <p>If we leave out the “something optional” that comes after the <code>function</code>keyword, we can translate all of the fat arrow functions that we’ve seen into <code>function</code> keyword functions, e.g.</p> | |
| <pre><code>(n)</code> <code>=></code> <code>(1.618**n</code> <code>-</code> <code>-1.618**-n)</code> <code>/</code> <code>2.236</code></pre> | |
| <p>Can be written as:</p> | |
| <pre><code>function</code> <code>(n)</code> <code>{</code> <code>return</code> <code>(1.618**n</code> <code>-</code> <code>-1.618**-n)</code> <code>/</code> <code>2.236;</code> <code>}</code></pre> | |
| <p>This still does not <em>name</em> a function, but as we noted above, functions written with the <code>function</code> keyword have an optional “something else.” Could that “something else” name a function? Yes, of course.</p> | |
| <p>Here are our example functions written with names:</p> | |
| <pre><code>const</code> <code>repeat</code> <code>=</code> <code>function</code> <code>repeat</code> <code>(str)</code> <code>{<br /></code> <code>return</code> <code>str</code> <code>+</code> <code>str;<br />};</code> </pre> | |
| <pre><code>const</code> <code>fib</code> <code>=</code> <code>function</code> <code>fib</code> <code>(n)</code> <code>{<br /></code> <code>return</code> <code>(1.618**n</code> <code>-</code> <code>-1.618**-n)</code> <code>/</code> <code>2.236;</code> <br /><code>};</code></pre> | |
| <p>Placing a name between the <code>function</code> keyword and the argument list names the function. Confusingly, the name of the function is not exactly the same thing as the name we may choose to bind to the value of the function. For example, we can write:</p> | |
| <pre><code>const</code> <code>double</code> <code>=</code> <code>function</code> <code>repeat</code> <code>(str)</code> <code>{</code> <br /> <code>return</code> <code>str</code> <code>+</code> <code>str;</code> <br /><code>}</code></pre> | |
| <p>In this expression, <code>double</code> is the name in the environment, but <code>repeat</code> is the function’s actual name. This is a <em>named function expression</em>. That may seem confusing, but think of the binding names as properties of the environment, not of the function. While the name of the function is a property of the function, not of the environment.</p> | |
| <p>And indeed the name <em>is</em> a property:</p> | |
| <pre><code>double.name</code> <code>//=> 'repeat'</code></pre> | |
| <p>In this book we are not examining JavaScript’s tooling such as debuggers baked into browsers, but we will note that when you are navigating call stacks in all modern tools, the function’s binding name is ignored but its actual name is displayed, so naming functions is very useful even if they don’t get a formal binding, e.g.</p> | |
| <pre><code>someBackboneView.on('click',</code> <code>function</code> <code>clickHandler</code> <code>()</code> <code>{</code> <code>//...</code> <code>});</code></pre> | |
| <p>Now, the function’s actual name has no effect on the environment in which it is used. To whit:</p> | |
| <pre><code>const</code> <code>bindingName</code> <code>=</code> <code>function</code> <code>actualName</code> <code>()</code> <code>{</code> <code>//...</code> <code>};</code> <br /><code>bindingName</code> <br /><code>//=> [Function: actualName]</code> </pre> | |
| <pre><code>actualName</code> <br /><code>//=> ReferenceError: actualName is not defined</code></pre> | |
| <p>So “actualName” isn’t bound in the environment where we use the named function expression. Is it bound anywhere else? Yes it is. Here’s a function that determines whether a positive integer is even or not. We’ll use it in an IIFE so that we don’t have to bind it to a name with <code>const</code>:</p> | |
| <pre><code>(function</code> <code>even</code> <code>(n)</code> <code>{<br /></code> <code>if</code> <code>(n</code> <code>===</code> <code>0)</code> <code>{<br /></code> <code>return</code> <code>true<br /></code> <code>}<br /></code> <code>else</code> <code>return</code> <code>!even(n</code> <code>-</code> <code>1)<br />})(5)</code> <br /><code>//=> false</code> </pre> | |
| <pre><code>(function</code> <code>even</code> <code>(n)</code> <code>{<br /></code> <code>if</code> <code>(n</code> <code>===</code> <code>0)</code> <code>{<br /></code> <code>return</code> <code>true<br /></code> <code>}<br /></code> <code>else</code> <code>return</code> <code>!even(n</code> <code>-</code> <code>1)</code> <br /><code>})(2)</code> <br /><code>//=> true</code></pre> | |
| <p>Clearly, the name <code>even</code> is bound to the function <em>within the function’s body</em>. Is it bound to the function outside of the function’s body?</p> | |
| <pre><code>even</code> <code>//=> Can't find variable: even</code></pre> | |
| <p><code>even</code> is bound within the function itself, but not outside it. This is useful for making recursive functions as we see above, and it speaks to the principle of least privilege: If you don’t <em>need</em> to name it anywhere else, you needn’t.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>function declarations</h4> | |
| <p>There is another syntax for naming and/or defining a function. It’s called a <em>function declaration statement</em>, and it looks a lot like a named function expression, only we use it as a statement:</p> | |
| <pre><code>function</code> <code>someName</code> <code>()</code> <code>{</code> <code>// ...</code> <code>}</code></pre> | |
| <p>This behaves a <em>little</em> like:</p> | |
| <pre><code>const</code> <code>someName</code> <code>=</code> <code>function</code> <code>someName</code> <code>()</code> <code>{</code> <code>// ...</code> <code>}</code></pre> | |
| <p>In that it binds a name in the environment to a named function. However, there are two important differences. First, function declarations are <em>hoisted</em> to the top of the function in which they occur.</p> | |
| <p>Consider this example where we try to use the variable <code>fizzbuzz</code> as a function before we bind a function to it with <code>const</code>:</p> | |
| <pre><code>(function</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>fizzbuzz();<br /></code> <br /> <code>const</code> <code>fizzbuzz</code> <code>=</code> <code>function</code> <code>fizzbuzz</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>"Fizz"</code> <code>+</code> <code>"Buzz";<br /></code> <code>}</code> <br /><code>})()</code> </pre> | |
| <pre><code>//=> undefined is not a function (evaluating 'fizzbuzz()')</code></pre> | |
| <p>We haven’t actually bound a function to the name <code>fizzbuzz</code> before we try to use it, so we get an error. But a function <em>declaration</em> works differently:</p> | |
| <pre><code>(function</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>fizzbuzz();<br /></code> <br /> <code>function</code> <code>fizzbuzz</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>"Fizz"</code> <code>+</code> <code>"Buzz";<br /></code> <code>}</code> </pre> | |
| <pre><code>})()</code> <br /><code>//=> 'FizzBuzz'</code></pre> | |
| <p>Although <code>fizzbuzz</code> is declared later in the function, JavaScript behaves as if we’d written:</p> | |
| <pre><code>(function</code> <code>()</code> <code>{<br /></code> <code>const</code> <code>fizzbuzz</code> <code>=</code> <code>function</code> <code>fizzbuzz</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>"Fizz"</code> <code>+</code> <code>"Buzz";<br /></code> <code>}</code> <br /> <code>return</code> <code>fizzbuzz();</code> <br /><code>})()</code></pre> | |
| <p>The definition of the <code>fizzbuzz</code> is “hoisted” to the top of its enclosing scope (an IIFE in this case). This behaviour is intentional on the part of JavaScript’s design to facilitate a certain style of programming where you put the main logic up front, and the “helper functions” at the bottom. It is not necessary to declare functions in this way in JavaScript, but understanding the syntax and its behaviour (especially the way it differs from <code>const</code>) is essential for working with production code.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>function declaration caveats</h4> | |
| <p>Function declarations are formally only supposed to be made at what we might call the “top level” of a function. Although some JavaScript environments permit the following code, this example is technically illegal and definitely a bad idea:</p> | |
| <pre><code>(function</code> <code>(camelCase)</code> <code>{<br /></code> <code>return</code> <code>fizzbuzz();<br /></code> <br /> <code>if</code> <code>(camelCase)</code> <code>{<br /></code> <code>function</code> <code>fizzbuzz</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>"Fizz"</code> <code>+</code> <code>"Buzz";<br /></code> <code>}<br /></code> <code>}<br /></code> <code>else</code> <code>{<br /></code> <code>function</code> <code>fizzbuzz</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>"Fizz"</code> <code>+</code> <code>"Buzz";<br /></code> <code>}<br /></code> <code>}</code> <br /><code>})(true)</code> </pre> | |
| <pre><code>//=> 'FizzBuzz'? Or ERROR: Can't find variable: fizzbuzz?</code></pre> | |
| <p>Function declarations are not supposed to occur inside of blocks. The big trouble with expressions like this is that they may work just fine in your test environment but work a different way in production. Or it may work one way today and a different way when the JavaScript engine is updated, say with a new optimization.</p> | |
| <p>Another caveat is that a function declaration cannot exist inside of <em>any</em>expression, otherwise it’s a function expression. So this is a function declaration:</p> | |
| <pre><code>function</code> <code>trueDat</code> <code>()</code> <code>{</code> <code>return</code> <code>true</code> <code>}</code></pre> | |
| <p>But this is not:</p> | |
| <pre><code>(function</code> <code>trueDat</code> <code>()</code> <code>{</code> <code>return</code> <code>true</code> <code>})</code></pre> | |
| <p>The parentheses make this an expression, not a function declaration.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h3>Combinators and Function Decorators</h3> | |
| <h4>higher-order functions</h4> | |
| <p>As we’ve seen, JavaScript functions take values as arguments and return values. JavaScript functions are values, so JavaScript functions can take functions as arguments, return functions, or both. Generally speaking, a function that either takes functions as arguments, or returns a function, or both, is referred to as a “higher-order” function.</p> | |
| <p>Here’s a very simple higher-order function that takes a function as an argument:</p> | |
| <pre><code>const</code> <code>repeat</code> <code>=</code> <code>(num,</code> <code>fn)</code> <code>=><br /></code> <code>(num</code> <code>></code> <code>0)<br /></code> <code>?</code> <code>(repeat(num</code> <code>-</code> <code>1,</code> <code>fn),</code> <code>fn(num))<br /></code> <code>:</code> <code>undefined</code></pre> | |
| <pre><code>repeat(3,</code> <code>function</code> <code>(n)</code> <code>{<br /></code> <code>console.log(`Hello ${n}`)<br />})</code> </pre> | |
| <pre><code>//=></code> <code>'Hello 1'</code> <code>'Hello 2'</code> <code>'Hello 3'</code> <code>undefined</code></pre> | |
| <p>Higher-order functions dominate <em>JavaScript Allongé</em>. But before we go on, we’ll talk about some specific types of higher-order functions.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>combinators</h4> | |
| <p>The word “combinator” has a precise technical meaning in mathematics:</p> | |
| <blockquote>“A combinator is a higher-order function that uses only function application and earlier defined combinators to define a result from its arguments.”–<a title="Combinatory Logic" href="https://en.wikipedia.org/wiki/Combinatory_logic" target="_blank" rel="nofollow noopener" data-href="https://en.wikipedia.org/wiki/Combinatory_logic">Wikipedia</a></blockquote> | |
| <p>If we were learning Combinatorial Logic, we’d start with the most basic combinators like <code>S</code>, <code>K</code>, and <code>I</code>, and work up from there to practical combinators. We’d learn that the fundamental combinators are named after birds following the example of Raymond Smullyan’s famous book <a href="http://www.amazon.com/gp/product/B00A1P096Y/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=B00A1P096Y&linkCode=as2&tag=raganwald001-20" target="_blank" rel="nofollow noopener" data-href="http://www.amazon.com/gp/product/B00A1P096Y/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=B00A1P096Y&linkCode=as2&tag=raganwald001-20">To Mock a Mockingbird</a>.</p> | |
| <p>In this book, we will be using a looser definition of “combinator:” Higher-order pure functions that take only functions as arguments and return a function. We won’t be strict about using only previously defined combinators in their construction.</p> | |
| <p>Let’s start with a useful combinator: Most programmers call it <em>Compose</em>, although the logicians call it the B combinator or “Bluebird.” Here is the typical programming implementation:</p> | |
| <pre><code>const</code> <code>compose</code> <code>=</code> <code>(a,</code> <code>b)</code> <code>=><br /></code> <code>(c)</code> <code>=></code> <code>a(b(c))</code></pre> | |
| <p>Let’s say we have:</p> | |
| <pre><code>const</code> <code>addOne</code> <code>=</code> <code>(number)</code> <code>=></code> <code>number</code> <code>+</code> <code>1;</code> <br /><code>const</code> <code>doubleOf</code> <code>=</code> <code>(number)</code> <code>=></code> <code>number</code> <code>*</code> <code>2;</code></pre> | |
| <p>With <code>compose</code>, anywhere you would write</p> | |
| <pre><code>const</code> <code>doubleOfAddOne</code> <code>=</code> <code>(number)</code> <code>=></code> <code>doubleOf(addOne(number));</code></pre> | |
| <p>You could also write:</p> | |
| <p><code>const</code> <code>doubleOfAddOne</code> <code>=</code> <code>compose(doubleOf,</code> <code>addOne);</code></p> | |
| <p>This is, of course, just one example of many. While some programmers believe “There Should Only Be One Way To Do It,” having combinators available as well as explicitly writing things out with lots of symbols and keywords has some advantages when used judiciously.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>a balanced statement about combinators</h4> | |
| <p>Code that uses a lot of combinators tends to name the verbs and adverbs (like <code>doubleOf</code>, <code>addOne</code>, and <code>compose</code>) while avoiding language keywords and the names of nouns (like <code>number</code>). So one perspective is that combinators are useful when you want to emphasize what you’re doing and how it fits together, and more explicit code is useful when you want to emphasize what you’re working with.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>function decorators</h4> | |
| <p>A <em>function decorator</em> is a higher-order function that takes one function as an argument, returns another function, and the returned function is a variation of the argument function. Here’s a ridiculously simple decorator:</p> | |
| <pre><code>const</code> <code>not</code> <code>=</code> <code>(fn)</code> <code>=></code> <code>(x)</code> <code>=></code> <code>!fn(x)</code></pre> | |
| <p>So instead of writing <code>!someFunction(42)</code>, we can write <code>not(someFunction)(42)</code>. Hardly progress. But like <code>compose</code>, we could write either:</p> | |
| <pre><code>const</code> <code>something</code> <code>=</code> <code>(x)</code> <code>=></code> <code>x</code> <code>!=</code> <code>null;</code></pre> | |
| <p>And elsewhere, write:</p> | |
| <pre><code>const</code> <code>nothing</code> <code>=</code> <code>(x)</code> <code>=></code> <code>!something(x);</code></pre> | |
| <p>Or we could write:</p> | |
| <pre><code>const</code> <code>nothing</code> <code>=</code> <code>not(something);</code></pre> | |
| <p><code>not</code> is a function decorator because it modifies a function while remaining strongly related to the original function’s semantics. Function decorators aren’t strict about being pure functions, so there’s more latitude for making decorators than combinators.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h3>Building Blocks</h3> | |
| <p>When you look at functions within functions in JavaScript, there’s a bit of a “spaghetti code” look to it. The strength of JavaScript is that you can do anything. The weakness is that you will. There are ifs, fors, returns, everything thrown higgledy piggledy together. Although you needn’t restrict yourself to a small number of simple patterns, it can be helpful to understand the patterns so that you can structure your code around some basic building blocks.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>composition</h4> | |
| <p>One of the most basic of these building blocks is <em>composition</em>:</p> | |
| <pre><code>const</code> <code>cookAndEat</code> <code>=</code> <code>(food)</code> <code>=></code> <code>eat(cook(food));</code></pre> | |
| <p>It’s really that simple: Whenever you are chaining two or more functions together, you’re composing them. You can compose them with explicit JavaScript code as we’ve just done. You can also generalize composition with the B Combinator or “compose” that we saw in Combinators and Decorators:</p> | |
| <pre><code>const</code> <code>compose</code> <code>=</code> <code>(a,</code> <code>b)</code> <code>=></code> <code>(c)</code> <code>=></code> <code>a(b(c));</code> <br /><code>const</code> <code>cookAndEat</code> <code>=</code> <code>compose(eat,</code> <code>cook);</code></pre> | |
| <p>If that was all there was to it, composition wouldn’t matter much. But like many patterns, using it when it applies is only 20% of the benefit. The other 80% comes from organizing your code such that you can use it: Writing functions that can be composed in various ways.</p> | |
| <p>Of course, you needn’t use combinators to implement either of these ideas, you can use if statements. But <code>once</code> and <code>maybe</code> compose, so you can chain them together as you see fit:</p> | |
| <pre><code>const</code> <code>actuallyTransfer =</code> <code>(from,</code> <code>to,</code> <code>amount)</code> <code>=></code> <code>// do something</code> <code>const</code> <code>invokeTransfer</code> <code>=</code> <code>once(maybe(actuallyTransfer(...)));</code></pre> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>partial application</h4> | |
| <p>Another basic building block is <em>partial application</em>. When a function takes multiple arguments, we “apply” the function to the arguments by evaluating it with all of the arguments, producing a value. But what if we only supply some of the arguments? In that case, we can’t get the final value, but we can get a function that represents <em>part</em> of our application.</p> | |
| <p>Code is easier than words for this. The <a href="http://underscorejs.org/" target="_blank" rel="nofollow noopener" data-href="http://underscorejs.org">Underscore</a> library provides a higher-order function called <em>map</em>. It applies another function to each element of an array, like this:</p> | |
| <pre><code>_.map([1,</code> <code>2,</code> <code>3],</code> <code>(n)</code> <code>=></code> <code>n</code> <code>*</code> <code>n)</code> <code>//=> [1, 4, 9]</code></pre> | |
| <p>We don’t want to fool around writing <code>_.</code>, so we can use it by writing:</p> | |
| <p><code>const</code> <code>map</code> <code>=</code> <code>_.map;</code></p> | |
| <p>This code implements a partial application of the map function by applying the function <code>(n) => n * n</code> as its second argument:</p> | |
| <pre><code>const</code> <code>squareAll</code> <code>=</code> <code>(array)</code> <code>=></code> <code>map(array,</code> <code>(n)</code> <code>=></code> <code>n</code> <code>*</code> <code>n);</code></pre> | |
| <p>The resulting function–<code>squareAll</code>–is still the map function, it’s just that we’ve applied one of its two arguments already. <code>squareAll</code> is nice, but why write one function every time we want to partially apply a function to a map? We can abstract this one level higher. <code>mapWith</code> takes any function as an argument and returns a partially applied map function.</p> | |
| <pre><code>const</code> <code>mapWith</code> <code>=</code> <code>(fn)</code> <code>=></code> <br /> <code>(array)</code> <code>=></code> <code>map(array,</code> <code>fn);</code> </pre> | |
| <pre><code>const</code> <code>squareAll</code> <code>=</code> <code>mapWith((n)</code> <code>=></code> <code>n</code> <code>*</code> <code>n);</code> </pre> | |
| <pre><code>squareAll([1,</code> <code>2,</code> <code>3])</code> <code>//=> [1, 4, 9]</code></pre> | |
| <p>The important thing to see is that partial application is orthogonal to composition, and that they both work together nicely:</p> | |
| <pre><code>const</code> <code>safeSquareAll</code> <code>=</code> <code>mapWith(maybe((n)</code> <code>=></code> <code>n</code> <code>*</code> <code>n));</code> </pre> | |
| <pre><code>safeSquareAll([1,</code> <code>null,</code> <code>2,</code> <code>3])</code> <code>//=> [1, null, 4, 9]</code></pre> | |
| <p>We generalized composition with the <code>compose</code> combinator.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h3>Magic Names</h3> | |
| <p>When a function is applied to arguments (or “called”), JavaScript binds the values of arguments to the function’s argument names in an environment created for the function’s execution. What we haven’t discussed so far is that JavaScript also binds values to some “magic” names in addition to any you put in the argument list.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>the function keyword</h4> | |
| <p>There are two separate rules for these “magic” names, one for when you invoke a function using the <code>function</code> keyword, and another for functions defined with “fat arrows.” We’ll begin with how things work for functions defined with the <code>function</code> keyword.</p> | |
| <p>The first magic name is <code>this</code>, and it is bound to something called the function’s context. We will explore <code>this</code> in more detail when we start discussing objects and classes <em>[editor: not in this article, but in the book and maybe in a future excerpt]</em>. The second magic name is very interesting, it’s called <code>arguments</code>, and the most interesting thing about it is that it contains a list of arguments passed to a function:</p> | |
| <pre><code>const</code> <code>plus</code> <code>=</code> <code>function</code> <code>(a,</code> <code>b)</code> <code>{</code> <br /> <code>return</code> <code>arguments[0]</code> <code>+</code> <code>arguments[1];</code> <br /><code>}</code> </pre> | |
| <pre><code>plus(2,3)</code> <br /><code>//=> 5</code></pre> | |
| <p>Although <code>arguments</code> looks like an array, it isn’t an array: It’s more like an object that happens to bind some values to properties with names that look like integers starting with zero:</p> | |
| <pre><code>const</code> <code>args</code> <code>=</code> <code>function</code> <code>(a,</code> <code>b)</code> <code>{<br /></code> <code>return</code> <code>arguments;</code> <br /><code>}</code> </pre> | |
| <pre><code>args(2,3)</code> <br /><code>//=> { '0': 2, '1': 3 }</code></pre> | |
| <p><code>arguments</code> always contains all of the arguments passed to a function, regardless of how many are declared. Therefore, we can write <code>plus</code> like this:</p> | |
| <pre><code>const</code> <code>plus</code> <code>=</code> <code>function</code> <code>()</code> <code>{</code> <code>return</code> <code>arguments[0]</code> <code>+</code> <code>arguments[1];</code> <code>}</code> </pre> | |
| <pre><code>plus(2,3)</code> <br /><code>//=> 5</code></pre> | |
| <p>When discussing objects, we’ll discuss properties in more depth. Here’s something interesting about <code>arguments</code>:</p> | |
| <pre><code>const</code> <code>howMany</code> <code>=</code> <code>function</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>arguments['length'];</code> <br /><code>}</code> </pre> | |
| <pre><code>howMany()</code> </pre> | |
| <pre><code>//=> 0</code> </pre> | |
| <pre><code>howMany('hello')</code> <br /><code>//=> 1</code> </pre> | |
| <pre><code>howMany('sharks',</code> <code>'are',</code> <code>'apex',</code> <code>'predators')</code> <br /><code>//=> 4</code></pre> | |
| <p>The most common use of the <code>arguments</code> binding is to build functions that can take a variable number of arguments.</p> | |
| </div> | |
| </div> | |
| </section> | |
| <section> | |
| <div><hr /></div> | |
| <div> | |
| <div> | |
| <h4>magic names and fat arrows</h4> | |
| <p>The magic names <code>this</code> and <code>arguments</code> have a different behaviour when you invoke a function that was defined with a fat arrow: Instead of being bound when the function is invoked, the fat arrow function always acquires the bindings for <code>this</code> and <code>arguments</code> from its enclosing scope, just like any other binding.</p> | |
| <p>For example, when this expression’s inner function is defined with <code>function</code>, <code>arguments[0]</code> refers to its only argument, <code>"inner"</code>:</p> | |
| <pre><code>(function</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>(function</code> <code>()</code> <code>{</code> <code>return</code> <code>arguments[0];</code> <code>})('inner');</code> <br /><code>})('outer')</code> </pre> | |
| <pre><code>//=> "inner"</code></pre> | |
| <p>But if we use a fat arrow, <code>arguments</code> will be defined in the outer environment, the one defined with <code>function</code>. And thus <code>arguments[0]</code> will refer to <code>"outer"</code>, not to <code>"inner"</code>:</p> | |
| <pre><code>(function</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>(()</code> <code>=></code> <code>arguments[0])('inner');</code> <br /><code>})('outer')</code> </pre> | |
| <pre><code>//=> "outer"</code></pre> | |
| <p>Although it seems quixotic for the two syntaxes to have different semantics, it makes sense when you consider the design goal: Fat arrow functions are designed to be very lightweight and are often used with constructs like mapping or callbacks to emulate syntax.</p> | |
| <p>To give a contrived example, this function takes a number and returns an array representing a row in a hypothetical multiplication table. It uses <code>mapWith</code>, which we discussed in <a href="https://medium.com/better-programming/an-intro-to-javascript-for-experienced-programmers-who-could-use-a-strong-dose-of-fundamentals-31535030616b#buildingblocks" data-href="#buildingblocks">Building Blocks</a>.<a href="https://medium.com/better-programming/an-intro-to-javascript-for-experienced-programmers-who-could-use-a-strong-dose-of-fundamentals-31535030616b#fn-mapWith" rel="footnote" data-href="#fn-mapWith">24</a> We’ll use <code>arguments</code> just to show the difference between using a fat arrow and the function keyword:</p> | |
| <pre><code>const</code> <code>row</code> <code>=</code> <code>function</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>mapWith((column)</code> <code>=></code> <code>column</code> <code>*</code> <code>arguments[0])(<br /></code> <code>[1,</code> <code>2,</code> <code>3,</code> <code>4,</code> <code>5,</code> <code>6,</code> <code>7,</code> <code>8,</code> <code>9,</code> <code>10,</code> <code>11,</code> <code>12]<br /></code> <code>)</code> <br /><code>}</code> </pre> | |
| <pre><code>row(3)</code> </pre> | |
| <pre><code>//=> [3,6,9,12,15,18,21,24,27,30,33,36</code></pre> | |
| <p>This works just fine, because <code>arguments[0]</code> refers to the <code>3</code> we passed to the function <code>row</code>. Our “fat arrow” function <code>(column) => column * arguments[0]</code>doesn’t bind <code>arguments</code> when it’s invoked. But if we rewrite <code>row</code>to use the <code>function</code> keyword, it stops working:</p> | |
| <pre><code>const</code> <code>row</code> <code>=</code> <code>function</code> <code>()</code> <code>{<br /></code> <code>return</code> <code>mapWith(function</code> <code>(column)</code> <code>{</code> <code>return</code> <code>column</code> <code>*</code> <code>arguments[0]</code> <code>})(<br /></code> <code>[1,</code> <code>2,</code> <code>3,</code> <code>4,</code> <code>5,</code> <code>6,</code> <code>7,</code> <code>8,</code> <code>9,</code> <code>10,</code> <code>11,</code> <code>12]<br /></code> <code>)</code> <code>}</code> </pre> | |
| <pre><code>row(3)</code> </pre> | |
| <pre><code>//=> [1,4,9,16,25,36,49,64,81,100,121,144]</code></pre> | |
| <p>Now our inner function binds <code>arguments[0]</code> every time it is invoked, so we get the same result as if we’d written <code>function (column) { return column * column }</code>.</p> | |
| <p>Although this example is clearly unrealistic, there is a general design principle that deserves attention. Sometimes, a function is meant to be used as a Big-F function. It has a name, it is called by different pieces of code, it’s a first-class entity in the code.</p> | |
| <p>But sometimes, a function is a small-f function. It’s a simple representation of an expression to be computed. In our example above, <code>row</code> is a Big-F function, but <code>(column) => column * arguments[0]</code> is a small-f function, it exists just to give <code>mapWith</code> something to apply.</p> | |
| <p>Having magic variables apply to Big-F functions but not to small-f functions makes it much easier to use small-f functions as syntax, treating them as expressions or blocks that can be passed to functions like <code>mapWith</code>.</p> | |
| </div> | |
| </div> | |
| </section> | |
| </div> | |
| <footer> | |
| </footer> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment