Trying to diagnose issue with tacit recursion $:

[Cameron Chandoke]

Hi all, I am running into a weird issue concerning the $: verb as used in the following tic-tac-toe game. Somehow replacing (u f.) with u's body gives a different result; it seems they should always be strictly equivalent.

   JVERSION
Engine: j9.7.0-beta4/j64/linux
Build: commercial/2025-05-05T13:14:19/clang-14-0-0/SLEEF=1
Library: 9.7.1
Platform: Linux 64
Installer: j9.7 install
InstallPath: /home/cam/Programs/j/j9.7
Contact: www.jsoftware.com

'`c t b'=.(?@#{])@([:I.0=b)`{.`}.                                  NB. cpu's move; turn; board
'`wm tm'=. (''echo@, {&'.XO'@-@t ,' wins'"_)`([:echo LF&,@'tie')   NB. print win/tie message
i=. (0=]{b@[) ::0 *: ]e.i.@9                                       NB. invalid posn? (x: state; y: posn)
y=. ($:@[ echo@'no')^:i  _1+0".1!:1@1@echo@'move (1-9):'           NB. your move
m=. -@t , c`y@.(1=t) t@]`[`(b@])} ]                                NB. apply current player's move to board
d=. ''echo@, '',~ (,' '&,)/"1@({&'.XO')@(3 3$b)                    NB. display the board
w=. 3 +./@:= |@(+/"1)@(],|:,(<@0 1|:|.),:<@0 1|:])@(3 3$b)         NB. test whether game has been won
g=: wm`tm`$:@.(1:i.~w,0-.@e.b)@([d)@m                              NB. move and display until won or full

   

   g 10{._1   NB. this works; recursion is scoped because g is a named verb

. . .
. . O
. . .

move (1-9):
5

. . .
. X O
. . .


. . O
. X O
. . .

move (1-9):
9

. . O
. X O
. . X


. . O
. X O
. O X

move (1-9):
1

X . O
. X O
. O X

X wins

   ([: g f.{{u y}} 10{._1:)''   NB. this also works; {{u y}} limits the recursion to exclude the 10{._1:

. . .
O . .
. . .

move (1-9):
5

. . .
O X .
. . .


. . O
O X .
. . .

move (1-9):
1

X . O
O X .
. . .


X O O
O X .
. . .

move (1-9):
9

X O O
O X .
. . X

X wins

   NB. replacing (g f.) with g's body should be strictly equivalent, but fails for some reason: 
   ([: wm`tm`$:@.(1:i.~w,0-.@e.b)@([d)@m {{u y}} 10{._1:)''

. . .
. . O
. . .

|domain error: y
|       u y
Press ENTER to inspect

NB. note that this is a different result than if we don't use {{u y}} at all...

 

[...]

. . .
. . .
O . .


. . .
. . .
O . .

|stack error: b
|       ([:wm`tm`$:@.(1:i.~w,0-.@e.b)@([d)@m 10{._1:)''

[Henry Rich]

Named verb nv Is not equivalent to (nv   f.) when nv contains $: .  The name sets a recursion point. 

Henry Rich

To unsubscribe from this group and stop receiving emails from it, send an email to forum+un...@jsoftware.com.

[Cameron Chandoke]

Sorry, I failed to communicate my thought clearly. I should've said that for any verb g, and for the recursion scoping adverb R, 

where

R=: 1 : 0

u y

:

x u y

)

then g f.R should be strictly equivalent to g. That is the substitution I'm making in the examples here, but somehow (g f.R y) produces an error where (g y) does not.

[Henry Rich]

The recursion point is pushed at the start of executing a verb fragment, or at the start of executing a name. It is popped when the execution completes. 

(g R) executes to produce an anonymous verb that is waiting for its noun arguments. The recursion point was pushed at the start of that execution but it is popped at the end, before the arguments have been applied. Thus, when the body of R is executed, the recursion point has been popped. 

You would need a scoping adverb $:: that pushes the recursion point, executes u, and then pops the recursion point. No one has ever asked for that. 

Henry Rich

[Pascal Jasmin]

Possibly the only use of the (A C) modifier train

+ ((0&) : )

0&+ :+

this is often written as 0&$:  : +

but avoiding $: avoids problems with inclusion in larger phrases.

>>> '`c t b'=.(?@#{])@([:I.0=b)`{.`}.                                  NB. cpu's move; turn; board'`wm tm'=. (''echo@, {&'.XO'@-@t ,' wins'"_)`([:echo LF&,@'tie')   NB. print win/tie messagei=. (0=]{b@[) ::0 *: ]e.i.@9                                       NB. invalid posn? (x: state; y: posn)y=. ($:@[ echo@'no')^:i  _1+0".1!:1@1@echo@'move (1-9):'           NB. your movem=. -@t , c`y@.(1=t) t@]`[`(b@])} ]                                NB. apply current player's move to boardd=. ''echo@, '',~ (,' '&,)/"1@({&'.XO')@(3 3$b)                    NB. display the boardw=. 3 +./@:= |@(+/"1)@(],|:,(<@0 1|:|.),:<@0 1|:])@(3 3$b)         NB. test whether game has been wong=: wm`tm`$:@.(1:i.~w,0-.@e.b)@([d)@m                              NB. move and display until won or full
>>>
>>>    
>>>    g 10{._1   NB. this works; recursion is scoped because g is a named verb. . .. . O. . .move (1-9):5. . .. X O. . .. . O. X O. . .move (1-9):9. . O. X O. . X. . O. X O. O Xmove (1-9):1X . O. X O. O XX wins
>>>
>>>
>>>
>>>
>>>    ([: g f.{{u y}} 10{._1:)''   NB. this also works; {{u y}} limits the recursion to exclude the 10{._1:. . .O . .. . .move (1-9):5. . .O X .. . .. . OO X .. . .move (1-9):1X . OO X .. . .X O OO X .. . .move (1-9):9X O OO X .. . XX wins

[Cameron Chandoke]

Henry: It seems to me that what you are describing (i.e. the idea that the recursion point is has already been popped by the time the derived verb executes on the noun) is true of

   (... $: ...){{u}} y

but not of the situation I am talking about, which is that of

   (... $: ...){{u y}} y

In the latter case, my understanding is that {{u y}} leads the derived adverb to be executed while the recursion point remains on the stack. Hence the successful scoping behavior of the following toy example (slightly modified for further clarity here) from https://code.jsoftware.com/wiki/Vocabulary/dollarco#Restrict (excuse the long aside, but I feel it's necessary here, to ensure that no subtle miscommunication is happening here about the verb $:):

For example, suppose we want a single verb that increments an argument, then uses anonymous recursion to print the argument and subtract one until zero is reached.

We might initially try the following:

   V=: ($:@<: [ echo)^:*@>:
   V 2
...
3
3
3
3
3
|stack error: echo
|       V 2
The problem is that @>: is part of the recursion, so we get (y+1)-1 in each iteration. We want to separate @>: from the recursion.

The remedy is to pass ($:@<: [ echo)^:* to an adverb that explicitly refers to its noun arguments:

   V0=: ($:@<: [ echo)^:*{{u y}}@>:

   V0 2
3
2
1
0

In other words, if I am understanding you correctly, it seems that you are describing the same idea as the note [about the above example] that I added on the NuVoc page, posted here for reference:

   "Note that the adverb {{u}} (as opposed to {{u y}}) would not have had the desired effect of restricting the recursive scope, because a given instance of $: is not assigned a verb value until it is executed on (noun) arguments. In the case of $:@<:^:*{{u}}@>:, although $: is contained within the named verb u during the adverb's execution (the process of deriving the resulting verb), u itself is never executed on the argument. Instead the adverb simply returns the (anonymous) derived verb (in this case just the unmodified operand ($:@<: [ echo)^:*), and it is from within this anonymous derived verb that $: is executed on the argument. Since, in this case, when $: is actually executed on argument(s), it is not doing so from within any named verb, $: therefore refers to the outermost verb phrase that contains it, which is the entire phrase ($:@<: [ echo)^:*@>:."

   V1=: ($:@<: [ echo)^:*{{u}}@>:  
   V 2
...
3
3
3
3
3
|stack error: echo
|       V1 2

Rewording the above insight in your choice of phrasing, I think we would say that for

   ($:@<: [ echo)^:*{{u}}@>: 2

the recursion point has been popped before the argument has been applied, whereas for

   ($:@<: [ echo)^:*{{u y}}@>: 2

the recursion point remains on the stack at the time that the argument is applied, hence its behavior of restricting the "scope" of $:.

Have I understood your terms / idea correctly?

Assuming yes, then my question is -- in light of the above NuVoc example -- why the adverb {{u y}} (the monadic-only version of my adverb R from the previous reply) appears to not have the same scoping effect in my tic-tac-toe code that it has in the above example? 

And the follow-up is "what is it doing instead?"

[Raul Miller]

In
verb {{u}}
the result of {{u}} is (verb)

In
verb {{u y} noun
the result of {{u y}} is (verb noun)

In other words, in the second example, the verb's execution happens
inside the {{ }} expression and is isolated from anything else that
happens on the containing line.

--
Raul

[Raul Miller]

Oops, typo, I should have said
verb {{u y}} noun

for the second example.

Sorry about that,

--
Raul

[Cameron Chandoke]

Yes, this difference is part of what I was pointing out.

[Henry Rich]

No, I think you have it wrong. I'm away from my machine but the note you quoted, about $: not having a value till it gets arguments, is wrong. 

The body of.  w  {{ u }} is executed immediately, producing w. It's as if the {{u}} didn't exist. 

The body of  w {{ u y}} is.not executed immediately. Execution of {{u y}} produces an anonymous verb. This verb can be part of a compound, but when the body is executed, w y is executed as a new sentence, and the recursion point is set to w.

This is /not/ what I was talking about in my earlier mail, which concerned execution of names. They have similar but different issues. 

Henry Rich

 

[Raul Miller]

Unfortunately, your example is too complicated to go through the
evaluation steps.

But I think you have misunderstood how this works.

Consider, for example, a quicksort implementation:

N=: 3 1 4 1 5 9 2 6 5 3 5 8 9
((($:@(<#[) , (=#[) , $:@(>#[)) ({~ ?@#)) ^:(1<#)) N
1 1 2 3 3 4 5 5 5 6 8 9 9

If we introduce a {{u}} operation on an intermediate verb, that verb
is not evaluated inside {{u}} but is instead evaluated in the original
context:

((($:@(<#[) {{u}}, (=#[) , $:@(>#[)) ({~ ?@#)) ^:(1<#)) N
1 1 2 3 3 4 5 5 5 6 8 9 9

If we introduce {{x u y}} such that the intermediate verb is evaluated
in a different context, that breaks the implementation:

((($:@(<#[) {{x u y}}, (=#[) , $:@(>#[)) ({~ ?@#)) ^:(1<#)) N
|domain error, executing dyad #

Since ($:@(<#[) was executed in a context where $: was not the full
quicksort verb, the behavior changed.

Does that make sense to you?

Thanks,

--
Raul

[Cameron Chandoke]

@Raul: I'm wondering specific things I've said here that lead you to think that I was/am misunderstanding what you're pointing out here? Isn't your quicksort example showcasing the same dynamic as the example of 

   V=: ($:@<: [ echo)^:*@>:
   V 2
...
3
3
3
3

|stack error: echo
|       V 2

 vs.

   V0=: ($:@<: [ echo)^:*{{u y}}@>:

   V0 2
3
2
1
0

that I mentioned earlier?

I understand that {{u}} never has any effect because it immediately derives a verb which is just the original operand, and the name 'u' disappears before any arguments are processed. 

I understand that {{u y}} executes its verb operand in an isolated context, where on the named verb y, where the operand's value has been assigned to the named verb (that is, u). As such, $: operates on the argument y from within u, whose body is the value of $: . 

Yes, your example makes perfect sense to me. I could see myself having written the same example and explanation to someone else. All very familiar so far. 

[Cameron Chandoke]

Ok, most of this is familiar, but there are a couple points that are still a bit ambiguous to me.

The body of.  w  {{ u }} is executed immediately, producing w. It's as if the {{u}} didn't exist. 

The body of  w {{ u y}} is.not executed immediately. Execution of {{u y}} produces an anonymous verb. This verb can be part of a compound, but when the body is executed, w y is executed as a new sentence, and the recursion point is set to w.

Yes, I see that in w {{ u }}, it's as if the {{u}} didn't exist. 

Concerning the second statement, I'm unclear on the term "recursion point", and haven't seen it elsewhere. We should probably define that before we move forward. My guess is that this simply refers to the 3 rules you mentioned in a previous thread, which are

The value of $: is set in 3 places:

* when a thread is started, to the verb that is executed in the thread
* when a name is executed, to the value of the name
* when a the parser executes a verb on its noun arguments, to the value
of the verb

So when you say "recursion point", are you simply referring to the verb value that is assigned to $: according to one of these three rules? Or if not, please clarify what you mean by the phrase. Thanks

[Henry Rich]

Yes, that is what I mean. The recursion point is the value of $: .

Henry Rich

[Raul Miller]

Re-reading, I see that what you were saying is not what I thought you
were saying.

The misunderstanding was mine.

Thanks,

--
Raul

[Cameron Chandoke]

@Henry: Regarding this:

The value of $: is set in 3 places:

* when a thread is started, to the verb that is executed in the thread
* when a name is executed, to the value of the name
* when a the parser executes a verb on its noun arguments, to the value
of the verb

I don't understand the distinction between the last two; could you give a simple example of the name one and the parser/verb one? 

And can these 3 places overlap, or are they mutually exclusive?

[Henry Rich]

fib =: (* $:@<:)^:(1&<)  NB. a recursive definition

   fib 6
720
   fib @ <: 6  NB. @:<: is NOT part of the recursion, which starts at the named value
120
   (fib f.) @ <: 6  NB. name removed: now @:<: is part of the recursion
15
   (fib f.) <: 6  NB. The executed verb is (* $:@<:)^:(1&<), which is the recursion point
120

Henry Rich

[Cameron Chandoke]

Right, ok. Yes, I would've been able to predict what those results would be. 

Earlier, I would've looked at that (fib f.) example and described that as "this example shows that $: wasn't assigned a value at the time when fib was defined;  rather $: was assigned a value only when it was executed on arguments".

But you said that 

... the note you quoted, about $: not having a value till it gets arguments, is wrong.

So that means that in this fib example, $: is assigned a value before it gets arguments. 

Also you avoided mentioning arguments here when talking about a name executing:

The value of $: is set in 3 places:
* when a thread is started, to the verb that is executed in the thread
* when a name is executed, to the value of the name
* when a the parser executes a verb on its noun arguments, to the value
of the verb

So, what is meant by saying that "a name is executed" (like "fib" here, for example)? Does it not imply that it is executing on arguments? Or does it mean something else?

[Henry Rich]

During parsing, $: is assigned its value after a fragment has been recognized as being a verb with noun arguments, just before it is executed on those arguments. 

During the execution of a fragment, which may involve many executions of named and primitive verbs, $: is assigned with the value of any named verb just before that verb is executed.

[$: is also assigned when a named modifier is executed, but that value can never be used before it is overwritten.]

Henry Rich

[Cameron Chandoke]

Ok. And in that second sentence, when you say "just before that (named) verb is executed", you do mean "executed on arguments", then? 

If so, I'm a bit confused as to why you said that [my understanding that $: is not assigned a value until it is given arguments] was wrong?

Just want to be sure I'm not missing anything before coming back to my original question.

[Cameron Chandoke]

Well, I suppose maybe you meant to emphasize that $: is assigned a value as soon as [the name or anonymous verb phrase in which $: appears] gets arguments. Which is before the $: verb itself gets arguments. 

I could see it making sense to point out that distinction.

[Henry Rich]

Yes, that is the distinction. 

What JE does for recursion is almost trivial, but I have spent hours trying to find words that convey what it does to a reader. The problem is that you first have to understand that a long compound is parsed before it is executed, and then executed /in toto/. Only then can you make sense of the notion that $: is assigned at the point of that execution. 

Henry Rich

[Henry Rich]

I don't remember exactly what I said when, but the answer to your final question is No.

I don't think your suggested language is adequate: 

* You refer to /the/ containing verb, but there may be many such verbs.

* $: inside a named verb that is inside X would naturally be said to be inside X, but it does not recur to X.

Henry Rich

On Fri, Apr 24, 2026, 6:51 PM Cameron Chandoke <ccha...@gmail.com> wrote:

Right. I think we can just amend it to say e.g. "$: is not assigned a value until the verb that contains it (whether named or anonymous) is executed on arguments". And have an example that shows that by "contains" we mean "whose (verb) value includes $:". Thus fib@<: does not contain $:, but fib does, and fib f.@<: does. 

So, returning to the original question of the thread, I was asserting that

for any verb g, and for the recursion scoping adverb R,
where
R=: 1 : 0
u y
:
x u y
)
then g f.R should be strictly equivalent to g. That is the substitution I'm making in the examples here, but somehow (g f.R y) produces an error where (g y) does not.

You replied that

The recursion point is pushed at the start of executing a verb fragment, or at the start of executing a name. It is popped when the execution completes. 

 

(g R) executes to produce an anonymous verb that is waiting for its noun arguments. The recursion point was pushed at the start of that execution but it is popped at the end, before the arguments have been applied. Thus, when the body of R is executed, the recursion point has been popped. 

 

You would need a scoping adverb $:: that pushes the recursion point, executes u, and then pops the recursion point. No one has ever asked for that. 

 Note: You mentioned (g R) here, but I was talking about (g f.R), not (g R). Maybe that created a misunderstanding.

That reply still isn't making sense to me in light of this behavior: 

   fib=:  (* $:@<:)^:(1&<)

   R  =:  ]: ({{u y}} : {{x u y}})   NB. scoping adverb

   fib@<: 6            NB. @:<: is NOT part of the recursion

120

   fib f.@<: 6         NB. name removed: now @:<: is part of the recursion
15
   (fib f. R)@<: 6     NB. again @:<: is NOT part of the recursion
120

   (fib f.R@<: -: fib@<:) 6
1

Your statement seemed to imply that fib f.R@<:  would not be functionally equivalent to fib@<: , but this demonstrates that it is equivalent. 

I was merely saying that this equivalence should hold for any verb, in place of fib.  Is there a case in which this equivalence (g f.R -: g) does not hold? 

[Cameron Chandoke]

Yeah, I was about to remove that suggestion from my message and re-post it, because I realized the inadequacy of it.

[Cameron Chandoke]

But, ok... in what case(s), and why, would the equivalence (g f.R -: g) not hold as it did here?

[Cameron Chandoke]

Since (g f.) is anonymous, this also seems to be the same question as, "in the phrase (... $: ...)R, when does R fail to provide recursion scoping for the anonymous operand (... $: ...) as it did in this instance with fib? And why?"

[Henry Rich]

I'm sorry, I was trying to be unambiguous. Your equivalence always holds.

[I'm on my phone & trying to save characters.]

Henry Rich  

[Cameron Chandoke]

Ah, ok. 

Separately, looking back, I now realize that I got distracted by discussing $: in the first place.

My original message boiled down to:

Somehow replacing (u f.) with u's body gives a different result; it seems they should always be strictly equivalent.

You responded that 

Named verb nv Is not equivalent to (nv   f.) when nv contains $: .  The name sets a recursion point.

But I was not saying that a named verb nv should be equivalent to (nv f.) ; I was saying that [nv's body] -- which is anonymous -- should be equivalent to (nv f.) (including when it contains $:). 

For example, with fib=: (* $:@<:)^:(1&<) , I should be able to replace 

   (fib f.) 

with 

   (* $:@<:)^:(1&<) 

anywhere; they should be interchangeable. It seems this should be so for any verb in place of fib .

Isn't this "(nv f.) -: [nv's anonymous body]"  equivalence also universal? It fails in the case of my tic-tac-toe code, which led me to think there may be a bug.

[Henry Rich]

The equivalence in your last paragraph should hold, as long as the name is tacit and there are no locatives about. If you have a counterexample, produce it as briefly as possible. 

Henry Rich

[Cameron Chandoke]

Ahh. Having narrowed it down further, I see that it's a bug that results from assigning to the special names x y u v m n outside of an enclosed context, and having these names interact with e.g. the adverb {{u y}}. 

Two simple examples:

   y=: <: 

   y {{u y}} 5

|domain error in y, executing noun y

|       u y
Press ENTER to inspect

   x=: +
   2  (0 x ]) {{x u y}} 5
|domain error in x, executing dyad x
|   x     u y
Press ENTER to inspect

   JVERSION
Engine: j9.7.1/j64avx2/linux
Build: commercial/2026-04-06T04:03:13/clang-14-0-0/SLEEF=1

Library: 9.7.1
Platform: Linux 64
Installer: j9.7 install
InstallPath: /home/cam/Programs/j/j9.7
Contact: www.jsoftware.com

The equivalence (g f.) -: [g's anonymous body] did not hold in my program because f. removed the name 'y' from g's verb value, allowing JE to produce the correct result. The version with [g's anonymous body] contained the name 'y', and thus gave this domain error. The presence of $: was incidental. 

I should apologize for not having spent more time narrowing this down before posting here. One can always use simpler verbs and try to produce the simplest error case. Next time I will do so.

[Henry Rich]

No apology called for. We had an illuminating discussion, and it convinced me that $:: to end recursion should be added to the language. 

Henry Rich

[Cameron Chandoke]

Oh. Well I'm glad to hear it; I've wished for a while that J had this adverb.

Thinking about it further, this discussion about  $:  makes me wonder what result is actually assigned in the sentence

   fac=: (* $:@<:)^:(1<])

The parsing page stresses that in the sentence  mean =: +/ % #  :

I want to emphasize that what is assigned to mean is the result of parsing +/ % # .  It is not the sequence +/ % #, but rather a single verb which performs the function described by the fork.

But how does this work in the case of (fac=: ... $: ...), given that $: does not have a value at this point? 

The question applies equally to the sentence

   g=: 3 + und_h    NB. assume that verb und_h has not been yet been defined

[Henry Rich]

Consider a similar question about the grammar of English: what does 'itself' mean? 

It helps little to talk about what the word means in the abstract. It has meaning only in a sentence, and its meaning there is defined by the rules of the grammar. 

Similarly with $: . As parsing/execution proceeds, the interpreter keeps track of what $: will mean if it is seen. 

Verbs and modifiers that contain names are stacked by reference, which means that instead of stacking a possibly undefined value, JE stacks ('name'~). The reference contains the part of speech of the name (verb if undefined) and its rank, but the actual value is recovered only when the reference is executed. 

Henry Rich