•Eval doesn't exist except in dzaima/BQN

2 files changed, 2 insertions, 2 deletions

diff --git a/doc/paradigms.md b/doc/paradigms.md
index c20cf289..37189854 100644
--- a/doc/paradigms.md
+++ b/doc/paradigms.md
@@ -30,7 +30,7 @@ BQN uses [namespaces](namespace.md) as **modules** to organize code; the only po
 
 BQN supports **object-oriented** programming [only incidentally](oop.md). This is not as bad as it sounds, and programming with objects in BQN can often feel pretty similar to other object-based languages. The main differences are that objects don't have a `this` property to pass themselves into functions, and there's no built-in way to find the class of an object. There is also no support for inheritance, which is not unheard of in the object-oriented world.
 
-BQN does not support **metaprogramming** such as macros or reflection, except with very crude techniques like `•Eval`. Functions describe computations and can easily be written, passed around, and applied: they can fill in for any use of macros or generics in a C-like language. If desired, it's easy to use lists as S-expressions to form structures that can be easily manipulated and also evaluated—roughly, embedding Lisp in BQN.
+BQN does not support **metaprogramming** such as macros or reflection, except with very crude techniques like `•BQN` to evaluate a string. Functions describe computations and can easily be written, passed around, and applied: they can fill in for any use of macros or generics in a C-like language. If desired, it's easy to use lists as S-expressions to form structures that can be manipulated and also evaluated—roughly, embedding Lisp in BQN.
 
 BQN does not yet have support for **concurrent** programming. It's likely that its strict approach to lexical scoping and encapsulation make it a good fit for concurrent execution, but designing such a system is not a priority. In contrast, array operations are ideal for **parallel** computing, including SIMD or GPU computation. To enable highly-parallel algorithms, the implementation must evaluate primitives (or combinations) using these algorithms, and the programmer must use primitives that have been implemented in this way. It would be possible to define a subset of BQN that restricts the programmer to code with an efficient parallel implementation, but BQN itself does not have any such restrictions.
 
diff --git a/docs/doc/paradigms.html b/docs/doc/paradigms.html
index 38093372..5542f213 100644
--- a/docs/doc/paradigms.html
+++ b/docs/doc/paradigms.html
@@ -19,6 +19,6 @@
 <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>
 <p>BQN supports <strong>object-oriented</strong> programming <a href="oop.html">only incidentally</a>. This is not as bad as it sounds, and programming with objects in BQN can often feel pretty similar to other object-based languages. The main differences are that objects don't have a <code><span class='Value'>this</span></code> property to pass themselves into functions, and there's no built-in way to find the class of an object. There is also no support for inheritance, which is not unheard of in the object-oriented world.</p>
-<p>BQN does not support <strong>metaprogramming</strong> such as macros or reflection, except with very crude techniques like <code><span class='Function'>•Eval</span></code>. Functions describe computations and can easily be written, passed around, and applied: they can fill in for any use of macros or generics in a C-like language. If desired, it's easy to use lists as S-expressions to form structures that can be easily manipulated and also evaluated—roughly, embedding Lisp in BQN.</p>
+<p>BQN does not support <strong>metaprogramming</strong> such as macros or reflection, except with very crude techniques like <code><span class='Function'>•BQN</span></code> to evaluate a string. Functions describe computations and can easily be written, passed around, and applied: they can fill in for any use of macros or generics in a C-like language. If desired, it's easy to use lists as S-expressions to form structures that can be manipulated and also evaluated—roughly, embedding Lisp in BQN.</p>
 <p>BQN does not yet have support for <strong>concurrent</strong> programming. It's likely that its strict approach to lexical scoping and encapsulation make it a good fit for concurrent execution, but designing such a system is not a priority. In contrast, array operations are ideal for <strong>parallel</strong> computing, including SIMD or GPU computation. To enable highly-parallel algorithms, the implementation must evaluate primitives (or combinations) using these algorithms, and the programmer must use primitives that have been implemented in this way. It would be possible to define a subset of BQN that restricts the programmer to code with an efficient parallel implementation, but BQN itself does not have any such restrictions.</p>
 <p>BQN doesn't support <strong>logic</strong> programming or <strong>computer algebra</strong>, although its <a href="../spec/inferred.html">inferred properties</a> might be considered a very rudimentary form of either of these. It doesn't support <strong>dataflow</strong> programming.</p>