sane.tex

\documentclass[11pt,letter]{book}

\addtolength{\oddsidemargin}{-.875in}
\addtolength{\evensidemargin}{-.875in}
\addtolength{\textwidth}{1.75in}
\addtolength{\topmargin}{-.875in}
\addtolength{\textheight}{1.75in}

\usepackage[pdftex]{graphicx}
\usepackage[svgnames]{xcolor}
\usepackage{tipa}

\begin{document}
    \frontmatter

    \begin{titlepage}
        \begin{center}
            { \huge \bfseries Writing Sane JavaScript}\\[0.4cm]
            \textsc{\Large A Comprehensive Introduction}\\[0.5cm]
            \textsc{Wyatt Allen}\\
            \vspace{1.2cm}
            \includegraphics[width=14cm]{socrates-hemlock}
            \vfill
        \end{center}
    \end{titlepage}
    
    \tableofcontents 
    
    \chapter{Preface}
    \begin{quote}
        \emph{
            ... An interesting mix ... capable of such beautiful dreams and such horrible 
            nightmares.
        }
    \end{quote}
    \begin{flushright}
        --- Carl Sagan, \emph{Contact}
    \end{flushright}
    \vspace{1.2cm}
    
    \begin{quote}
        \emph{
            More good code has been written in languages denounced as bad than in languages 
            proclaimed wonderful --- much more.
        }
    \end{quote}
    \begin{flushright}
        --- Bjarne Stroustrup, \emph{The Design and Evolution of C++}
    \end{flushright}
    \vspace{1.2cm}
    
    JavaScript is a truly remarkable language. It is ubiquitous: every computer with a browser 
    installed comes with a full runtime. It's uncommonly powerful: its dynamic nature is more 
    flexible than nearly any enterprise language, yet is used to do more and more amazing things.
    It's unstoppable: since its halfhearted genesis in 1995 it's never slowed its growing 
    popularity.
    
    Moreover, JavaScript is simultaneously beautiful and deeply flawed. The above quote from Carl 
    Sagan frequently visits my thoughts as I work on code, although it was originally written about 
    an alien being musing on the human race. There's no shortage of JavaScript code which is truly 
    beautiful and elegant, frequently leaving the programmer with the impression of that 
    ever-indefinable language quality: \emph{expressiveness}.
    
    But much more frequently, JavaScript will leave the programmer with a strong, sour impression of 
    a desperate mess. Unreadable, unreliable, buggy and just plain bad code is rampant and difficult 
    for the professional programmer to avoid encountering (or even to avoid writing, sometimes).
    
    Bad JavaScript code doesn't necessarily mean bad programmers. It's a product of haphazard 
    language design. For all of JavaScript's flexibility and power it can sometimes be maddeningly 
    inconsistent and idiosyncratic, especially to the beginner. The aim of this book is to lend you, 
    the reader complete knowledge of this unusual and rewarding language in order to overcome its 
    obstacles. To borrow from Sagan --- and wax just a bit starry-eyed --- the aim of this 
    book is to prevent the horrible nightmares, and promote the beautiful dreams.
    
    \section*{Pedagogy}
    Learning to master JavaScript is an unusual challenge when compared to the task of learning 
    other programming languages. No small part of this challenge is the fact that it's a very easy 
    language to pick up and start using in a basic way without having formally learned it. Just 
    about any programmer with an acquaintance with the C family of languages could hack together a 
    functioning event handler or popup in a webpage by trial and error or a handful of Google 
    searches.
    
    Because JavaScript is so easy to mess with, and is often used as a afterthought in webpage 
    design, many treat it like a toy language and percieve formally learing it to be overkill. 
    Unstoppably, however, JavaScript's role in the web has become more and more central. Scripts 
    have grown to be complex and archetected -- no longer simple, shallow event handlers but real, 
    multi-tier applications. The casual knowledge a programmer may gain from simple script hacking
    becomes insufficient for constructing these new, complex, engineered systems.
    
    This book was written to give you, the reader a proper, formal understanding of this capable 
    language. For this reason, we do not begin with the easy aspects of the language; we will start 
    by delving into the language's hard parts. It's not overkill. And at no point in this book will 
    we treat JavaScript as a toy language. 
    
    Many other JavaScript books will begin with the easier, more casual aspects of the language, 
    forcing readers to make a paradigm-shift partway through before they can really, formally learn 
    it. Other books focus exclusively on the ``good parts'' of the language, advising readers to 
    avoid using (or even considering) the poorly-designed parts which can cause trouble. Still other 
    books are dry and meticulous tomes which, while useful reference volumes, afford little to the 
    learner.
    
    In this book, we will make an unflinching, complete tour through JavaScript --- from start to 
    finish. After reading, you, the reader will be able to say that you know or grok the language, 
    warts and all. Moreover, the power is given to you the reader throughout these chapters to judge 
    the language. I will always endeavor to advise you on the common snags, but, as a programmer, 
    your judgement is respected and you choose what to make of it all.
    
    \section*{Who is this Book For?}
    As stated above, in this book, the power is given to you the reader \emph{as a programmer}. 
    Consequently, you will need to be able to program. This is not an introduction to programming 
    via JavaScript, but a comprehensive introduction to JavaScript programming. No prior 
    JavaScript knowledge will be assumed.
    
    As we shall see in JavaScript's history, its language design is influenced by C, Java and 
    (remarkably) Self. If the reader is acquainted with any of these, it will be a great help. At 
    least some understanding of Object-Oriented Programming (OOP) will be requisite, although 
    JavaScript may force you to un-learn some of OOP's traditional forms. Acquaintance with 
    Functional Progamming (FP) will be helpful for understanding much of JavaScript, but is not 
    necessary.
    
    \chapter{Introduction}
    
    \section*{History}
    An essential part of understanding JavaScript and its significance is its unusual history.
    
    
    
    
    
    
    
    
    
    
    
    TODO: Title, History, Significance, Beauty, State, How to read
    
    \mainmatter
    
    \part{The Language}
    \chapter{The Type System}
    
    \section{Overview}
    The first hurdle in mastering JavaScript is a complete understanding of the type system. In this 
    chapter we will have a first look at each of the fundamental datatypes in JavaScript. We examine 
    the type system before presenting any code examples, so this chapter may seem a little dry. Let 
    the reader be ensured, however, that this approach is to provide a rich context for when we 
    finally do get to code.
    
    JavaScript has a unique type system. In many ways it is Spartan. In many other ways 
    it is rich and expressive. In many, many other ways it is inconsistent and treacherous.
    Throughout this book, you will be introduced to the type system from each of these three 
    angles.
    
    If you, the reader, gain a complete understanding of these types, it will either result 
    in true enjoyment of a unique and powerful system, or well-informed hatred of a tangled 
    mess. Read on to find out which it will be.
    
    \section{Datatypes at a Fundamental Level}
    At a fundamental level JavaScript has four basic datatypes. There are three primitive 
    types which should be familiar to you as a programmer: \texttt{boolean}, \texttt{number} 
    and \texttt{string}. The fourth datatype is \texttt{object}, which may be thought of as a 
    composite type. The three primitives will behave largely in a similar fashion to what you're 
    used to in other languages, but some of \texttt{object}'s nuances may be surprising.
    
    Although we say there are only three primitive datatypes, JavaScript technically defines two 
    more: \texttt{null} and \texttt{undefined}. \texttt{null} will probably look familiar to you 
    from most any object-oriented language. \texttt{undefined} might be new to you. We'll explore 
    these types in greater detail (and see why they're very different from the other primitives) 
    once we've dug deeper into the type system. For now, just put them on your radar.
    
    It's important to note that the line between primitive and object is not so clearly defined
    in JavaScript as it is in other languages. You'll find that nearly any value in JavaScript can
    \emph{behave} like an object while remaining primitive. Some people interpret this to mean that
    \emph{every value} in JavaScript is an object in disguise, but this is not the truth. We'll look 
    at objects very closely soon enough.
    
    \subsection{The \texttt{boolean} Datatype}
    If we restrict ourselves to the fundamentals of the type system, the \texttt{boolean} 
    datatype is as simple as can be. The ECMAScript standard explains it in a single sentence:
    
    \begin{quote}
        The Boolean type represents a logical entity having two values, called \textbf{true}
        and \textbf{false}.
    \end{quote}
    
    In practice, \texttt{true} and \texttt{false} are keywords which statically refer to the two 
    possible boolean values (just as you find in most programming languages). These are considered 
    ``Boolean Literals.''
    
    \subsection{The \texttt{number} Datatype}
    In JavaScript, there is no distinction between integral and floating-point numbers. Instead, 
    we're given a single, unified type: \texttt{number}.
    
    A number is stored as a signed 64-bit float according to the IEEE 754 standard. This means, 
    under the covers, the numbers you deal with in JavaScript have the same encoding constraints as 
    double-precision floats in Java or C.
    
    It is worth noting that the simplicity you get by having a unified type for numbers comes at 
    a cost of space-efficiency, performance and type-safety. On the other hand this will make 
    some of your code cleaner because you no-longer need to coerce integers to floats or 
    worry about loss of precision in mixed-mode division. In general, we will find that 
    JavaScript tends to sacrifice efficiency/performance/safety in small ways in order to gain 
    in simplicity.
    
    A JavaScript number can be as large as $\pm 1.7976931348623157 \times 10^{308}$ or as small as
    $\pm 5 \times 10^{-324}$. The range of integral values which can be stored in a JavaScript 
    \texttt{number} is $\pm 2^{53}$.
    
    Numbers can be declared with number literals. Number literals are usually decimal (base-10) but 
    can also be hexadecimal (base-16) using the traditional \texttt{0x} prefix. (In some 
    implementations octal (base-8) number literals are allowed when the number is prefixed with a 
    leading zero, although this is not standard.)
    
    \begin{verbatim}
        7
    
        42
        
        7.62
        
        0xf0
    
        0xff63ba
    \end{verbatim}
    
    Number literals can also be written in exponential notation by suffixing a lower or upper-case 
    letter ``e'' followed by a positive or negative radix. 
    
    \begin{verbatim}
    6.022141e23
    
    6.6260695729E-34
    \end{verbatim}
    
    Negative number literals can be made in the usual way, by prefixing the literal with a minus 
    sign. However, this isn't actually part of the literal itself, but is an application of the 
    unary negation operator to the literal.
    
    \begin{verbatim}
    -532
    \end{verbatim}
    
    \subsection{The \texttt{string} Datatype}
    JavaScript provides \texttt{string} as a primitive type for dealing with text. All strings in 
    JavaScript are encoded using either UTF-16 or UCS-2. (UCS-2 is a text encoding form which is 
    extremely similar to UTF-16, but doesn't understand surrogate pair code points, which is almost
    never a problem.)
    
    You just learned that JavaScript unifies integers and floats under numbers at a cost of 
    performance and for the sake of simplicity. With strings, JavaScript makes a similar 
    simplification: there is no \texttt{char} type. That is to say: in JavaScript any single 
    character is of type \texttt{string} with a string-length of 1. As a result, when dealing with  
    text, the \texttt{string} datatype is the only datatype you need.
    
    String literals must be delimited by matching single or double quotes. In other words, strings 
    may be delimited by either a matching start and end single quote or a matching start and end 
    double quote but not mixed. The quote type which is not used to delimit may be used within the 
    string literal without escaping.
    
    \begin{verbatim}
    "Hello, world."
    
    'Hello, world with single quotes.'
    
    "This apostrophe needn't be escaped."
    
    'Double "quotes inside single" quotes.'
    \end{verbatim}
    
    JavaScript \texttt{string}s support many of the escape sequences you're used to.
    
    \vspace{10pt}
    \begin{tabular}{l|l|l}
        Sequence & Result & Code-Point \\
        \hline
        \texttt{\textbackslash{'}}  & A single quote. & \textbackslash{u0027} \\
        \texttt{\textbackslash{"}}  & A double quote. & \textbackslash{u0022} \\
        \texttt{\textbackslash\textbackslash} 
                                    & A backslash. & \textbackslash{u005c} \\
        \texttt{\textbackslash{u\#\#\#\#}}
                                    & The unicode character represented by the hexadecimal
                                        digits \#\#\#\#. & \\
        \texttt{\textbackslash{t}}  & A horizontal tab. & \textbackslash{u0009} \\
        \texttt{\textbackslash{n}}  & A newline. & \textbackslash{u000a} \\
    \end{tabular}
    \vspace{10pt}
    
    Several other escape sequences are available, but are not useful in most JavaScript scenarios. 
    A full list of available escape sequences can be found in the appendix.
    
    \begin{verbatim}
    'This apostrophe\'s escape is necessary.'
    
    "Text\n spanning\n multiple\n lines"
    \end{verbatim}
    
    \subsection{The \texttt{object} Datatype}
    
    As stated above, the \texttt{object} datatype may be thought of as a composite of other 
    datatypes. In particular, an object is a collection of \emph{named data properties}, similar
    to a dictionary you may be familiar with from other languages.
    
    It is a remarkable feature of JavaScript that the \texttt{object} datatype also has a literal
    notation. The \texttt{object} is delimited by a pair of curly braces (i.e. ``\texttt{\{}'' and 
    ``\texttt{\}}''). Within these braces, any number of named data properties are specified by a 
    name, followed by a colon (i.e. \texttt{:}) followed by the property's data value. These named 
    data properties must be separated by commas.
    
    As an example, the following is an object literal with two properties: a property named 
    \texttt{foo} with the value of the \texttt{number} \texttt{42} and another property named 
    \texttt{bar} with the value of the \texttt{string} \texttt{"hello, world"}.
    
    \begin{verbatim}
    { foo:42, bar:"hello, world" }
    \end{verbatim}
    
    The order of the properties within the object literal is insignificant because the properties
    will be accessed by their names. For example, if this object were stored in the variable 
    \texttt{x}, the \texttt{foo} property could be accessed via the familiar \emph{dot-notation}.
    
    \begin{verbatim}
    x.foo
    \end{verbatim}
    
    There is an additional \emph{bracket-notation} for accessing properties by a string for their 
    name. The following example accesses the same property as the example above, but with the 
    alternate notation.
    
    \begin{verbatim}
    x["foo"]
    \end{verbatim}
    
    In light of this, objects may feel significantly similar to a conventional dictionary 
    collection; string-keys map to values. This bracket-notation makes two big things possible. 
    
    \begin{enumerate}
        \item It allows you to access properties of an object dynamically, via a string variable. 
        Later on, we'll loop over the properties of an object by enumerating it's property names 
        into a key variable, and then access the property values themselves by using that key 
        variable with the bracket-notation.
    
        \item The bracket-notation makes possible the accessing of properties which have names with 
        symbols that are not valid in normal property names. 
        
        For example, a single property named \texttt{prop.erty} cannot be accessed using the dot 
        notation because the dot in its name will be misinterpreted as accessing the \texttt{erty} 
        subproperty of the \texttt{prop} property. Instead we can access this value in the following 
        manner.
        
        \begin{verbatim}
        x["prop.erty"]
        \end{verbatim}
        
        As you can see, because the dot is safely enclosed within the string, JavaScript can see 
        that it is the name of a single property.
        
        The \texttt{object literal} syntax also allows illegal symbols in property names if you 
        write the property name as a string. For example:
        
        \begin{verbatim}
        { "name with spaces":"hello, world", "(){}[]":"another value" }
        \end{verbatim}
        
        You may notice that all of these bracket-notation examples use \texttt{string}s as keys, and 
        you may wonder whether other datatypes --- such as \texttt{number}s --- may also be used for 
        property names. In fact, any datatype can be used to specify a property, but its value will 
        be converted to a \texttt{string} before the object is searched for a matching name.
        
        This means that the following two lines refer to the same property of the \texttt{object} 
        \texttt{foo} --- even though the datatypes in the brackets are completely different.
        
        \begin{verbatim}
        foo["42"]
        foo[42]
        \end{verbatim}
    
    \end{enumerate}
    
    So far, we've constructed objects using the object literal syntax, but all objects can also be 
    created using another syntax which may be familiar to you: using the \texttt{new} operator and 
    the object constructor. Par example:
    
    \begin{verbatim}
    new Object()
    \end{verbatim}
    
    The reader's inner object-oriented programmer may immediately identify \texttt{Object} (with the 
    initial capital) as the \emph{class} of objects, but this is not the case. When we explore 
    object-orientation in later chapters we'll see that \texttt{Object} is not the \emph{class}, but 
    merely the \emph{constructor} for the \texttt{object} datatype.
    
    \section{Built-in Objects}
    It may seem odd that we discuss the four fundamental datatypes while not looking at arrays.
    Often, arrays are their own separate, special datatype, like in C. However, in JavaScript the 
    \emph{array datatype is implemented as an object}. More importantly, arrays are an example of a
    \emph{built-in object}.
    
    Built-in objects come from a set of classes which are provided for you by the JavaScript 
    implementation. Often, these objects are implemented with \emph{native code} and are part of 
    the JavaScript runtime itself. (Put differently, they are JavaScript objects which are not 
    written in JavaScript.) Consequently, they will behave a little differently from the objects 
    that you create.
    
    \subsection{The \texttt{array} Datatype}
    
    The array datatype is a good first example of a built-in-object because it is so useful. In 
    JavaScript, arrays are one-dimensional, untyped (potentially heterogenous) and dynamically 
    expanding. 
    
    We can create an empty array with the array literal syntax. The array is delimited by a pair of 
    open and close square braces (i.e. ``\texttt{[}'' and ``\texttt{]}'') and between them the 
    elements are separated by commas.
    
    \begin{verbatim}
    [ "element 1", "element 2", "element 3" ]
    \end{verbatim}
    
    Because arrays are really a kind of object, we can also build one with the constructor synatx:
    
    \begin{verbatim}
    new Array()
    \end{verbatim}
    
    There are two additionnal ways to call the array constructor. It can be called with a single 
    \texttt{number} argument to tell the runtime how many spaces to pre-allocate. Although a 
    pre-allocated array will have the specified length, it will otherwise behave like an empty array
    as it does not have any elements for the allocated spaces.
    
    \begin{verbatim}
    new Array(5)
    
    new Array(12)
    \end{verbatim}
    
    The \texttt{Array} constructor can also be called as a variadic function accepting as arguments
    all of the elements with which pre-populate the array.
    
    \begin{verbatim}
    new Array("element 1", "element 2", "element 3");
    
    new Array(1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987);
    \end{verbatim}
    
    You may notice that there is a potential ambiguity between these two argument patterns: if the
    \texttt{array} constructor is called as a variadic with only a single argument. Will the
    constructor treat that argument as only element or as the given length of the new array? 
    
    The resolution to this issue is that the constructor tests whether that single argument is an 
    integer, in which case it will be used as the array's new length but not as its element. In all 
    other cases, (i.e. when the lone argument is not an integer) the argument will be used as the 
    lone element of the array (which will then have a length of one). 
    
    Because of this, most programmers avoid the variadic version of the constructor and instead use 
    the array literal, which achieves the same effect with less characters and no ambiguity.
    
    The elements of any array can be indexed using the same bracket notation for accessing 
    properties of objects. The difference is that instead of passing the \texttt{string} of 
    the property name, we pass the inegral \texttt{number} of the element's zero-based index.
    For example, the following illustrates how to access the first and the twelfth element of an 
    array named \texttt{foo}.
    
    \begin{verbatim}
    foo[0]
    
    foo[11]
    \end{verbatim}
    
    \subsection{Other Built-in-Objects}
    JavaScript provides a whole host of useful built-in types in addition \texttt{array}. For 
    example, JavaScript provides a complete regular expression datatype called \texttt{RegExp} which
    has a literal syntax of its own. JavaScript provieds a \texttt{Date} object for parsing and 
    managing dates and times. JavaScript's DOM API (a Behemoth) provides a huge amount of built-in 
    objects to represent the various components of a webpage.
    
    In the next few chapters we'll learn that \emph{functions themselves} are buit-in objects. This 
    is a big concept, and we'll devote a lot of pages to them, but it means \texttt{function} is 
    just another datatype. It can be stored to a variable or passed as an argument.
    
    For the sake of this preliminary look at the type system, we'll have to leave off a complete 
    investigation of these built-in object datatypes for later chapters. Each type has its own 
    unique nuances, niceties and annoyances, so we'll have to take our time in order to be complete.
    
    \chapter{Procedural Programming}
    After looking at JavaScript's basic types, now it's time to use them as building-blocks in 
    procedural coding. We'll look at managing variables, using control structures and performing 
    calculations. This foundation will segue into the use and writing of functions.
    
    \section{Core Syntax}
    JavaScript is syntactically based on the C family of languages. For example, statements are 
    terminated by semicolons, whitespace is generally ignored and statement blocks are delimited by 
    open and close curly braces. These features --- as well as variable naming rules, code comments, 
    and the much of the operator collection --- are all borrowed from the syntax of C.
    
    \subsection{Comments}
    In particular, comments are written in two possible ways.
    
    \begin{verbatim}
    /* This
        is a
            multi-line
                comment
    */
     
    // This is a single-line comment.
    \end{verbatim}
    
    The Javadoc comment style is used frequently in JavaScript to document functions, but is not 
    strictly part of the language. Moreover, it's a subset of the existing comment syntax. 
    Similarly, C\#-style XML comments are sometimes used in conjunction with Microsoft tools.
    
    \subsection{Optional Semicolons}
    Unlike C, the use of semicolons to terminate statements in JavaScript is optional. This language 
    feature was initially concieved as a way to make the language more user-friendly or prettier. 
    However, in combination with whitespace-insensitivity, it can lead to ambiguities, especially 
    when placing multiple statements on the same line.
    
    For example:
    
    \begin{verbatim}
        x = 4
        y = x + 5
        
        // Is equivalent to...
        
        x = 4;
        y = x + 5;
        
        // However, with semicolons these statements could be on the same line.
        // For example:
        
        x = 4; y = x + 5;
        
        // This would generate a syntax error if the first semicolon were omitted.
        
    \end{verbatim}
    
    This is frequently called ``optional semicolons'' but is technically called ``automatic 
    semicolon insertion'', meaning that JavaScript tries to guess where the semicolons would belong 
    and adds them for you. In many cases JavaScript will guess wrong in such a way that the script 
    will still parse, but will not behave in an expected manner. For this reason it's considered a
    best-practice to always terminate statements with semicolons --- just as you would when writing 
    in C or Java. 
    
    \section{Declaring and using Variables}
    The most basic way to declare a variable in JavaScript is with the \texttt{var} keyword. As an 
    example, a variable named \texttt{myVar} can be declared in the following way.
    
    \begin{verbatim}
    var myVar;
    \end{verbatim}
    
    Even though the \texttt{myVar} is properly declared, it does not have a type. This declaration 
    syntax may look a bit like a declaration from a statically-typed language like C or Java, except
    that, in this case, the keyword \texttt{var} is used in place of the type.
    
    This is because JavaScript uses a \emph{dynamic type system} --- meaning, a variable can house a 
    value of \emph{any datatype}. The same variable that stores a \texttt{number} could be used to 
    store an \texttt{object} later on. A variable that stores a \texttt{boolean}, could be used to 
    store a \texttt{string} of any length.
    
    \subsection{\texttt{undefined}: The Universal Default Value}
    
    As a consequence of the dynamic system, when a variable has been declared but has not been 
    assigned, it is automatically given a default value which spans \emph{all types}: 
    \texttt{undefined}.
    
    In statically-typed languages, types usually have specific default values of their own. For 
    example (depending on the compiler and architecture) an \texttt{int} in C may be automatically
    given a default value of zero (or perhaps the garbage value of whatever data was located at its 
    memory space in the stack). But a \texttt{boolean} in Java may be automatically given the value 
    \texttt{true} or \texttt{false}.
    
    In JavaScript, since our variables do not have datatypes when they're declared, they must be 
    automatically assigned a default value \emph{which itself does not have a type}, and 
    \texttt{undefined} is this value.
    
    As stated in the chapter on the Type System, \texttt{undefined} is technically a primitive 
    datatype of its own in order to keep it seperate form all the others. What's more, 
    \texttt{undefined} is what's sometimes called a \emph{Unit Type} in Computer Type Theory, 
    meaning a type that can only house one value. Indeed the value \texttt{undefined} \emph{is its 
    own datatype}, and the datatype \texttt{undefined} \emph{is its only possible value}.
    
    This may be confusing, but the point to take away from this is that when a variable's value is
    equal to \texttt{undefined}, you should interpret that it was never assigned a value. (Unless, 
    for some reason, it was explicitly given the value \texttt{undefined}.)
    
    We'll learn more about \texttt{undefined} (and how its subtly different from \texttt{null}) as 
    we progress through the language.
    
    \subsection{Initialization Syntax}
    To give variables initial values (and to avoid \texttt{undefined}) you can specify a value in 
    stride with declaration.
    
    \begin{verbatim}
    var theAnswer = 42;
    \end{verbatim}
    
    Several variables can be declared and initialized at once using the \emph{declaration list 
    syntax}. Following the \texttt{var} keyword, variable names can be written together, seperated 
    by commas, with optional initial values.
    
    \begin{verbatim}
    var 
        message = "Welcome",
        prompt = "Please enter your name",
        givenName;
    \end{verbatim}
    
    \subsection{Variable Deletion}
    JavaScript provides a unary \texttt{delete} operator which can remove a variable and free its 
    memory space --- effectively reversing the effect of declaring it.
    
    \begin{verbatim}
    delete giantDataBuffer;
    \end{verbatim}
    
    Most programmers don't find much use for the \texttt{delete} operator because the releasing of 
    memory resources is usually handled automatically by scoping mechanisms in functions. However, 
    larger JavaScript applications can sometimes develop memory leaks and manual deletion become 
    necessary. \texttt{delete} can also be useful to overcome browser defects that generate memory 
    leaks in the DOM API (such as Internet Explorer in some cases).
    
    \subsection{A Note on Scoping}
    You may encounter what is spoken of as an alternative way of defining variables. In most cases
    you could omit the \texttt{var} keyword and the value will be accessible and assignable and 
    function exactly as if you did use the keyword.
    
    \begin{verbatim}
    theAnswer = 42;
    \end{verbatim}
    
    In truth, this syntax is \emph{not} totally equivalent to declaring a variable using 
    \texttt{var}, but it differs in terms of the scope in which the variable is created. We'll have 
    to take a look at functions and scoping before we appreciate this difference, so we'll revisit 
    this topic later.
    
    \section{Operators}
    JavaScript provides many of the operators common in C or Java. Interestingly, JavaScript treats
    some things as operators which you may be used to as syntactical constructs in other languages.
    In JavaScript, the comma is an operator. So is \texttt{new}.
    
    \subsection{Precidence}
    The following table shows the operator precedence for a few of the common operators in 
    JavaScript. For a complete precedence table see the appendix.
    
    \vspace{10pt}
    \begin{tabular}{l|l|l|l}
        Precedence & Order & Assoicativity & Operator \\ \hline
        
        1  & Unary & RTL & \texttt{new} \\ 
        1  & Binary & LTR & \texttt{.} (dot-notation), \texttt{[]} (bracket-notation). \\
        3  & Unary & & \texttt{++}, \texttt{--} \\
        4  & Unary & & \texttt{!}, \texttt{~}, \texttt{+}, \texttt{-}, 
            \texttt{typeof}, \texttt{void}, \texttt{delete} \\
        5  & Binary & LTR & \texttt{*}, \texttt{/}, \texttt{\%} (modulus) \\
        6  & Binary & LTR & \texttt{+}, \texttt{-} \\
        8  & Binary & LTR & \texttt{<}, \texttt{<=}, \texttt{>}, \texttt{>=} \\
        9  & Binary & LTR & \texttt{==}, \texttt{!=}, \texttt{===}, \texttt{!==} \\
        13 & Binary & LTR & \texttt{\&\&} \\
        14 & Binary & LTR & \texttt{\textpipe\textpipe} \\
        15 & Ternary & RTL & \texttt{?:} \\
        16 & Binary & RTL & \texttt{=}, \texttt{+=}, \texttt{-=}, \texttt{*=}, \texttt{/=}, 
            \texttt{\%=} \\
        17 & Binary & LTR & \texttt{,} (comma) \\
    \end{tabular}
    \vspace{10pt}
    
    These precidence rules mean that the expression \texttt{3*x+1} is equivalent to \texttt{(3*x)+1}
    and that \texttt{a || b \&\& c || d} is equivalent to \texttt{a || ((b \&\& c) || d)}.
    
    JavaScript provides no mechanism for overloading operators.
    
    \section{Arithmetic}
    On the surface, arithmetic in JavaScript works very much like it does in other languages. 
    However, there are some quirks, niceties and pitfalls to be aware of.
    
    In C you need to worry about dividing integers, for example the C expression \texttt{1/2} will 
    result in \texttt{0} because the arithmetic operation was in integer-mode and C did not know to
    promote the result into a float. However, in JavaScript, there is no integer type and 
    consequently there is no integer-mode. The same expression in JavaScript would yield 
    \texttt{0.5}.
    
    The division operator in JavaScript is transfinite, meaning that a division by zero such as
    \texttt{1/0} results in the \texttt{Infinity} value rather than throw an exception or result in 
    \texttt{NaN}. A negative infinity is also possible when the numerator is negative. On the other 
    hand, the expression \texttt{0/0} is treated as nonsense, and will result in \texttt{NaN}. In 
    the chapter on the \texttt{Number} datatype, we'll look closely at these special values.
    
    \section{Control Structures}
    JavaScript provides control structures to allow you to program loops and conditional blocks.
    
    \subsection{The \texttt{if} Control Structure}
    The \texttt{if} control structure is used to conditionally execute a statement or block of 
    statements based on an expression.
    
    For example:
    
    \begin{verbatim}
        if (true) {
            x = 4;
        }
        
        if (false) {
            x = 5;
        }
        
        // x has been set to 4.
    \end{verbatim}
    
    It is also possible to specify \texttt{else} and \texttt{else if} conditions.
    
    \begin{verbatim}
        var n = 4;
        
        if (n > 5) {
            x = 1;
        }
        
        else if (n <= 5 && n < 2) {
            x = 2;
        }
        
        else {
            x = 3;
        }
        
        // x has been set to 2 because it is between 2 and 5.
        // The middle (else-if) condition was executed.
    \end{verbatim}
    
    As you can see, this syntax is the same as in C and Java. In these cases one could omit the 
    curly-braces for these blocks if they only contain one statement. For example, the following 
    code is equivalent.
    
    \begin{verbatim}
        var n = 4;
        if (n > 5)
            x = 1;
        else if (n <= 5 && n < 2)
            x = 2;
        else
            x = 3;
    \end{verbatim}
    
    However, in almost all languages and coding style guides, this practice is considered bad. It is 
    recommended that you always use curly-braces to delimit your blocks. Historically, for most 
    languages and contexts, this recommendation is motivated by the fact that it is easier to read 
    code with the braces, and it is harder to make certain errors. In JavaScript, however, there is 
    the added motivation that some code optimizers work better when the braces are present.
    
    \subsubsection{A Note on Truthiness}
    The \texttt{if} control structure uses an expression to determine whether or not to execute a 
    block. However, unlike in most languages, the expression \emph{need not be boolean}. Moreover, 
    the \texttt{if} control structure can use an expression of any type, and instead of checking 
    whether it evaluates to \texttt{true} or \texttt{false}, it checks whether it is \emph{truthy}
    or \emph{falsy}.
    
    Truthiness is a generalization of the truth value to non boolean datatypes. This feature of the 
    JavaScript language is frequently maligned and often used in arguments that JavaScript is 
    inconsistent. However, the rules of truthiness are quite simple and unambiguous. Usually when an
    expression evaluates to an unexpected truthiness value, it is the result of subtle datatype 
    coersion that takes place before the truthiness is evaluated. We'll look at these confusing 
    expressions later.
    
    The rules of truthiness are as follows:
    
    \vspace{10pt}
    \begin{tabular}{l|l}
        Expression Type     & Truthiness \\ \hline
        \texttt{undefined}  & falsy \\
        \texttt{null}       & falsy \\
        \texttt{boolean}    & If the boolean is \texttt{true} then truthy, and if \texttt{false} 
            then falsy. \\
        \texttt{number}     & If the number is $+0, -0$ or \texttt{NaN}, then falsy. Truthy 
            otherwise. \\
        \texttt{string}     & If the string is empty (length is 0), then falsy. Truthy otherwise. \\
        \texttt{object}     & truthy \\
    \end{tabular}
    \vspace{10pt}
    
    This means that the following \texttt{if} blocks never execute.
    
    \begin{verbatim}
        if (false)     { /* never    */ }
        if (undefined) { /* ever     */ }
        if (null)      { /* ever     */ }
        if ("")        { /* ever     */ }
        if (0)         { /* ever     */ }
        if (0/0)       { /* executed */ }
    \end{verbatim}
    
    And that the following blocks always execute.
    
    \begin{verbatim}
        if (true)    { /* executed */ }
        if (1)       { /* each     */ }
        if (1/0)     { /* and      */ }
        if ("hello") { /* every    */ }
        if ({})      { /* time     */ }
    \end{verbatim}
    
    \subsubsection{A Note on K\&R Style}
    Another contentious aspect of coding style is whether to put opening curly-braces on the same 
    line as the control structure definition or on a newline after it. These two styles are 
    sometimes called K\&R style and BSD style respectively. As an illustrative example:
    
    \begin{verbatim}
        if (true) {
            // This block is K&R style. 
            // The open-curly brace is on the same line as the "if".
            
            // The K&R stands for Kerrighan and Richie because this style stems from their famous 
            // book titled "The C Programming Language".
        }
        
        if (true)
        {
            // This block is BSD style; sometimes called Allman style.
            // The open-curly brace is on a newline after the "if".
            
            // The BSD stands for the "Berkley Software Distribution" UNIX operating system. 
            // Eric Allman pioneered this style and also wrote a great deal of BSD.
        }
    \end{verbatim}
    
    Both of these styles are valid in JavaScript and work equally well in every way \emph{except
    one}. As we'll see in the chapter on functions, return statements with object literals 
    \emph{will not work correctly} when using BSD style. Consequently, for the sake of consistency, 
    most JavaScript code is written using K\&R style.
    
    \subsection{The \texttt{switch} Control Structure}
    TODO:
    
    \subsection{The \texttt{while} and \tetxtt{do...while} Control Structures}
    TODO:
    
    \subsection{The \texttt{for} and \texttt{for...in} Control Structures}
    TODO:
    
    \subsection{The \texttt{with} Control Structure}
    TODO:
    
    \subsection{The \texttt{throw} Statement}
    TODO:
    
    \subsection{The \texttt{try...catch} Control Structure}
    TODO:
    
    \section{Another Note on Scoping}
    No block scope... etc.
    
    \section{A Case Study in Procedural Programming}
    TODO:
    
    \chapter{Functions}
    TODO:
    
    \section{Declaring Functions}
    TODO:
    
    \subsection{Declaring Functions}
    TODO:
    
    \subsection{The \texttt{return} Statment}
    TODO:
    
    \subsection{Creating Function Objects}
    TODO:
    
    \section{The \texttt{this} Keyword}
    TODO:
    
    \section{A Deeper look at Calling Functions}
    TODO:
    
    \section{Scoping}
    TODO:
    
    \section{Hoisting}
    TODO:
    
    \section{Functions as First-Class Objects}
    TODO:
    
    \section{A Case Study in Programming with Functions}
    TODO:
    
    \chapter{Object-Oriented Programming}
    TODO:
    
    \section{Simple OOP}
    TODO:
    
    \subsection{Data Members and Methods}
    TODO:
    
    \subsection{Constructor Syntax}
    TODO:
    
    \section{Prototypal Inheritance}
    TODO:
    
    \subsection{The \texttt{prototype} Property}
    TODO:
    
    \subsection{The Role of \texttt{prototype} During Construction}
    TODO:
    
    \subsection{Derriving Classes via \texttt{prototype}}
    TODO:
    
    \section{Object Property Attributes}
    TODO:
    
    \subsection{The \texttt{value} Property Attribute}
    TODO:
    
    \subsection{The \texttt{writable} Property Attribute}
    TODO:
    
    \subsection{The \texttt{enumerable} Property Attribute}
    TODO:
    
    \subsection{The \texttt{configurable} Property Attribute}
    TODO:
    
    \section{A Case Study in Object-Oriented Prorgamming}
    TODO:
    
    \part{The Type System}
    
    \chapter{Truthy Values and the \texttt{boolean} Datatype}
    
    \section{\texttt{true} and \texttt{false} Vs. Truthy and Falsy}
    
    \section{The Truth of Expressions}
    
    \section{A Case Study in Truth Values}
    
    \chapter{The \texttt{number} Datatype}
    
    \section{Encoding and Range}
    
    \section{Special Numbers}
    
    \subsection{$\pm$ Zero}
    
    \subsection{$\pm$ Infinity}
    
    \subsection{\texttt{NaN}}
    
    \subsection{The \texttt{Math} Object}
    
    \section{\texttt{number}-Valued Expressions}
    
    \section{A Case Study in the \texttt{number} Datatype}
    
    \chapter{The \texttt{string} Datatype}
    
    \section{Encoding}
    
    \section{String Methods}
    
    \subsection{The \texttt{fromCharCode()} Method}
    
    \subsection{The \texttt{charAt(pos)} and \texttt{charCodeAt(pos)} Methods}
    
    \subsection{The \texttt{concat(string1, ..., stringN)} Method}
    
\end{document}