Fixes suggested by readers

contents/_build/html/_sources/errors.ipynb

@@ -257,7 +257,7 @@
  "]dinput\n",
  "g ← { \n",
  " 3::'out of range' ⍝ Error guard, catching INDEX ERROR\n",
- " h ⍺⊃⍵ ⍝ No longer a tail call, due to precense of error guard\n",
+ " h ⍺⊃⍵ ⍝ No longer a tail call, due to presense of error guard\n",
  "}"
  ]
  },

contents/_build/html/_sources/functions.ipynb

@@ -14,7 +14,7 @@
  "cell_type": "markdown",
  "metadata": {},
  "source": [
- "Until now, we've mainly used APL as a toolkit for array manipulation using its built-in primitives. Sure, it goes a long way, but to fully take advantage of it, we also need to be able to create our own functions and operators. Fortunately, the syntax -- if we can even call it that -- for user-defined functions, is super-simple. As someone said on the APL Orchard chat room, all you need to do is \"slap curly braces around your code, and you're done\". It's not _quite_ that simple, but not far from it.\n",
+ "Until now, we've mainly used APL as a toolkit for array manipulation using its built-in primitives. Sure, it goes a long way, but to fully take advantage of it, we also need to be able to create our own functions and operators. Fortunately, the syntax -- if we can even call it that -- for user-defined functions, is super-simple. As someone said on the APL Orchard chat room, all you need to do is \"slap curly braces around your code, and you're done\". It's not _quite_ that simple, but not too far off.\n",
  "\n",
  "The definition of a _dfn_ (direct function) is enclosed in a pair of curly braces. It's what's known as an anonymous function, or a lambda, in other languages, meaning that there is no syntactic sugar for naming a function beyond ordinary assignment using _Gets_, `←`:\n",
  "\n",
@@ -26,17 +26,17 @@
  "\n",
  "First a bit of unavoidable [yak shaving](https://xkcd.com/349/): if a dfn fits entirely on a single line, you can type it out directly in the RIDE IDE. So far, so expected. If your dfn extends across multiple lines, you can't (at the time of writing) just type it in. Dyalog is working on enhancing this. \n",
  "\n",
- "Instead, in order to enter such a function, you need to enter:\n",
+ "Instead, the most convenient way to enter such a function is to say\n",
  "\n",
  " )ed name\n",
  " \n",
- "if you want to create a function called `name`. RIDE will open its function editor and let you enter your code there. Once you want to test your function, you first need to save it, which in APL-speak is called \"to fix your function\". The default way (and you're unlikely to ever discover this by yourself) to fix (save) your function is to hit \"escape\". Fortunately -- and I recommend you do so right now -- RIDE allows you to re-bind keystrokes by clicking on the little keyboard symbol in the top-right corner.\n",
+ "if you want to create a function called `name`. RIDE will open its function editor and let you enter your code there. Once you want to test your function, you first need to save it, which in APL-speak is called \"to fix your function\". The default way (and you're unlikely to ever discover this by yourself) to fix (save) your function is to hit \"escape\". Yes, really. Fortunately -- and I recommend you do so right now -- RIDE allows you to re-bind keystrokes by clicking on the little keyboard symbol in the top-right corner.\n",
  "\n",
- "Locate the row that says \"Fix the current function\" and map that to the key combo that is save on your platform. And whilst you're there, make a note of the keys binding to \"Forward\" and \"Backward\" -- they default to ctrl-shift-enter and ctrl-shift-backspace. In the REPL, these mean forward/back in the history of executed lines, like the arrow keys in the shell. The arrow keys instead moves up and down spatially, in the _output_. You might also want to rebind \"Strong interrupt\" to ctrl-c while you're at it.\n",
+ "Locate the row that says \"Fix the current function\" and map that to the key combo that is `save` on your platform. And whilst you're there, make a note of the keys binding to \"Forward\" and \"Backward\" -- they default to ctrl-shift-enter and ctrl-shift-backspace. In the REPL, these mean forward/back in the history of executed lines, like the arrow keys in the shell. The arrow keys instead moves up and down spatially, in the _output_, still, to me an incomprehensible design decision. You might also want to rebind \"Strong interrupt\" to ctrl-c while you're at it.\n",
  "\n",
  "The other thing to note is that in RIDE there is no visual cue that an editor window contains unsaved changes. This is sure to bite you sooner or later.\n",
  "\n",
- "In a Jupyter notebook, like here, the will likely feel a bit more familiar. The only quirk is that in order to enter a multi-line dfn, you need to start the cell with `]dinput`, which shouldn't be used in RIDE.\n",
+ "In a Jupyter notebook, like here, entering functions might feel a bit more familiar: just type them into a cell. The only quirk is that in order to enter a multi-line dfn, you need to start the cell with `]dinput` (which isn't needed in a RIDE edit window). You _can_ actually use the `]dinput` way of entering a multi-line function in the interpreter REPL, too, but (in my opinion) it's rather cumbersome unless you're just cutting and pasting from somewhere else. In the upcoming (at the time of writing) version 18.1 there is experimental support for being able to type in multi-line functions directly in the REPL, similar to how that works in Python's REPL.\n",
  "\n",
  "First, our now familiar prelude:"
  ]

contents/_build/html/errors.html

@@ -484,7 +484,7 @@ <h1>Error handling<a class="headerlink" href="#error-handling" title="Permalink
 <div class="highlight-APL notranslate"><div class="highlight"><pre><span></span><span class="sr">]</span><span class="nv">dinput</span>
 <span class="nv">g</span> <span class="kd">←</span> <span class="kt">{</span> 
  <span class="m">3</span><span class="bp">::</span><span class="s1">&#39;out of range&#39;</span> <span class="c1">⍝ Error guard, catching INDEX ERROR</span>
- <span class="nv">h</span> <span class="bp">⍺</span><span class="o">⊃</span><span class="bp">⍵</span> <span class="c1">⍝ No longer a tail call, due to precense of error guard</span>
+ <span class="nv">h</span> <span class="bp">⍺</span><span class="o">⊃</span><span class="bp">⍵</span> <span class="c1">⍝ No longer a tail call, due to presense of error guard</span>
 <span class="kt">}</span>
 </pre></div>
 </div>

contents/_build/html/functions.html

@@ -403,22 +403,22 @@ <h1>Direct functions and operators<a class="headerlink" href="#direct-functions-
 <div><p>I made up the term “object-oriented,” and I can tell you I did not have C++ in mind.
 –<em>Alan Kay</em></p>
 </div></blockquote>
-<p>Until now, we’ve mainly used APL as a toolkit for array manipulation using its built-in primitives. Sure, it goes a long way, but to fully take advantage of it, we also need to be able to create our own functions and operators. Fortunately, the syntax – if we can even call it that – for user-defined functions, is super-simple. As someone said on the APL Orchard chat room, all you need to do is “slap curly braces around your code, and you’re done”. It’s not <em>quite</em> that simple, but not far from it.</p>
+<p>Until now, we’ve mainly used APL as a toolkit for array manipulation using its built-in primitives. Sure, it goes a long way, but to fully take advantage of it, we also need to be able to create our own functions and operators. Fortunately, the syntax – if we can even call it that – for user-defined functions, is super-simple. As someone said on the APL Orchard chat room, all you need to do is “slap curly braces around your code, and you’re done”. It’s not <em>quite</em> that simple, but not too far off.</p>
 <p>The definition of a <em>dfn</em> (direct function) is enclosed in a pair of curly braces. It’s what’s known as an anonymous function, or a lambda, in other languages, meaning that there is no syntactic sugar for naming a function beyond ordinary assignment using <em>Gets</em>, <code class="docutils literal notranslate"><span class="pre">←</span></code>:</p>
 <div class="highlight-apl notranslate"><div class="highlight"><pre><span></span><span class="nv">name</span> <span class="kd">←</span> <span class="kt">{</span> 
  <span class="c1">⍝ expressions</span>
 <span class="kt">}</span>
 </pre></div>
 </div>
 <p>First a bit of unavoidable <a class="reference external" href="https://xkcd.com/349/">yak shaving</a>: if a dfn fits entirely on a single line, you can type it out directly in the RIDE IDE. So far, so expected. If your dfn extends across multiple lines, you can’t (at the time of writing) just type it in. Dyalog is working on enhancing this.</p>
-<p>Instead, in order to enter such a function, you need to enter:</p>
+<p>Instead, the most convenient way to enter such a function is to say</p>
 <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>)ed name
 </pre></div>
 </div>
-<p>if you want to create a function called <code class="docutils literal notranslate"><span class="pre">name</span></code>. RIDE will open its function editor and let you enter your code there. Once you want to test your function, you first need to save it, which in APL-speak is called “to fix your function”. The default way (and you’re unlikely to ever discover this by yourself) to fix (save) your function is to hit “escape”. Fortunately – and I recommend you do so right now – RIDE allows you to re-bind keystrokes by clicking on the little keyboard symbol in the top-right corner.</p>
-<p>Locate the row that says “Fix the current function” and map that to the key combo that is save on your platform. And whilst you’re there, make a note of the keys binding to “Forward” and “Backward” – they default to ctrl-shift-enter and ctrl-shift-backspace. In the REPL, these mean forward/back in the history of executed lines, like the arrow keys in the shell. The arrow keys instead moves up and down spatially, in the <em>output</em>. You might also want to rebind “Strong interrupt” to ctrl-c while you’re at it.</p>
+<p>if you want to create a function called <code class="docutils literal notranslate"><span class="pre">name</span></code>. RIDE will open its function editor and let you enter your code there. Once you want to test your function, you first need to save it, which in APL-speak is called “to fix your function”. The default way (and you’re unlikely to ever discover this by yourself) to fix (save) your function is to hit “escape”. Yes, really. Fortunately – and I recommend you do so right now – RIDE allows you to re-bind keystrokes by clicking on the little keyboard symbol in the top-right corner.</p>
+<p>Locate the row that says “Fix the current function” and map that to the key combo that is <code class="docutils literal notranslate"><span class="pre">save</span></code> on your platform. And whilst you’re there, make a note of the keys binding to “Forward” and “Backward” – they default to ctrl-shift-enter and ctrl-shift-backspace. In the REPL, these mean forward/back in the history of executed lines, like the arrow keys in the shell. The arrow keys instead moves up and down spatially, in the <em>output</em>, still, to me an incomprehensible design decision. You might also want to rebind “Strong interrupt” to ctrl-c while you’re at it.</p>
 <p>The other thing to note is that in RIDE there is no visual cue that an editor window contains unsaved changes. This is sure to bite you sooner or later.</p>
-<p>In a Jupyter notebook, like here, the will likely feel a bit more familiar. The only quirk is that in order to enter a multi-line dfn, you need to start the cell with <code class="docutils literal notranslate"><span class="pre">]dinput</span></code>, which shouldn’t be used in RIDE.</p>
+<p>In a Jupyter notebook, like here, entering functions might feel a bit more familiar: just type them into a cell. The only quirk is that in order to enter a multi-line dfn, you need to start the cell with <code class="docutils literal notranslate"><span class="pre">]dinput</span></code> (which isn’t needed in a RIDE edit window). You <em>can</em> actually use the <code class="docutils literal notranslate"><span class="pre">]dinput</span></code> way of entering a multi-line function in the interpreter REPL, too, but (in my opinion) it’s rather cumbersome unless you’re just cutting and pasting from somewhere else. In the upcoming (at the time of writing) version 18.1 there is experimental support for being able to type in multi-line functions directly in the REPL, similar to how that works in Python’s REPL.</p>
 <p>First, our now familiar prelude:</p>
 <div class="cell tag_hide-output docutils container">
 <div class="cell_input docutils container">

contents/_build/jupyter_execute/errors.apl

@@ -40,7 +40,7 @@ fnew ← { ⍝ Now correct
 ]dinput
 g ← { 
  3::'out of range' ⍝ Error guard, catching INDEX ERROR
- h ⍺⊃⍵ ⍝ No longer a tail call, due to precense of error guard
+ h ⍺⊃⍵ ⍝ No longer a tail call, due to presense of error guard
 }
 
 ]dinput

contents/_build/jupyter_execute/errors.ipynb

@@ -243,7 +243,7 @@
  "]dinput\n",
  "g ← { \n",
  " 3::'out of range' ⍝ Error guard, catching INDEX ERROR\n",
- " h ⍺⊃⍵ ⍝ No longer a tail call, due to precense of error guard\n",
+ " h ⍺⊃⍵ ⍝ No longer a tail call, due to presense of error guard\n",
  "}"
  ]
  },

contents/_build/jupyter_execute/functions.ipynb

@@ -14,7 +14,7 @@
  "cell_type": "markdown",
  "metadata": {},
  "source": [
- "Until now, we've mainly used APL as a toolkit for array manipulation using its built-in primitives. Sure, it goes a long way, but to fully take advantage of it, we also need to be able to create our own functions and operators. Fortunately, the syntax -- if we can even call it that -- for user-defined functions, is super-simple. As someone said on the APL Orchard chat room, all you need to do is \"slap curly braces around your code, and you're done\". It's not _quite_ that simple, but not far from it.\n",
+ "Until now, we've mainly used APL as a toolkit for array manipulation using its built-in primitives. Sure, it goes a long way, but to fully take advantage of it, we also need to be able to create our own functions and operators. Fortunately, the syntax -- if we can even call it that -- for user-defined functions, is super-simple. As someone said on the APL Orchard chat room, all you need to do is \"slap curly braces around your code, and you're done\". It's not _quite_ that simple, but not too far off.\n",
  "\n",
  "The definition of a _dfn_ (direct function) is enclosed in a pair of curly braces. It's what's known as an anonymous function, or a lambda, in other languages, meaning that there is no syntactic sugar for naming a function beyond ordinary assignment using _Gets_, `←`:\n",
  "\n",
@@ -26,17 +26,17 @@
  "\n",
  "First a bit of unavoidable [yak shaving](https://xkcd.com/349/): if a dfn fits entirely on a single line, you can type it out directly in the RIDE IDE. So far, so expected. If your dfn extends across multiple lines, you can't (at the time of writing) just type it in. Dyalog is working on enhancing this. \n",
  "\n",
- "Instead, in order to enter such a function, you need to enter:\n",
+ "Instead, the most convenient way to enter such a function is to say\n",
  "\n",
  " )ed name\n",
  " \n",
- "if you want to create a function called `name`. RIDE will open its function editor and let you enter your code there. Once you want to test your function, you first need to save it, which in APL-speak is called \"to fix your function\". The default way (and you're unlikely to ever discover this by yourself) to fix (save) your function is to hit \"escape\". Fortunately -- and I recommend you do so right now -- RIDE allows you to re-bind keystrokes by clicking on the little keyboard symbol in the top-right corner.\n",
+ "if you want to create a function called `name`. RIDE will open its function editor and let you enter your code there. Once you want to test your function, you first need to save it, which in APL-speak is called \"to fix your function\". The default way (and you're unlikely to ever discover this by yourself) to fix (save) your function is to hit \"escape\". Yes, really. Fortunately -- and I recommend you do so right now -- RIDE allows you to re-bind keystrokes by clicking on the little keyboard symbol in the top-right corner.\n",
  "\n",
- "Locate the row that says \"Fix the current function\" and map that to the key combo that is save on your platform. And whilst you're there, make a note of the keys binding to \"Forward\" and \"Backward\" -- they default to ctrl-shift-enter and ctrl-shift-backspace. In the REPL, these mean forward/back in the history of executed lines, like the arrow keys in the shell. The arrow keys instead moves up and down spatially, in the _output_. You might also want to rebind \"Strong interrupt\" to ctrl-c while you're at it.\n",
+ "Locate the row that says \"Fix the current function\" and map that to the key combo that is `save` on your platform. And whilst you're there, make a note of the keys binding to \"Forward\" and \"Backward\" -- they default to ctrl-shift-enter and ctrl-shift-backspace. In the REPL, these mean forward/back in the history of executed lines, like the arrow keys in the shell. The arrow keys instead moves up and down spatially, in the _output_, still, to me an incomprehensible design decision. You might also want to rebind \"Strong interrupt\" to ctrl-c while you're at it.\n",
  "\n",
  "The other thing to note is that in RIDE there is no visual cue that an editor window contains unsaved changes. This is sure to bite you sooner or later.\n",
  "\n",
- "In a Jupyter notebook, like here, the will likely feel a bit more familiar. The only quirk is that in order to enter a multi-line dfn, you need to start the cell with `]dinput`, which shouldn't be used in RIDE.\n",
+ "In a Jupyter notebook, like here, entering functions might feel a bit more familiar: just type them into a cell. The only quirk is that in order to enter a multi-line dfn, you need to start the cell with `]dinput` (which isn't needed in a RIDE edit window). You _can_ actually use the `]dinput` way of entering a multi-line function in the interpreter REPL, too, but (in my opinion) it's rather cumbersome unless you're just cutting and pasting from somewhere else. In the upcoming (at the time of writing) version 18.1 there is experimental support for being able to type in multi-line functions directly in the REPL, similar to how that works in Python's REPL.\n",
  "\n",
  "First, our now familiar prelude:"
  ]

contents/errors.ipynb

@@ -257,7 +257,7 @@
  "]dinput\n",
  "g ← { \n",
  " 3::'out of range' ⍝ Error guard, catching INDEX ERROR\n",
- " h ⍺⊃⍵ ⍝ No longer a tail call, due to precense of error guard\n",
+ " h ⍺⊃⍵ ⍝ No longer a tail call, due to presense of error guard\n",
  "}"
  ]
  },