INDEX work in chapter 5

[martin-henz]

No description provided.

[martin-henz]

Substantial changes:

25/4/2021: 5.4.1 near end: removed newline before
"ev_sequence_empty",
go_to(reg("continue")),
There may be some reasoning behind the newline, but I think it looks better without the newline.

25/4/2021: 5.3.1 added is_boolean and is_undefined to the list of is_ functions just before heading “Implementing Stacks”. This is for completeness, to have consistent index entries for these predicates.

25/4/2021: 5.3.1 handling of strings: we forgot that +, stringify, char_at etc create new strings at runtime. Also note the established term for this: string pool.

A string might be represented as a typed pointer that designates a sequence of the characters that form the string<APOS/>s printed representation. This sequence is constructed by the JavaScript parser when the character string is initially encountered in input. Since we want two instances of a string to be recognized as the <QUOTE>same</QUOTE> string by <JAVASCRIPTINLINE>===</JAVASCRIPTINLINE> and we want <JAVASCRIPTINLINE>===</JAVASCRIPTINLINE> to be a simple test for equality of pointers, we must ensure that if the parser sees the same character string twice, it will use the same pointer (to the same sequence of characters) to represent both occurrences. To accomplish this, the parser maintains a table of all the strings it has ever encountered. When the parser encounters a character string and is about to construct a string, it checks the table to see if it has ever before seen the same character string. If it has not, it uses the characters to construct a new string (a typed pointer to a new character sequence) and enters this pointer in the table. If the parser has seen the string before, it returns the string pointer stored in the table. This process of replacing character strings by unique pointers is called <EM>interning</EM> strings. 

⇒

A string might be represented as a typed pointer that designates a sequence of the characters that form the string<APOS/>s printed representation. The JavaScript parser constructs such a sequence when it initially encounters a string as a string literal, and the string-producing concatenation operator <JAVASCRIPTINLINE>+</JAVASCRIPTINLINE> and string-producing primitive functions such as <JAVASCRIPTINLINE>stringify</JAVASCRIPTINLINE> and <JAVASCRIPTINLINE>char_at</JAVASCRIPTINLINE> construct such a sequence when they return a new string. Since we want two instances of a string to be recognized as the <QUOTE>same</QUOTE> string by <JAVASCRIPTINLINE>===</JAVASCRIPTINLINE> and we want <JAVASCRIPTINLINE>===</JAVASCRIPTINLINE> to be a simple test for equality of pointers, we must ensure that if the machine sees the same string twice, it will use the same pointer (to the same sequence of characters) to represent both occurrences. To accomplish this, the machine maintains a table, called the <EM>string pool</EM>, of all the strings it has ever encountered. When the machine encounters a string, it checks the string pool to see if it has ever before seen the same string. If it has not, it uses the string<APOS/>s characters to construct a new string (a typed pointer to a new character sequence) and enters this pointer in the string pool. If the machine has seen the string before, it returns the string pointer stored in the string pool. This process of replacing strings by unique pointers is called <EM>string interning</EM>. 

25/4/2021: 5.1.1: print => display
Instead of having the machine stop after printing
the answer, we have made it start over, so that it repeatedly
reads a pair of numbers, computes their GCD, and prints
the result.
⇒
Instead of having the machine stop after displaying
the answer, we have made it start over, so that it repeatedly
reads a pair of numbers, computes their GCD, and displays
the result.

25/4/2021: 5.5.3, footnote 47: move closer to original: Rationale: If “compilers not always” do this, a programmer cannot rely on recursion for representing iterative processes, so the conclusion is still valid, even for a weaker premise.
However, most compilers for common languages, including C, cannot always do this, and as a result cannot always represent iterative processes in terms of function call alone.
⇒
However, compilers for common languages, including C and C++, do not always do this, and therefore these languages cannot represent iterative processes in terms of function call alone.

24/4/2021: 5.4.3, exercise on while loops: rephrased
You may cheat and assume that the syntax transformer
⇒
You may cheat by assuming that the syntax transformer

24/4/2021: 5.4.3, exercise on while loops: removed “then”
You can then paste the declaration of the function
⇒
You can paste the declaration of the function

24/4/2021: 5.4.3, subheading “Blocks“: Removed footnote. Rationale: This footnote doesn’t make sense, in multiple ways, in my view.

Scanning out declarations should be a syntax transformation,
like operator_combination_to_application.
See footnote in
section.

[TobiasWrigstad]

Looks great. There may be one INDEX placement that needs tweaking once I've rebased the mit branch, but I'll deal with that in that case.

All content edits good. We need to alert Julie to these, ofc.