> Is it one of the things in the table towards the bottom of the J article?
Erm, no. That table suggests using b. as a replacement for other (clearer) algorithms for performance reasons, rather than parameterisation.
What I mean by parameterisation is this: if you have a function that takes some arbitrary bitwise operation, instead of taking a lambda, you can pass the truth-table directly.
This idea is mentioned only briefly in the J article (More Info, ¶2):
2. Operand m may be an array, in which case each result cell will be the array of the results of the logical functions specified by m.
Maybe that is too-obvious to an array programmer and not-enough-obvious to someone who isn't, and so it is hard to properly consider the implications or applications of this.
Here's one: Parsing AND/OR operations from an expression (like an SQL expression). You could use a tree of operators and then walk the tree for every row you want to consider or you could store the compositions as a list and do a single reduction.
Is that enough for you to get the idea of what is going on here?