Undery =: 2 :'(v.^:_1)@:(u. v.)"((1{u.b.0),2{v.b.0)'

We have selected the left rank of u and the right rank of v, and put them as the ranks of the verb produced by Undery . This produces the desired result:

_3 _4 _3 {."0 1 Undery #: 32 31 30 0 15 6

and we can see the verb produced by Undery, with its ranks:

{."0 1 Undery #: #:^:_1@:({."0 1 #:)"0 0

This version of Undery produces correct results, but we should add one small improvement: the inverse of monad #: should be monad #. rather than monad #:^:_1, because the two forms are different. One difference is obvious: the rank of #:^:_1 is infinite, while the rank of #. is 1; but that is immaterial in Undery . The other difference is subtle but it could be significant: the two forms may have different performance in compounds. The interpreter recognizes certain compounds for special handling; the list grows from release to release, but it's a pretty safe bet that #. will be selected for special treatment before #:^:_1 (and < before >^:_1, and so on). So, we would like to replace the v.^:_1 with the actual inverse of v . We can get the inverse of v by looking at v b. _1 which produces a character-string representation of the inverse of v . We can then convert this string to a verb by making it the result of an adverb (we can't make it the result of a verb, because the result of a verb must be a noun). So, we are led to

Undery=:2 :'(a: 1 :(v.b._1))@:(u.v.)"((1{u.b.0),2{v.b.0)' where we defined the adverb 1 :(v.b._1) and then immediately executed it with an ignored left operand a: to create the desired verb form. Now we have

{."0 1 Undery #: #.@:({."0 1 #:)"0 0 which we can be content with.

An Exception: Modifiers that Do Not Refer to u. or v.

In very early versions of J, modifiers could not refer to their x. and y. operands. In those days, a modifier used the names x. and y. to mean what we now mean by u. and v. . Modern versions of J continue to execute the old-fashioned modifiers correctly by applying the following rule: if a modifier does not contain any reference to u., v., m., or n., it is assumed to be an old-style modifier, and references to x. and y. are treated as if they were u. and v. . You may encounter old code that relies on this rule, but you should not add any new examples of your own.

Modifiers That Refer To x. Or y.

Most of the modifiers you write will refer to x. and y. . The names x. and y. refer to the noun operands that are supplied when the modifier is invoked as

[x] u adverb y or [x] u conjunction v y .

181

Here is an example, which is invoked as [x] u InLocales n y, where u is a verb and n is a list of locale names; it executes u y (or x u y if the invocation is dyadic) in each locale of n :

InLocales =: 2 : 0 l1 =. 18!:5 '' for_l. n. do.

cocurrent l u. y.

end. cocurrent l1

''

:

l1 =. 18!:5 '' for_l. n. do. cocurrent l x. u. y.

end. cocurrent l1

''

)

This illustrates the important points. The text of the definition is not interpreted until the x. and y. are available, in other words until the verb defined by u InLocales n is invoked. Since that invocation may be either monadic or dyadic, two versions of the conjunction are given, one for each valence. The result of the execution must be a noun, because the definition defines a verb and the result of a verb is always a noun.

That last point is important and I want to emphasize it. It is true that InLocales is a conjunction, and yet its text defines a verb. How is this possible? Because

InLocales is executed as a conjunction at the time it gets its u and n operands, but its text is not interpreted until the derived verb (which consists of u, n, and the text of InLocales) gets its x and y operands. When InLocales is supplied with u and n, it is executed to produce a verb which consists of the text of InLocales along with u and the value of n . This derived verb is hidden inside the interpreter where it waits to be applied to a y (and possibly x). When the derived verb is given its operands, it starts interpreting the text of InLocales, which was unusable until the time that y. and x. could be given values, and initializes u. and n. from the values that were saved when u InLocales n was executed. Thus the text of InLocales describes a verb operating on y. and x. .

Your modifiers should refer to x. and y. only if necessary. Ifany from the previous section could have been written

Ifany =: 1 : 'u.^:(*#y.) y.'

which would produce exactly the same result as the other definition, but it would usually be slower, because the text could not be interpreted until x. and y. could be defined. If the conjunction happens to be used in a verb of low rank, the result could be soporific.

182

Here's a puzzle that may be of interest to those readers whose eventual goal is Full Guru certification. Why did InLocales save and restore the current locale? Didn't we say that completion of any named entity restores the original locale?

Let's see what happens when we don't restore, using a simple testcase: t =: 1 : 0

cocurrent u. y.

)

(<'abc') t 0

0

18!:5 '' +---+ |abc| +---+

Sure enough, the current locale was changed! But see what happens when we give a name to the verb created by the execution of t :

cocurrent <'base' tt =: (<'abc') t tt 0

0

18!:5 '' +----+ |base| +----+

The current locale was restored. What causes the difference?

The answer is that in the sentence (<'abc') t 0, the named adverb t is executed when it is given its operand <'abc' . The result of that execution is the derived verb (<'abc') t which has no name. When the derived verb is executed with the operand 0, the text is interpreted, causing a change to the current locale, and when the derived verb finishes, the current locale is not restored because the derived verb is anonymous. If we give that derived verb a name (tt here), it restores the current locale on completion.

The observed behavior reinforces the point that the text of a modifier that refers to x. or y. is not interpreted when the modifier is executed; it is interpreted only when the derived verb is executed.

183