Add Array Cast link to J hook discussion

1 files changed, 1 insertions, 1 deletions

diff --git a/commentary/why.md b/commentary/why.md
index 912ba22d..456815d6 100644
--- a/commentary/why.md
+++ b/commentary/why.md
@@ -67,7 +67,7 @@ J uses bytestrings by default, making Unicode handling a significant difficulty
 
 But J has its type advantages as well. I miss complex number support in BQN, as it's an optional extension that we haven't yet implemented. And BQN has a hard rule that only one numeric type is exposed to the programmer, which means high-precision integers and rationals aren't allowed at all for a float-based implementation. I think this rule is worth it because J's implicit type conversion is hard to predict and an unexpected numeric type can cause sporadic or subtle program errors.
 
-BQN uses a modifier `⟜` for J's hook, adding `⊸` for a reversed version (which I use nearly twice as often). This frees up the 2-train, which is made equivalent to Atop (`∘`). It's the system Roger Hui came to advocate, since he argued in favor of a hook conjunction [here](https://code.jsoftware.com/wiki/Essays/Hook_Conjunction%3F) and made 2-train an Atop when he brought it to Dyalog APL. As an example, the J hook `(#~0&<:)` to remove negative numbers becomes `0⊸≤⊸/` in BQN.
+BQN uses a modifier `⟜` for J's hook, adding `⊸` for a reversed version (which I use nearly twice as often). This frees up the 2-train, which is made equivalent to Atop (`∘`). It's the system Roger Hui came to advocate, since he argued in favor of a hook conjunction [here](https://code.jsoftware.com/wiki/Essays/Hook_Conjunction%3F) and made 2-train an Atop when he brought it to Dyalog APL. As an example, the J hook `(#~0&<:)` to remove negative numbers becomes `0⊸≤⊸/` in BQN. Hooks are also the topic of [Array Cast episode 14](https://www.arraycast.com/episodes/episode17-tacit4-the-dyadic-hook), where the panel points out that in J, adding a verb at the far left of a dyadic train changes the rest of the train from dyadic to monadic or vice-versa, an effect that doesn't happen in BQN.
 
 J locales are not first-class values, and BQN namespaces are. I think BQN's namespaces are a lot more convenient to construct, although it is lacking an inheritance mechanism (but J's path system can become confusing quickly). More importantly, BQN namespaces (and closures) are garbage collected. J locales leak unless manually freed by the programmer. More generally, J has no mutable data at all, and to simulate it properly you'd have to write your own tracing garbage collection as the J interpreter doesn't have any. I discussed this issue some in [this J forum thread](http://www.jsoftware.com/pipermail/programming/2021-April/058006.html).