Forks is the answer to what is the main reason to use J, IMO. Unfortunately, the parsing and readability rules force you to understand and memorize hooks as well, and adding complexity without much benefit.

If you only use forks and never use hooks, then your code is much more readable because you don't have to count the number of verb phrases in a parenthesis to know how to parse it. More importantly, you don't need to remember/keep looking up how hooks are applied.

Forks have a pretty simple application rule that is consistent and natural in the monad and dyad case.

Applying a verb monadically even if it is parsed as dyad

f@]

will give the result of f y, even if it is called as x f y.

3

hook refresher

(f g) y --> y f (g y)

x (f g) y --> x f (g y)

Equivalent forks to hooks

(f g) y --> (] f g) y

x (f g) y --> x ([ f g@]) y

It turns out that a single conversion is possible for both the monad and dyad cases, but its rare that a hook (or fork for that matter) has an obvious sense for both its monad and dyad case, and so I prefer to tailor syntax to its intended use. The common conversion of a monadic and dyadic hook is the dyadic one:

(f g) --> ([ f g@])

This works for the monad case as well because [ y --> y.

Even if you like to continue to use hooks, these conversion concepts can help you build longer trains where the hooks are not limited to the leftmost position. Understanding the conversion techniques can also let you modify the mechanics of forks. For instance:

(f x) h (x g y) --> x (f@[ h g) y

The main reason I hate hooks is that if I haven't looked up the definition in a while, though hooks have been defined with the arguably most useful semantics, an alternately natural verb execution/definition for x (f g ) y is f x g y

f x g y --> x ([: f g) y

y f x g y --> (] f g)

x f x g y --> ([ f g)

Thinking with forks only I believe lets me focus better on a problem without considering how to try to force the solution into a hook. It lowers my fear of dyads, because each side of a fork has easy flexibility to to use any part of the fork's dyadic arguments in any order.

If the language designers were to remove hooks from the language, the most natural re-definition of the verb (f g) would be ([: f g). That is a fork (or train) with no left most operand. There would no longer need to mention a higher train concept. For readability purposes, the right most (g) verb in a fork/train would always be (x if dyad) g y. the 2nd rightmost (f) verb would parse identically as ... f (x if dyad) g y. The presense or absense of a leftmost 3rd verb would immediately identify whether f is applied monadically or dyadically.

PascalJasmin/Use Forks Instead of Hooks (last edited 2011-05-24 02:50:00 by PascalJasmin)