aboutsummaryrefslogtreecommitdiff
path: root/docs/doc/paradigms.html
diff options
context:
space:
mode:
authorMarshall Lochbaum <mwlochbaum@gmail.com>2021-07-18 17:53:37 -0400
committerMarshall Lochbaum <mwlochbaum@gmail.com>2021-07-18 17:53:37 -0400
commit7e0e38bd155fab76fa3b6776f9184611d044903d (patch)
tree9cbd13e8aae249cb97b1dd2b22a084817093890c /docs/doc/paradigms.html
parentbbecd676b7c127fead3ef172bbae3ddf2fb7f19a (diff)
Finish lexical scope documentation
Diffstat (limited to 'docs/doc/paradigms.html')
-rw-r--r--docs/doc/paradigms.html2
1 files changed, 1 insertions, 1 deletions
diff --git a/docs/doc/paradigms.html b/docs/doc/paradigms.html
index 750e2302..9e2538f2 100644
--- a/docs/doc/paradigms.html
+++ b/docs/doc/paradigms.html
@@ -14,7 +14,7 @@
<p>Dynamic types and garbage collection introduce overhead relative to a statically-typed or manually managed language. The impact of this overhead can be greatly reduced with array programming, because an array of numbers or characters can be stored as a single unit of memory and processed with functions specialized to its element type.</p>
<h2 id="styles">Styles</h2>
<p>BQN is designed for <strong>array</strong> programming. The array is its only built-in collection type and it has many primitives designed to work with arrays.</p>
-<p>BQN is okay for <strong>imperative</strong> programming. Blocks are lists of statements. Variables can be modified with <code><span class='Gets'>↩</span></code>, and while there are no truly global variables, lexical scoping allows variables at the top level of a file, which are similar (<code><span class='Function'>•Import</span></code> with no left argument saves and reuses results, so that data can be shared between files by loading the same namespace-defining file in each). BQN doesn't directly support <strong>structured</strong> programming (which refers to a particular way to structure programs; it also doesn't have a Goto statement, the &quot;unstructured&quot; alternative when the term was coined). However, its first-class functions allow a reasonably similar <a href="control.html">imitation</a> of control structures.</p>
+<p>BQN is okay for <strong>imperative</strong> programming. Blocks are lists of statements. Variables can be modified with <code><span class='Gets'>↩</span></code>, and while there are no truly global variables, <a href="lexical.html">lexical scoping</a> allows variables at the top level of a file, which are similar (<code><span class='Function'>•Import</span></code> with no left argument saves and reuses results, so that data can be shared between files by loading the same namespace-defining file in each). BQN doesn't directly support <strong>structured</strong> programming (which refers to a particular way to structure programs; it also doesn't have a Goto statement, the &quot;unstructured&quot; alternative when the term was coined). However, its first-class functions allow a reasonably similar <a href="control.html">imitation</a> of control structures.</p>
<p><strong>Functional</strong> programming is a term with many meanings. Using the terms defined in the <a href="functional.html">functional programming document</a>, BQN supports first-class functions and function-level programming, allows but doesn't encourage pure functional programming, and does not support typed functional programming. BQN uses <strong>lexical scope</strong> and has full support for <strong>closures</strong>. In this way BQN is very similar to Lisp, although it lacks Lisp's macro system.</p>
<p>BQN has excellent <a href="tacit.html">support</a> for <strong>tacit</strong> or <strong>point-free</strong> programming, with <a href="train.html">trains</a> and intuitive symbols for combinators making it much easier to work with (in my opinion) than other languages that support this style. It's near-universally considered a poor choice to implement entire programs in a tacit style, so this paradigm is best used as a small-scale tool within a style like functional or object-oriented programming.</p>
<p>BQN uses <a href="namespace.html">namespaces</a> as <strong>modules</strong> to organize code; the only possible interaction with a module is by its exported variables. There doesn't seem to be a name for this paradigm, but there should be.</p>