PIE update

Author: easycoder

js/easycoder/Browser.js

@@ -2174,8 +2174,6 @@ const EasyCoder_Browser = {
 				switch (targetRecord.keyword) {
 				case `text`:
 				case `textarea`:
-					target.value = value;
-					break;
 				case `input`:
 					target.value = value;
 					break;

pie/pie/2 Designing a language/Commands.txt

@@ -22,11 +22,19 @@ If you are building a composite string this can be a little cumbersome, so I rec
 index Numbers to N
 print `The value of element ` cat N cat ` of Numbers is ` cat Numbers
 ```
-All languages need a selection of conditional commands, the minimum being `if` and `while`. Because this language will probably lack any advanced structuring you'll also need the infamous `goto` command. To avoid repetition you'll most likely want `gosub` and `return` (or their equivalents). If you're feeling really adventurous you might include a `with` clause in your `gosub` so you can pass in private variables, but it could get rather complex as you'll need some way of identiying them at the entry point of a subroutine.
+All languages need a selection of flow control commands, the minimum being `if` and `while`. Because this language will probably lack any advanced structuring you'll also need the infamous `goto` command. To avoid repetition you'll most likely want `gosub` and `return` (or their equivalents). If you're feeling really adventurous you might include a `with` clause in your `gosub` so you can pass in private variables, but it could get rather complex as you'll need some way of identiying them at the entry point of a subroutine.
 
-When you're programming browser-based apps you'll almost certainly want concurrent processing at some point. JavaScript itself is single-threaded but there are ways to implement concurrency (or at least something that looks and feels like it) in your scripts. All I'll say here is that with this capability you can implement commands like `wait` to pause execution for a given time, `fork` to run different parts of your script concurrently with another, and `run` to load and concurrently run different script modules. There's a whole chapter of this book devoted to the subject.
+When you're programming browser-based apps you'll almost certainly want concurrent processing at some point. JavaScript itself is single-threaded but there are ways to implement concurrency (or at least something that looks and feels like it) in your scripts. All I'll say here is that with this capability you can implement commands like `wait` to pause execution for a given time, `fork` to run different parts of your script concurrently with another, and `run` to load and concurrently run different script modules. I'll cover these a little later on in this book.
 
-Another thing you'll almost certainly want at some point is a set of REST commands so you can GET data from your own or remote websites and POST data back again.
+Some other things you're likely to want at some point (some more important than others):
+ - a set of REST commands so you can GET data from your own or remote websites and POST data back again
+ - commands for handling JSON data; creating JSON objects adding and removing items from them etc.
+ - commands for handling forms
+ - a Google Maps module
+ - floating-point arithmetic
+ - other specialized domain-related commands
+
+All of these can be handled by load-on-demand plugins (~sid:5 Plugins:See this section~) instead of rolling them into the main JS file~
 
 ## DOM commands
 A large number of commands in the browser domain will be those dealing with the Document Object Model. This is where the language is likely to be most frequently used; as a replacement for JavaScript when aspects of a web page need to be tweaked.
@@ -35,7 +43,7 @@ Each of the DOM variables such as `<div>` will be designed to handle actions on
 ```
 attach Screen to `id_screen`
 ```
-This assumes that in your page there is a `<div>` with an id of `id_screen`. Your runtime JavaScript looks for this id and "attaches" its owner to the script variable. You can now perform operations on the variable; the runtime instantly and faithfully mirrors changes on the `<div>` itself. Your language will have to recognise all the commands that are valid for this variable type, so you might decide to implement a `set` command to do the hard work, with constructs like
+This assumes that in your document there is a `<div>` with an id of `id_screen`. Your runtime JavaScript looks for this id and "attaches" its owner element to the script variable. You can now perform operations on the variable; the runtime instantly and faithfully mirrors changes on the `<div>` itself. Your language will have to recognise all the commands that are valid for this variable type, so you might decide to implement a `set` command to do the hard work, with constructs like
 ```
 set the background of Screen to `yellow`
 ```

pie/pie/2 Designing a language/Environment.txt

@@ -6,7 +6,7 @@ Rather than beat about the bush I'll come straight to the point. The techniques
 
 The other decision concerns where the code is to run. If the compiler is coded in Python, the applications you build are basically restricted to running on a PC of some kind. I'm personally doubtful of the value of this, especially as Python is itself already a fairly high-level language and you'd get more bang from your buck by just learning that.
 
-Some might prefer to code in C++ or Java. Many compilers are written in C++ so there's something to be said for that, though if you want to distrbute your efforts you'll have to do versions for Windows, for Mac and for Linux.
+Some might prefer to code in C++ or Java. Many compilers are written in C++ so there's something to be said for that, though if you want to distribute your efforts you'll have to do versions for Windows, for Mac and for Linux.
 
 There are many, many other alternatives but the one that stands out is JavaScript, because it runs in every browser on the planet. Many people, most notably Chromebook owners, rarely venture outside the browser. Your apps can reside on a webserver and be available simply by typing a URL. Add to this a superb graphics environment and the case is unanswerable.
 

pie/pie/2 Designing a language/Example code.txt

@@ -45,6 +45,6 @@ multiply C by B
 divide B by A giving C
 divide C by B
 ```
-Note how I've shown multiply and divide having the two values in the opposite order to add and subtract. This of course regards B as a "primary" value and A as something being used to modify it, which might not always be the case, but it serves to point out how the new language can follow English quite closely.
+Note how I've shown multiply and divide having the two values in the opposite order to add and subtract. The way I've presented it treats B as a "primary" value and A as something being used to modify it, which might not always be the case, but it serves to point out how the new language can follow English quite closely.
 
 ~tid:Variables~

pie/pie/2 Designing a language/content.txt

@@ -12,7 +12,7 @@ This is pretty obvious really. If we can't be sure what a statement means, how c
 
  2. A computer program is code, but sometimes there's a need to explain what's happening. A comment is there for human readers and the computer knows to ignore it when running the program. You can adopt any comment style you wish, but for the purposes of this book I'm going to use an exclamation mark (!) to indicate that what follows is a comment.
 
- 3. Modern programming is nearly always 'structured', but human language isn't. Human-written instructions such as cooking recipes or navigation directions use GOTO freely, but this has been anathema to programmers for some decades now. Here we have something of a dilemma. Structure can be applied without the use of symbols, for example using indentation as in Python, but then it's all too easy to get wrong in ways that are hard to spot, so in many respects it's little better than having no structural rules at all. Consider though that programs written in our new language are unlikely to be massively complex. Anything really large or complex requires a professional programmer, who will be using mainstream development tools, so it's arguable we don't need formal structure. Fortran managed without it in the early days of programming, so without any sense of shame we'll resurrect the much-maligned GOTO command. What we do need is something to identify a labelled point in a program, and for this I'll allocate a colon (:) symbol.
+ 3. Modern programming is nearly always 'structured', but human language isn't. Human-written instructions such as cooking recipes or navigation directions use GOTO freely, but this has been anathema to programmers for some decades now. Here we have something of a dilemma. Structure can be applied without the use of symbols, for example using indentation as in Python, but then it's all too easy to get wrong in ways that are hard to spot, so in many respects it's little better than having no structural rules at all. Consider also that programs written in our new language are unlikely to be massively complex. Anything really large or complex requires a team of professional programmers, who will be using mainstream development tools, so it's arguable we don't need formal structure. Fortran managed without it in the early days of programming, so without any sense of shame we'll resurrect the much-maligned GOTO command. What we do need is something to identify a labelled point in a program, and for this I'll allocate a colon (:) symbol.
 
  4. When literal text is used it must be quoted so the compiler won't mistake it for code. This is normally done with single or double quotes, but when you want to include one of these characters in your quoted text it gets very messy. So I'll specify the little-used backtick (`) to denote quoted text.
 
@@ -22,6 +22,6 @@ And that's it - just 3 symbols.
 
 To help with clarity it's useful to capitalize certain words. English is actually a poor example since capitals are used mainly to start sentences and for names. German takes things a lot further by capitalizing all nouns.
 
-Computer languages generally use camel case, which does indeed improve readability, but then start all names with lower-case, contrary to usage in human languages. To keep closer to the latter I'll suggest using an initial capital letter on all variable names. It won't actually be a requirement but it makes statements much more readable. The initial word of every statement will start with a lower-case letter otherwise it could be confused with a variable having the same name. It also helps when you build a color-coded editor to have all the variables stand out in their own color.
+Computer languages generally use camel case, which does indeed improve readability, but then start all names with lower-case, contrary to usage in human languages. To keep closer to the latter I'll suggest using an initial capital letter on all variable names. It won't actually be a requirement but it makes statements much more readable. The initial word of every statement will start with a lower-case letter otherwise it could be confused with a variable having the same name. It also helps when you build a color-coded editor, to have all the variables stand out in their own color.
 
 ~tid:Environment:The coding environment~

pie/pie/3 Compilation/Compiler.txt

@@ -1,8 +1,6 @@
-# Keywords
+# The compiler
 
-In our custom language, every program statement starts with an English command verb such as `put`, `get`, `open`, `close`, `print` etc., plus a handful of other words like `if` and `while`. All of these words we call _keywords_ and each one of them has its own section of code in the compiler to handle it.
-
-Most of the main compiler module is a collection of functions to do things that will be needed by the keyword processors. I'll show the ones implemented in _**EasyCoder**_; your language may need more or less of them.
+Most of the main compiler module is a collection of functions to do things that will be needed by the ~tid:Keywords:keyword handlers~. I'll show the ones implemented in _**EasyCoder**_; your language may need more or less of them.
 
 The _**EasyCoder**_ compiler module looks like this:
 ```

pie/pie/3 Compilation/Handlers.txt renamed to pie/pie/3 Compilation/Keywords.txt

@@ -1,6 +1,10 @@
 # Keyword handlers
 
-Here we come to the heart of the compiler. When the compiler starts to evaluate a command, the first word will be a command verb or a special word such as `if` or `while`. The compiler tries each of the available domains in turn until one reports it is able to handle that keyword. This is done by a call to a function inside the domain handler. The one for the "core" package looks like this:
+Here we come to the heart of the compiler.
+
+In our custom language, every program statement starts with an English command verb such as `put`, `get`, `open`, `close`, `print` etc., plus a handful of other words like `if` and `while`. All of these words we call _keywords_ and each one of them has its own section of code in the compiler to handle it. These _handlers_ are distributed among the various domain modules that contribute to the language.
+
+When the compiler starts to evaluate a command, the first word will be a command verb or a special word such as `if` or `while`. The compiler tries each of the available domains in turn until one reports it is able to handle that keyword. This is done by a call to a function inside the domain handler. The one for the "core" package looks like this:
 ```
 	getHandler: (name) => {
 		switch (name) {
@@ -30,7 +34,7 @@ Perhaps the most important command is `stop`, which causes the current thread of
 
 There's also likely to be an `exit` command, which not only stops the current thread but terminates the entire program instance, which ideally should clean itself up and remove itself from the browser. You should choose what action should happen if execution reaches the end of a script without either `stop` or `exit` being found. The `exit` command is unlikely to be used by the mai program running in a browser as the page would stop operating, but if you've called in other scripts it's sometimes useful to be able to terminate them.
 
-Let's continue by examining how to process an `add` command. Here's the handler:
+Let's continue by examining how to process an `add` command. Here's the handler referenced in the fragment above:
 ```
 	Add: {
 

pie/pie/3 Compilation/Tokenizer.txt

@@ -1,12 +1,12 @@
 # The tokenizer
 
-The tokenizer reads the entire script and converts if to a list of tokens. Since we're dealing with a variant of English, these tokens are words delimited by spaces or newlines. We'll decide to ignore the difference as for as possible and allow scripts to be written on one line or over several lines, according to the whim of the programmer.
+The tokenizer reads the entire script and converts it to a list of tokens. Since we're dealing with a variant of English, these tokens are words delimited by spaces or newlines. We'll decide to ignore the difference as far as possible and allow scripts to be written on one line or over several lines, according to the whim of the programmer.
 
 The tokenizer scans along the source script, character by character. First it looks for a non-space, then it moves forward until it sees a space. The characters it passed over become a _token_ that gets pushed into an array, with a couple of exceptions:
 
-The first exception is comments. These start with an exclamation mark and continue to the end of a line. A comment can be the only thing on a line or it can be placed after a program instruction. So when the scanner sees an exclamation mark it removes everything from and including it to the end of the line.
+The first exception is comments. These start with an exclamation mark and continue to the end of a line. A comment might be the only thing on a line or it might be placed after a program instruction. So when the scanner sees an exclamation mark it removes everything from and including it to the end of the line.
 
-The second exception is quoted strings, which may themselves contain spaces. Quoted strings start and end with a backtick (`) and they're not allowed to continue from one line to the next. So when the tokenizer sees a backtick it reads ahead until it sees a matching backtick, then the entire string (minus its backticks) is pushed to the list.
+The second exception is quoted strings, which may themselves contain spaces. Quoted strings start and end with a backtick (`) and they're not allowed to continue from one line to the next. So when the tokenizer sees a backtick it reads ahead until it sees a matching backtick, then the entire string (minus its backticks) is pushed to the token array.
 
 At the end of the scanning pass we have an array of tokens. However, there's a little more to do to make the programmer's life easier. If an error occurs it's polite to report it, showing where it happened in the original script. Rather than just push plain tokens onto our list we also push the index of the token in the list and the line number of the original script it came from. The latter is easy to  get simply by counting newlines while scanning. We also build a second array, comprising the line number and the text of each line. This will let our error reporter show the line at which the error occurred and maybe a few lines leading up to it.
 

pie/pie/3 Compilation/Variables.txt

@@ -1,6 +1,6 @@
 # Compiling variables
 
-Variables are a special kind of entity and require a special kind of entry in the program list. Each _domain_ (see ~tid:Compiler:the compiler~) handles its own types of variables but in the program list they all look much the same. In _**EasyCoder**_ the _compileVariable()_ function looks like this:
+Variables are a special kind of entity and require a special kind of entry in the program list. Each _domain_ (see ~tid:Domains:Domains~) handles its own types of variables but in the program list they all look much the same. In _**EasyCoder**_ the `compileVariable()` function looks like this:
 ```
 	compileVariable: function(domain, keyword, isVHolder = false, extra = null) {
 		this.next();
@@ -42,7 +42,7 @@ It starts by checking for a duplicate token name, then adds an entry to the symb
 
 `used` - a boolan value that starts `false` and is changed to `true` as soon as the compiler comes across a command that assigns it a value. This allows a post-compilation check to be made for unused variables. Note that simply reading a variable does not set the flag (this would defeat the purpose of identifying it as unused). Unused variables are a frequent source of errors when you come to run your program.
 
-`isVHolder` - tells the compiler that this variable is able to hold a numeric or a string value. Many variable types do not so this permits another compilation check to be made that a script is not attempting to assign a value to them.
+`isVHolder` - tells the compiler that this variable is able to hold a numeric or a string value. Many variable types do not so this permits another compilation check to be made that a script is not attempting to assign a value to one of them.
 
 `name` - the name of the variable.
 
@@ -56,6 +56,6 @@ It starts by checking for a duplicate token name, then adds an entry to the symb
 
 `extra` - an unspecified extra object. This is used by the _browser_ plugin to signify that the variable is a DOM object. Other domains may use it for something else entirely.
 
-Your language may have more or less fields than this, according to its requirements.
+Your language may have more or fewer fields than this, according to its requirements.
 
-~tid:Handlers:Keyword handlers~
+~tid:Keywords:Keyword handlers~

pie/pie/3 Compilation/content.txt

@@ -16,7 +16,7 @@ The compiler I will describe here will generate code that can easily be interpre
 
 ## Compiler strategy
 
-Books on compiler design generally describe a standard series of steps such as _lexical_, _syntax_ and _semantic analysis_, _code generation_ and _optimization_. The compiler examines the entire program to build an internal representation of if, then traverses the structure to generate and optimize the code. We're not going to do any of that. Not because it's wrong - it certainly isn't - but because it's not the only way. The technique I'll be describing here is based on observation of how human beings process language, particularly foreign language. As far as I know there are no other books on this techinique.
+Books on compiler design generally describe a standard series of steps such as _lexical_, _syntax_ and _semantic analysis_, _code generation_ and _optimization_. The compiler examines the entire program to build an internal representation of if, then traverses the structure to generate and optimize the code. We're not going to do any of that. Not because it's wrong - it certainly isn't - but because it's not the only way. The technique I'll be describing here is based on observation of how human beings process language, particularly foreign language. I have yet to find any other books describing this techinique.
 
 Imagine you encounter some instructions written in some language other than English. Let's say you have a very basic understanding of the language but are in no way fluent, and that you have a dictionary to hand. How do you approach the task?
 
@@ -32,7 +32,7 @@ Now I can't guarantee that all minds approach a problem the same way, but this h
 
 The first word is _apri_. I look this up in the dictionary and discover it means _open_ (as a command verb). So I deduce that what follows must be something that needs to be opened. The next word is _la_ (_the_) which I will treat as syntactic noise that doesn't affect the overall meaning. Then comes _terza_ (_third_). I realize this isn't a thing at all; it's an ordinal number. So the thing that needs to be opened is the third of something. Save that information and move on to _porta_ (_door_). Yes, this makes sense; it's the third door.
 
-At this point there are potentially several possibilities. Perhaps there's nothing at all, in which case I'll need to make some kind of assumption about which door to open. Perhaps it's telling me _how_ to open the door, with a adjective like _quickly_ or _slowly_? Nope, it's none of them.  It's actually _a_ (_on the_). This is another bit of syntactic noise, but it gives me a good clue as to what to expect, that is, either _right_ or _left_. When I take the next token it's confirmed.
+At this point there are potentially several possibilities. Perhaps there's nothing at all, in which case I'll need to make some kind of assumption about which door to open. Perhaps it's telling me _how_ to open the door, with an adjective like _quickly_ or _slowly_? Nope, it's none of them.  It's actually _a_ (_on the_). This is another bit of syntactic noise, but it gives me a good clue as to what to expect, that is, either _right_ or _left_. When I take the next token it's confirmed.
 
 There are several points along the way where more than one possibility branches off from where I am. The technique I'm using tries each of these possibilities in turn until one is found that meets expectations, then I move on. If none of my expectations are met I may have taken a wrong turning earlier, so I back up to that point and try another path. Eventually I either find a complete match for the whole instruction or I conclude that it's nonsense - an error.
 
@@ -42,7 +42,7 @@ However, all of the above assumes the program is presented to the compiler as a
 
 ## Function naming
 
-When you add a JavaScript file to your web page you are adding all its global constants, variables and functions. It's important to name these in such as way that they're not likely to clash with names chosen for other JS modules that might also be added to the page. The best strategy is to keep to a minimum the number of distinct global names and to prefix each one with a unique identifier such as the name of your project. For example, _**EasyCoder**_ comprises a number of source files each of which contains a single function with the name `EasyCoder_`_something_. Here is the start of the main compiler module:
+When you add a JavaScript file to your web page you are adding all its global constants, variables and functions. It's important to name these in such as way that they're not likely to clash with names chosen for other JS modules that might also be added to the page. The best strategy is to keep to a minimum the number of distinct global names and to prefix each one with a unique identifier such as the name of your project. For example, _**EasyCoder**_ comprises a number of source files each of which contains a single object with the name `EasyCoder_`_something_. Here is the start of the main compiler module:
 ```
 const EasyCoder_Compiler = {
 

pie/pie/4 Runtime/DOM.txt

@@ -0,0 +1,135 @@
+# Running DOM commands
+
+Browser commands tend to be more complex than the simple ones we've just seen, with the notable exception of variable declarations, which just return the address of the next command.
+
+Here's the browser `create` command. It's a simplified copy of the code in _**EasyCoder**_:
+```
+    run: (program) => {
+        const command = program[program.pc];
+        const targetRecord = program.getSymbolRecord(command.name);
+        let parent;
+        if (command.parent === `body`) {
+            parent = document.body;
+        } else {
+            const p = program;
+            const parentRecord = p.getSymbolRecord(command.parent);
+            parent = parentRecord.element[parentRecord.index];
+        }
+        targetRecord.element[targetRecord.index] = document.createElement(targetRecord.keyword);
+        targetRecord.element[targetRecord.index].id =
+            `ec-${targetRecord.name}-${targetRecord.index}-${EasyCoder.elementId++}`;
+        if (targetRecord.keyword === `a`) {
+            targetRecord.element[targetRecord.index].setAttribute(`href`, `#`);
+        }
+        parent.appendChild(targetRecord.element[targetRecord.index]);
+        return command.pc + 1;
+    }
+```
+As before, first we get the command, then the symbol table record for the target variable (for example a `<div>`).
+
+When we create a DOM object we can make it a direct child of the page BODY or of another DOM element. In the latter case, the parent will have been specified in the script, so we can get its record, and from that the actual DOM element (which will only exist if the parent has also been `create`d or has been `attach`ed to a suitable element in the document).
+
+Now we create a new element, giving it the type, e.g. `dom`. We must give it an ID that is guaranteed to be unique; I choose to use a 3-part name comprising the variable name, its array index and a global serial number that increments for every DOM element. This combination ID is very useful when using the browser debugger as it becomes quite clear how any element relates to the script. So a typical ID looks like
+```
+MyDiv-0-392
+```
+A special action is needed for hyperlinks; these must have an attribute set so they don't respond to clicks except via script commands (more of this later). And finally we append the new element to its parent.
+
+### `on click`
+
+This is the runtime code for the following command:
+```
+on click <DOM variable> <do something>
+```
+
+This is one of the most complex parts of DOM handling. Here's a simplified version of the code extracted from the _**EasyCoder**_ handler:
+```
+    targetRecord = program.getSymbolRecord(command.symbol);
+    targetRecord.element.forEach(function (target, index) {
+        if (target) {
+            target.targetRecord = targetRecord;
+            target.targetIndex = index;
+            target.targetPc = command.pc + 2;
+            target.onclick = function (event) {
+                event.stopPropagation();
+                EasyCoder_Browser.clickData = {
+                    target,
+                    clientX: event.clientX,
+                    clientY: event.clientY
+                };
+                if (program.length > 0) {
+                    const eventTarget = event.target;
+                    if (eventTarget.type != `radio`) {
+                        eventTarget.blur();
+                    }
+                    if (typeof eventTarget.targetRecord !== `undefined`) {
+                        eventTarget.targetRecord.index = eventTarget.targetIndex;
+                        setTimeout(function () {
+                            program.run(eventTarget.targetPc);
+                        }, 1);
+                    }
+                }
+                return false;
+            };
+        }
+    });
+```
+In _**EasyCoder**_ it's common to create an array of DOM variables that respond identically to a mouse click, avoiding the need to set up a handler for each array element. So the code sets up listeners for each of the array elements.
+
+Three items of information need to be retrieved when a mouse click occurs, so these are added to the DOM element as properties. Bear in mind that at the point this code runs there hasn't yet been a mouse click; we're just setting up for when they do happen.
+
+Next we set up the `onclick` listener. The content of this is what will handle the actual click. We set up a global record to record the target element and the click location; this is needed for drag and drop operations. We 'blur' everything except radio buttons (to remove the focus), then we set the index of the DOM variable to the one that was clicked, allowing the `<do something>` code to know which element it's dealing with.
+
+Finally, we request a new execution thread for the actions resulting from the click. It's best to do this after a short pause, otherwise the display doesn't have time to update before the actions start to take effect.
+
+This code is not guaranteed to be optimal. Slight changes tend to have unforseen effects. All I can say is that it works pretty reliably and saves a massive amount of effort compared with having to do it in JavaScript each time.
+
+## CSS
+
+You have a choice of assigning CSS classes to DOM elements or of assigning specific style values. If you want to do the former you'll need something along the lines of:
+```
+    symbol = program.getSymbolRecord(command.symbolName);
+    target = symbol.element[symbol.index];
+    if (!target) {
+        targetId = program.getValue(symbol.value[symbol.index]);
+        target = document.getElementById(targetId);
+    }
+    program.getValue(command.value).split(` `).forEach(function(item) {
+        target.classList.remove(item);
+        target.classList.add(item);
+    });
+
+```
+This gets the symbol record for the element, either directly from the symbol record or by using its saved ID and requesting it from the DOM. Then it splits the list of classes provided, removes each one from the target's class list and replaces it.
+
+The alternative is to set styles directly:
+```
+    symbol = program.getSymbolRecord(command.symbolName);
+    target = symbol.element[symbol.index];
+    if (!target) {
+        const symbolElement = symbol.value[symbol.index];
+        if (!symbolElement.type) {
+            program.runtimeError(command.lino,
+                `Variable '${symbol.name}' is not attached to a DOM element.`);
+            return 0;
+        }
+        targetId = program.getValue(symbolElement);
+        target = document.getElementById(targetId);
+    }
+    const styleValue = program.getValue(command.styleValue);
+    if (!symbol.element[symbol.index]) {
+        program.runtimeError(command.lino, `Variable '${symbol.name}' has no DOM element.`);
+        return 0;
+    }
+    switch (command.type) {
+    case `setStyle`:
+        target.style[command.styleName.content] = styleValue;
+        break;
+    case `setStyles`:
+        target.style.cssText = styleValue;
+        break;
+    }
+```
+This one presents an alternative way of getting the target element. It then either replaces all the styles on that element or just one of them, depending on what it finds in `command.type`.
+
+~sid:5 Plugins:Plugins~

pie/pie/4 Runtime/Handlers.txt

@@ -0,0 +1,87 @@
+# Runtime handlers
+
+Every keyword has a runtime handler function alongside the compiler function described ~stid:3 Compilation/Handlers:earlier~. The handler for `add` looks like this:
+```
+    run: program => {
+        const command = program[program.pc];
+        const value1 = command.value1;
+        const value2 = command.value2;
+        const target = program.getSymbolRecord(command.target);
+        if (target.isVHolder) {
+            const value = target.value[target.index];
+            if (value2) {
+                const result = program.getValue(value2) +
+                    program.getValue(value1);
+                target.value[target.index] = {
+                    type: `constant`,
+                    numeric: true,
+                    content: result
+                };
+            } else {
+                if (!value.numeric && isNaN(value.content)) {
+                    program.nonNumericValueError(command.lino);
+                }
+                const result = parseInt(value.content) + parseInt(program.getValue(value1));
+                target.value[target.index] = {
+                    type: `constant`,
+                    numeric: true,
+                    content: result
+                };
+            }
+        } else {
+            program.variableDoesNotHoldAValueError(command.lino, target.name);
+        }
+        return command.pc + 1;
+    }
+```
+We start by extracting the command from the program (passed in as the single parameter) at the index given by `program.pc`. Then we get from it the two values to be added and the name of the _target_ variable - that is, where the result is going. Next we get the symbol table record for that variable and check if it's able to hold a value. If not, we throw an error.
+
+Next we get the current value of the target, by using its array index. Remember that every variable is an array although most only ever have a single element.
+
+Now we check if there actually was a second value or whether the sum is of the form
+```
+C = C + A
+```
+If `value2` exists we can request the values to be added, do the addition and write the result back into the target array. Note that we're writing a new value specification, not just the result itself.
+
+If the second value was not present we check that the target contains a numeric value, without which it's risky to do the addition. This is a safety measure to avoid hard-to-find type conversion errors. (You may think it should also be done for the first case too, but I'm assuming that `getValue(value)` will convert strings to numbers.) So we get the integer value of each of the 2 values, add them together and post them back to the target.
+
+Finally, we return the value of the current program counter advanced by one.
+
+There's nothing to say this is the only - or even the best - way to handle all the issues involved, but it's one that I've found in practice results in very few errors.
+
+### `fork`
+
+Here's a second example; this time of the `fork` command:
+```
+    run: program => {
+        const command = program[program.pc];
+        try {
+            program.run(program.symbols[command.label].pc);
+        } catch (err) {
+            console.log(err.message);
+            alert(err.message);
+        }
+        return command.pc + 1;
+    }
+```
+This function is very short; it extracts the command as before then starts a new program thread at the address of the label given before returning the next step as before. The new thread won't run immediately because this one is still active, so it just goes onto the queue and the current thread continues with the next command. The new thread will get its day in the sun when the current one reaches a `stop` or a `wait` command.
+
+### `if`
+
+And finally, here's how the `if` command is handled:
+```
+    run: program => {
+        const command = program[program.pc];
+        const condition = command.condition;
+        const test = program.condition.test(program, condition);
+        if (test) {
+            return command.pc + 1;
+        }
+        return command.else;
+    }
+
+```
+This one extracts the command then the condition and calls the condition processor to evaluate it as `true` or `false`. It then returns either with the address of the next command or with the `else` address.
+
+~tid:DOM:Running DOM commands~

pie/pie/4 Runtime/content.txt

@@ -2,13 +2,13 @@
 
 Once compilation is complete, its output is a _program_; a list of commands. The job of the runtime engine is to take these commands in linear order or as directed otherwise and perform the duties each one encapsulates. You could regard the commands as an assembly language for a rather special kind of processor.
 
-The runtime engine starts by pushing onto a runtime queue the offset (the program counter) at which to start execution. If the queue was not empty, nothing else happens as the queue already contains one or more threads of execution handling previous run requests.
+The runtime engine starts by pushing onto a runtime queue the offset (the program counter) at which to start execution. If the queue was not empty, nothing else happens as the queue already contains one or more threads of execution, handling previous run requests.
 
 Once an execution thread stops, by reaching a `stop` or `wait` command, the queue is popped and the next run request starts. If this is well-behaved it too will stop or wait at some point and allow another thread to start. This behaviour creates an illusion of multi-tasking.
 
-In a system where multiple scripts may running at the same time, each one can have its own program and its own queue or you may set up a gloabl queue where each entry comprises a program and its program counter.
+In a system where multiple scripts may run at the same time, you can arrange for each one to have its own program and its own queue or you may set up a global queue where each entry comprises a program and its program counter.
 
-Each command contains a `domain` property. This identifies which plugin domain should handle the command. Here's the core of the runtime engine in its simplest form:
+Each command contains a `domain` property that identifies which plugin domain should handle the command. Here's the core of the runtime engine in its simplest form:
 ```
     while (queue.length > 0) {
         program.pc = queue.shift();
@@ -41,4 +41,4 @@ If you add a `trace` command you can arrange for the program to stop at each com
 
 Trace/debug is implemented in _**EasyCoder**_. The code is all in the `Runtime.js` file and there's a page in the [Codex](https://easycoder.github.io?s=step10) describing the tracer and how to use it.
 
-~sid:5 Plugins:Plugins~
+~tid:Handlers:Runtime handlers~

pie/pie/5 Plugins/Export and import.txt

@@ -0,0 +1,80 @@
+# Export and import
+
+As ~tid:Handling plugins:already mentioned~, the language can share variables between scripts, allowing almost any amount of functionality to be delegated. With such power comes a certain amount of danger as you may have no control over what the delegate will do with your variables.
+
+The code to specify a list of exports looks like this:
+```
+    // Get the exports, if any
+    const imports = [];
+    if (compiler.tokenIs(`with`)) {
+        while (true) {
+            if (compiler.nextIsSymbol(true)) {
+                const symbolRecord = compiler.getSymbolRecord();
+                imports.push(symbolRecord.name);
+                compiler.next();
+                if (!compiler.tokenIs(`and`)) {
+                    break;
+                }
+            }
+        }
+    }
+```
+It may seem odd to label the array `imports[]` but that's exactly what they will be when received by the child script Here we're specify what they are in the parent's space. It's simply a matter of listing the variable names. Here's an example:
+```
+    run Calculator with Opcode and Arg1 and Arg2
+```
+On the receiving side, the child script would start with something like this:
+```
+    import variable Opcode and variable Arg1 and variable Arg2
+```
+The first thing to say is that the names of the variable don't have to match what they were called in the parent script, but ther types must match, as must the number of shared variables. Here's the code to handle importing:
+```
+	Import: {
+
+		compile: compiler => {
+			const imports = compiler.imports;
+			let caller = EasyCoder.scripts[imports.caller];
+			const program = compiler.getProgram();
+			if (imports.length) {
+				for (const name of imports) {
+					let symbolRecord = caller.getSymbolRecord(name);
+					const thisType = compiler.nextToken();
+					const exportedType = symbolRecord.keyword;
+					if (thisType === exportedType) {
+						const command = compiler.compileVariable(symbolRecord.domain, exportedType, true);
+						const newRecord = program[compiler.getSymbols()[command.name].pc];
+						newRecord.element = symbolRecord.element;
+						newRecord.exporter = symbolRecord.exporter ? symbolRecord.exporter : caller.script;
+						newRecord.exportedName = symbolRecord.name;
+						newRecord.extra = symbolRecord.extra;
+						newRecord.isVHolder = symbolRecord.isVHolder;
+						if (symbolRecord.program) {
+							newRecord.program = symbolRecord.program.script;
+						}
+						newRecord.imported = true;
+						if (!compiler.tokenIs(`and`)) {
+							break;
+						}
+					} else {
+						throw new Error(`Mismatched import variable type for '${symbolRecord.name}'`);
+					}
+				}
+				if (compiler.tokenIs(`and`)) {
+					throw new Error(`Imports do not match exports`);
+				}
+			} else {
+				compiler.next();
+			}
+			return true;
+		},
+
+		run: program => {
+			return program[program.pc].pc + 1;
+		}
+	},
+```
+This iterates the imports. For each one, we get its record from the symbol table of the calling program and compare its type with the corresponding item in the import command as shown above. If they match we then compile the variable as if it had been a regular declaration.
+
+Next we pull out the record for the variable as `newRecord` and add information from the exported variable. The important thing is to ensure the two records keep in step with each other and there are a couple of different strategies to ensure this. One is to share the actual content of the parent and child; the other is to synchronize every time the variable is read or altered. When I translated this code from Java back in 2018 I was still new to JavaScript and I couldn't figure if sharing was even possible, so I went for the second strategy. You should not assume that _**EasyCoder**_ does it the best way; the code has been susequently governed by the rule "If it ain't broke, don't fix it".
+
+

pie/pie/5 Plugins/Handling plugins.txt

@@ -0,0 +1,196 @@
+# Handling plugins
+
+This is a fairly complex part of the language but well worth implementing as it gives a huge amount of power to the programmer.
+
+In order to compile a script, all of the domain handlers for the keywords it contains must already be present. A script can't request a plugin for its own code because by then the compiler is already running, and to add a new domain would mean suspending compilation while the new domain is loading. Not impossible, perhaps, but I'm assuming this is not implemented. So instead we use a 2-stage bootstrap where the extra domain(s) are called in by a boot script which then loads the main script, compiles and runs it.
+
+For this we need 2 keywords: `require` and `run`, plus a `module` variable type in the core language module. The first looks like this:
+```
+	Require: {
+
+		compile: compiler => {
+			const lino = compiler.getLino();
+			const type = compiler.nextToken();
+			if ([`css`, `js`].includes(type)) {
+				const url = compiler.getNextValue();
+				compiler.addCommand({
+					domain: `core`,
+					keyword: `require`,
+					lino,
+					type,
+					url
+				});
+				return true;
+			}
+			throw new Error(`File type must be 'css' or 'js'`);
+		},
+
+		// runtime
+
+		run: program => {
+			const command = program[program.pc];
+			program.require(command.type, program.getValue(command.url),
+				function () {
+					program.run(command.pc + 1);
+				});
+			return 0;
+		}
+	},
+```
+Note that program execution halts while the load is happening and resumes once it has completed.
+
+The `program.require() function used by `run(program)` looks like this:
+```
+	require: function(type, src, callback) {
+		let prefix = ``;
+		if (src[0] == `/`) {
+			prefix = window.location + `/`;
+		}
+		const element = document.createElement(type === `css` ? `link` : `script`);
+		switch (type) {
+		case `css`:
+			element.type = `text/css`;
+			element.href = `${prefix}${src}`;
+			element.rel = `stylesheet`;
+			break;
+		case `js`:
+			element.type = `text/javascript`;
+			element.src = `${prefix}${src}`;
+			break;
+		default:
+			return;
+		}
+		element.onload = function () {
+			console.log(`${Date.now() - EasyCoder.timestamp} ms: Library ${prefix}${src} loaded`);
+			callback();
+		};
+		document.head.appendChild(element);
+	},
+```
+This can load either CSS or JS files, so as well as your domains being load-on-demand capable, so also can be your CSS scripts.
+
+## Running a child script
+
+The `run()` handler looks like this:
+```
+	Run: {
+
+		compile: compiler => {
+			const lino = compiler.getLino();
+			const script = compiler.getNextValue();
+			// Get the exports, if any
+			const imports = [];
+			if (compiler.tokenIs(`with`)) {
+				while (true) {
+					if (compiler.nextIsSymbol(true)) {
+						const symbolRecord = compiler.getSymbolRecord();
+						imports.push(symbolRecord.name);
+						compiler.next();
+						if (!compiler.tokenIs(`and`)) {
+							break;
+						}
+					}
+				}
+			}
+			// Specify the module variable
+			let module;
+			if (compiler.tokenIs(`as`)) {
+				if (compiler.nextIsSymbol(true)) {
+					const moduleRecord = compiler.getSymbolRecord();
+					// moduleRecord.program = program.script;
+					compiler.next();
+					if (moduleRecord.keyword !== `module`) {
+						throw new Error(`'${moduleRecord.name}' is not a module`);
+					}
+					module = moduleRecord.name;
+				}
+			}
+			let nowait = false;
+			if (compiler.tokenIs(`nowait`)) {
+				compiler.next();
+				nowait = true;
+			}
+			const pc = compiler.getPc();
+			compiler.addCommand({
+				domain: `core`,
+				keyword: `run`,
+				lino,
+				script,
+				imports,
+				module,
+				nowait,
+				then: 0
+			});
+			// Get the 'then' code, if any
+			if (compiler.tokenIs(`then`)) {
+				const goto = compiler.getPc();
+				// Add a 'goto' to skip the 'then'
+				compiler.addCommand({
+					domain: `core`,
+					keyword: `goto`,
+					goto: 0
+				});
+				// Fixup the link to the 'then' branch
+				compiler.getCommandAt(pc).then = compiler.getPc();
+				// Process the 'then' branch
+				compiler.next();
+				compiler.compileOne(true);
+				compiler.addCommand({
+					domain: `core`,
+					keyword: `stop`
+				});
+				// Fixup the 'goto'
+				compiler.getCommandAt(goto).goto = compiler.getPc();
+			}
+			return true;
+		},
+
+		// runtime
+
+		run: program => {
+			program.nextPc = program.pc + 1;
+			program.runScript(program);
+			return 0;
+		}
+```
+This may seem a little complex but it deals with several things. As well as just running a script you also have the option of
+
+> a) adding a `with` clause to hand some of your variables to the child script
+> b) specifying an action to occur after the child script has completed
+
+The first of these is equivalent to passing variables by reference in other programming languages, except it's not a subroutine or function that we're sharing with; it's a completely different script that's potentially running concurrently with the first one. Having a shared variable space is a powerful feature; I'll describe it in more detail later.
+
+Since you are launching an independent program that could be sharing some of your variables, you may not be able to interact with it until it has completed some initialization. For example, imagine a child script whose sole job is to fetch the weather from a remote server when it receives a message from the parent. So we add a command that the child script runs when it is ready to interact with the parent - in this case to receive messages. I use `set ready` but you can choose any suitable syntax. The parent will block until this command is run.
+
+The use of `nowait` overrides this functionality and allows the calling script to continue immediately.
+
+Here is the `runScript(program)` function from _**EasyCoder**_:
+```
+	runScript: function (program) {
+		const command = program[program.pc];
+		const script = program.getValue(command.script);
+		const imports = command.imports;
+		imports.caller = program.script;
+		const moduleRecord = command.module ? program.getSymbolRecord(command.module) : null;
+		try {
+			EasyCoder.tokeniseAndCompile(script.split(`\n`), imports, moduleRecord, this.script, command.then);
+		} catch (err) {
+			EasyCoder.reportError(err, program, program.source);
+			if (program.onError) {
+				program.run(program.onError);
+			} else {
+				let parent = EasyCoder.scripts[program.parent];
+				if (parent && parent.onError) {
+					parent.run(parent.onError);
+				}
+			}
+			return;
+		}
+		if (command.nowait) {
+			EasyCoder.run(program.nextPc);
+		}
+	},
+```
+You can see this invokes the tokenizer and compiler to process the new script and then run it. The largest part of the function is in dealing with errors.
+
+~tid:Export and import~

pie/pie/5 Plugins/content.txt

@@ -1,4 +1,233 @@
-# Plugins
+# Plugins and child scripts
 
-## An example plugin
+Plugins are JavaScript files containing domain handler code in a fixed format. The best way of illustrating this format is to write a plugin for a hypothetical domain. Let's assume your problem domain is that of logistics, and that one of your custom variable types is a `box`, which has features that make it useful when packing items for transport. The `box` has dimensions and weight so we need to be able to create a box, set up its properties and return information when requested. Here's a simple script that exercises all the features:
+```
+    box Box52
+    
+    create Box52
+        width 60
+        depth 40
+        height 40
+        weight 20
+    
+    print the volume of Box52
+    if Box52 is heavy print `Heavy: ` cat the weight of Box 52
+    stop
+```
+Here's the complete plugin in a form that's compatible with _**EasyCoder**_. To adapt it for you own language you probably need to do no more than globally change _**EasyCoder**_ into the name of your project. The filname is `box.js`.
+```
+const EasyCoder_Box = {
 
+	name: `EasyCoder_Box`,
+
+	BOX: {
+
+		compile: compiler => {
+			compiler.compileVariable(`box`, `box`);
+			return true;
+		},
+
+		run: program => {
+			return program[program.pc].pc + 1;
+		}
+	},
+
+	Create: {
+
+		compile: compiler => {
+			const lino = compiler.getLino();
+			if (compiler.nextIsSymbol())
+			{
+				const symbolRecord = compiler.getSymbolRecord();
+				const keyword = symbolRecord.keyword;
+				if (keyword === `box`) {
+                    let width;
+                    let depth;
+                    let height;
+                    let weight;
+                    compiler.next();
+                    while (true)
+                    {
+                        switch (compiler.getToken()) {
+                        case `width`:
+                            width = compiler.getNextValue();
+                            break;
+                        case `depth`:
+                            depth = compiler.getNextValue();
+                            break;
+                        case `height`:
+                            height = compiler.getNextValue();
+                            break;
+                        case `weight`:
+                            weight = compiler.getNextValue();
+                            break;
+                        default:
+                            compiler.addCommand({
+                                domain: `box`,
+                                keyword: `create`,
+                                name: symbolRecord.name,
+                                lino,
+                                width,
+                                depth,
+                                height,
+                                weight
+                            });
+                            return true;
+                        }
+                    }
+                 }
+			}
+			return false;
+		},
+
+		run: program => {
+			const command = program[program.pc];
+			const width = program.getValue(command.width);
+			const depth = program.getValue(command.depth);
+			const height = program.getValue(command.height);
+			const weight = program.getValue(command.weight);
+			const box = program.getSymbolRecord(command.name);
+			box.value[box.index] = {
+                width,
+                depth,
+                height,
+                weight
+			};
+			return command.pc + 1;
+		}
+	},
+
+	// Values
+	value: {
+
+		compile: compiler => {
+            compiler.skip(`the`);
+            const type = compiler.getToken();
+            if ([`width`, `depth`, `height`, `weight`, `volume`].includes(type)) {
+                compiler.next();
+                compiler.skip(`of`);
+                const name = compiler.getToken();
+                compiler.next();
+                return {
+                    domain: `box`,
+                    name,
+                    type
+                };
+            };
+            return null;
+		},
+
+		get: (program, value) => {
+            const symbolRecord = program.getSymbolRecord(value.name);
+            const record = symbolRecord.value[symbolRecord.index];
+            let content;
+            switch (value.type) {
+                case `width`:
+                    content = record.width;
+                    break;
+                case `depth`:
+                    content = record.depth;
+                    break;
+                case `height`:
+                    content = record.height;
+                    break;
+                case `weight`:
+                    content = record.weight;
+                    break;
+                case `volume`:
+                    content = record.width * record.depth * record.height / 100 / 100 / 100;
+                    break;
+            }
+            return {
+                type: `constant`,
+                numeric: true,
+                content
+            };
+			return value;
+		}
+	},
+
+	// Conditions
+	condition: {
+
+		compile: compiler => {
+            if (compiler.isSymbol()) {
+				const symbolRecord = compiler.getSymbolRecord();
+				if (symbolRecord.keyword === `box`) {
+					if (compiler.nextTokenIs(`is`)) {
+						let sense = true;
+						if (compiler.nextTokenIs(`not`)) {
+							compiler.next();
+							sense = false;
+						}
+						if (compiler.tokenIs(`heavy`)) {
+							compiler.next();
+							return {
+								domain: `box`,
+								type: `heavy`,
+								name: symbolRecord.name,
+								sense
+							}
+						}
+					}
+					return null;
+				}
+            }
+		},
+
+		test: (program, condition) => {
+            if (condition.type === `heavy`) {
+                const record = program.getSymbolRecord(condition.name);
+                const heavy = (record.value[record.index].weight >= 25);
+                return condition.sense ? heavy : !heavy;
+            }
+            return false;
+        }
+    },
+
+	// Dispatcher
+	getHandler: name => {
+		switch (name) {
+		case `box`:
+			return EasyCoder_Box.BOX;
+		case `create`:
+			return EasyCoder_Box.Create;
+		default:
+			return false;
+		}
+	},
+
+	run: program => {
+		const command = program[program.pc];
+		const handler = EasyCoder_Box.getHandler(command.keyword);
+		if (!handler) {
+			program.runtimeError(command.lino, `Unknown keyword '${command.keyword}' in 'box' package`);
+		}
+		return handler.run(program);
+	}
+};
+
+// eslint-disable-next-line no-unused-vars
+EasyCoder.domain.box = EasyCoder_Box;
+```
+At the start is a property giving the name of the module. This is for the convenience of the programmer; it may help to locate the code during debugging.
+
+Next there are handler objects for the 2 keywords implemented in this domain; `box` and `create`. Each of these contains 2 functions; `compile(compiler)` and `run(program)`.
+
+The `box` command is a variable declaration and is implemented in a standard way.
+
+The `create` command accepts the syntax shown in the example at the top of this section, where the item is first named and then followed by a set of attributes, which can be given in any order. The function returns an object with all these items.
+
+At runtime, the command is read from the program array and the various items are extracted. An object is built to contain the current values of the items and is written to the variable.
+
+Next we have the value handler object. This contains the compiler function `compile(compiler)` and the runtime function `get(program, value)`. Between them they provide the means to access any of the properties of the box variable, plus the volume, which is computed on the fly at runtime.
+
+After this is the condition handler object. This contains the compiler function `compile(compiler)` and the runtime function `test(program, condition)`. Between then they implement a single test, which returns `true` if the box weight exceeds a fixed value. Note that the core condition handler will already have checked for `not`, which if given will negate the test, as in `if Box52 is not heavy ...`
+
+Now we come to the `getHandler(name)`, the dispatcher function, which returns the handler object for any given keyword in this domain (or null if an unknown keyword is given).
+
+This is followed by the runtime function that is called by the main runtime to execute the command at the current program counter.
+
+Finally, the module posts itself into the list of domains held by the main program module, allowing the compiler to include it in searches for a suitable handler for any given keyword.
+
+~tid:Handling plugins~

pie/pie/home/content.txt

@@ -1,26 +1,26 @@
 # Programming In English
 
-This book describes how to build a versatile computer language whose scripts look like a series of step-by-step English commands similar to cookery recipes, navigation instructions or car maintenance manuals. The language will be English stripped to the minimum; terse but understandable by anyone familiar with the problem domain. The environment will be that of a web browser and the language will be a replacement for JavaScript, permitting scripts to be embedded in any web page then compiled and run on the fly as the page loads.
+This book describes how to build a versatile computer language whose scripts look like a series of step-by-step English commands similar to cookery recipes, navigation instructions or car maintenance manuals. The syntax will be English stripped to the minimum; terse but understandable by anyone familiar with the problem domain. The environment will be that of a web browser and the language will be a comprehensive, capable and easy to use replacement for JavaScript, permitting scripts to be embedded in any web page then compiled and run on the fly as the page loads.
 
 Programming is about communication; specifically about getting computers to do things. I'm assuming that you, my reader, are a programmer and that among your circle of friends and aquaintances there are others with whom you share specialized skills you've worked long and hard to gain.
 
 You'll also know a lot of other people who aren't programmers, most of whom find your interests and skills baffling or even frightening. For them, computers are just tools to be used, preferably without the need to understand how they work any more than most of us know about what happens under the hood of a car, or indeed anywhere outside own own areas of speciality.
 
-Just as non-programmers find it hard to understand how programmers think, we often fail to fully appreciate the complexities of the world outside the computer, for which we build software systems. Better understanding makes for better, more reliable software, and communication is the key to understanding.
+Just as non-programmers find it hard to understand how programmers think, we often fail to fully appreciate the complexities of the world outside the computer, for which we build software systems. We have a regrettable tendency to disregard advice from users of a system because we all too often assume we know better than those users. Better understanding makes for better, more reliable software, and better communication is the key to better understanding.
 
 ## What is programming?
 
-Computers are literal devices. They blindly follow the instructions given, without stopping to question if you really meant what you said. A programmer is someone who has the skill to create sets of instructions that are unambiguous, so the computer will do exactly what is intended. In order for this to happen, instructions are written in a computer _language_; a formal syntax that's understood by a computer and more importantly by the programmers tasked with ensuring the right things are done. Many computer languages have been invented, most of which are much more similar to each other than any of them are to human languages. But just as human language develops specialized dialects to suit the needs of a particular group, whether it be chemists, lawyers or footballers, new computer languages can always be created to provide a better match to problem domains of one kind or another.
+Computers are literal devices. They blindly follow the instructions given, without stopping to question if you really meant what you said. A programmer is someone who has the skill to create sets of instructions that are unambiguous, so the computer will do exactly what is intended. In order for this to happen, instructions are written in a computer _language_; a formal syntax that's understood by a computer and more importantly by the programmers tasked with ensuring the right things are done. Many computer languages have been invented, most of which are much more similar to each other than any of them are to human languages. And just as human language develops specialized dialects to suit the needs of a particular group, whether it be chemists, lawyers or footballers, new computer languages are always being created to provide a better match to problem domains of one kind or another.
 
 ## Why is programming so difficult?
 
-Most computer languages are less than half a century old. Programming started by devising symbolic code that offered a human-readable alternative to coding in the hard-to-remember numbers required by the computing devices themselves. As time went by, more and more layers of abstraction were added, but in most cases they retained a fundamental characteristic, being more or less a system of mathematical symbols and expressions.
+Most if not all of our current computer languages are less than half a century old. Programming started by devising symbolic code that offered a human-readable alternative to coding in the hard-to-remember numbers required by the computing devices themselves. As time went by, more and more layers of abstraction were added, but in most cases they retained a fundamental characteristic, being more or less a system of mathematical symbols and expressions.
 
 Take a few lines of any computer program written in C/C++, Java, Python or JavaScript, and try to read it out loud. It's almost impossible to do it in such a way that another human being - even another programmer - can make sense of what you are saying. The only sensible way to communicate computer code to another person is in writing. And this is one reason why non-programmers find programming so difficult. We learn to speak before we learn to read; most of us can "hear" written text when we see it and many people sub-vocalize to help them process the meaning, without even being aware of it. For them, coding feels unnatural; something to be left to those strange geeks.
 
-It's all a matter of motivation. As programmers, you and I may be happy to live in a silent world of cryptic formulae and text, but the majority of people aren't built like that and for them it's a complete turn-off. It's not that they _can't_ become programmers; they just don't have any motivation for doing so. In fact, nearly everybody is a programmer, quite capable of handling cooking recipies or step by step car maintenance instructions that resemble simple computer programs. The human species developed complex societies long before we invented computer language. Lawyers and engineers have the mental discipline to organise facts in a coherent manner so that the outcome of an action can be safely predicted, but for some reason, when it comes to computers we suddenly feel the need to invent a whole new way of expressing things that's competely alien to our natural ways of thinking. Small wonder there's a shortage of good programmers.
+It's all a matter of motivation. As programmers, you and I may be happy to live in a silent world of cryptic formulae and text, but the majority of people aren't built like that and for them it's a complete turn-off. It's not that they _can't_ become programmers; they just don't have any motivation for doing so. In fact, nearly everybody is a programmer, quite capable of handling cooking recipies or step by step car maintenance instructions that resemble simple computer programs. The human species developed complex societies long before we invented computer language. There were programmes long before there was programming. Lawyers and engineers have the mental discipline to organise facts in a coherent manner so that the outcome of an action can be safely predicted, but for some reason, when it comes to computers we assume it's necessary to use a way of expressing things that's competely alien to our natural modes of thinking. Small wonder there's a shortage of good programmers.
 
-It gets worse. Computer software is structurally complex, requiring a huge amount of training and experience to understand how a large program works or even where it begins. As a result, maintenance is often a time bomb waiting to blow up large systems. By the time a few years have passed, the original designers of a software system are long gone and maintenance is often left in the hands of people who are inadequately trained or for whom this is only one of many other responsibilities. Lacking the insights posessed by the original design team they inevitably make mistakes, causing invisible damage to the whole edifice. Slowly but surely the system begins to decay, with every attempt to fix it creating further problems. In the end, to avoid catastrophic failure the system will have to be replaced, often well before its originally projected lifetime.
+It gets worse. Computer software is structurally complex, requiring a huge amount of training and experience to understand how a large program works or even where it begins. As a result, maintenance is often a time bomb waiting to blow up big systems. By the time a few years have passed, the original designers of a software system are long gone and maintenance is often left in the hands of people who are inadequately trained or for whom this is only one of many other responsibilities. Lacking the insights posessed by the original design team they inevitably make mistakes, causing invisible damage to the whole edifice. Slowly but surely the system begins to decay, with every attempt to fix it creating further problems. In the end, to avoid catastrophic failure the system will have to be replaced, often well before its originally projected lifetime.
 
 For centuries we have built complex and robust human societies without the need for computers or software. Language had a huge, vital part to play in this; without it we'd still be living in caves.
 
@@ -43,6 +43,8 @@ And finally, before getting started, **_EasyCoder_** has its own website at [htt
 
 This book can be read in a linear fashion; at the bottom of each page is a link to the next. Alternatively, you can choose any page from the table of contents below.
 
+I'm assuming you have some experience with JavaScript and ES6. You don't need to be an expert but complete beginners will find it a little hard going in places as I expect you to be able to read sections of code without my having to spell out everything line by line. When I started the _**EasyCoder**_ project my level of JS knowledge was pretty low (and it shows in places).
+
 ~sid:2 Designing a language:Designing a language~
 
 > ~stid:2 Designing a language/Environment:The coding environment~
@@ -67,7 +69,7 @@ This book can be read in a linear fashion; at the bottom of each page is a link
 
 > ~stid:3 Compilation/Variables:Compiling variables~
 
-> ~stid:3 Compilation/Handlers:Keyword handlers~
+> ~stid:3 Compilation/Keywords:Keyword handlers~
 
 > ~stid:3 Compilation/If:The `if` handler~
 
@@ -81,4 +83,8 @@ This book can be read in a linear fashion; at the bottom of each page is a link
 
 ~sid:4 Runtime:The runtime engine~
 
-~sid:5 Plugins:Creating plugin modules~
+~sid:5 Plugins~
+
+~stid:5 Plugins/Handling plugins:Handling plugins~
+
+~stid:5 Plugins/Export and import:Export and import~