Bill Harris wrote:
> I've learned that when I see an apparent discrepancy between the
> documentation and behavior in J, the problem lies in my understanding.
I've learned the same painful lesson. Ken was a meticulous writer, and
Roger maintains that tradition. For an extreme example, see [1], where
Roger realized explicitly asserting the equivalence (f g h) y <==> (f y) g
(h y) in the DoJ could be construed as a guarantee of execution order, and
his response was to excise the assertion (and leave it implied by a
diagram)!
That meticulousness, combined with my numerous embarrassments when I've
declared "problems" with the DoJ, has had the result of making me very shy
of such declarations. For example, it took over a week to convince myself
that the discrepancy I reported in [2] was in J, and not just my mind. But
convinced I was, so as rigorous and dependable as the DoJ is, it is not
inerrant.
That said, problems in the DoJ are often actually problems of
interpretation; the DoJ is written in English, which can be ambiguous (as
any language can [3]), so the reader's understanding can differ from the
author's intent. And I think the text you quoted suffers from this problem:
> Moreover, the left argument of an adverb or conjunction is the entire
> verb phrase that precedes it.
I have never liked "the entire verb phrase that precedes it", and think it
is particularly unclear.
You have provided a sterling example. As you noted, (# %: *) is most
certainly a verb phrase: it produces a verb (forks are one of our most
recognized and celebrated verb phrases). And in the plainest sense, the
fork (verb phrase) # %: * precedes the adverb / . Yet, (# %: */) is
rendered # %: (*/) and not (# %: *)/ . Why?
The short answer is, I don't think we can know why from just the summary
language "the entire verb phrase that precedes it". I think we'd have
clarify our understanding through the less ambiguous parse table at the
bottom of the page [4]. Put another way, I don't think "the entire verb
phrase that precedes it" unequivocally predicts the behavior observed.
Now, I think, with a little exegesis, we could come to another understanding
of the word "precedes", and maybe even defend this understanding, but
tenuously at best [5]. I consider it better to conclude the clause in
question was never intended to be a specification. It is marked as "summary
material", and by definition omits relevant details; perhaps the clause
serves better as a hint or reminder.
The following text can also be confusing:
> Thus, in the phrase +/ . */b , the rightmost adverb /
> applies to the verb derived from the phrase +/ . * ,
> not to the verb * .
because it employs a conjunction (.) . The example only works because
conjunctions have higher precedence than adverbs, so . executes and
gobbles up +/ and * before the adverb in question (the ultimate / ) ever
gets to see them. This is in contrast to your # %: */ whose highest
precedence rule is the adverb in question.
But parsing and execution is still the weakest aspect of understanding of J,
and I should really take the time to study it. We do have a some nice tools
for such study. I'm thinking in particular of the trace script, e.g.
load'trace'
trace'+/ . */'
--------------- 3 Adverb -----
+
/
+/
--------------- 4 Conj -------
+/
.
*
+/ .*
--------------- 3 Adverb -----
+/ .*
/
+/ .*/
==============================
trace '# %: */'
--------------- 3 Adverb -----
*
/
*/
--------------- 5 Trident ----
#
%:
*/
# %: */
==============================
and chapter 39 of J for C programmers:
http://www.jsoftware.com/help/jforc/parsing_and_execution_ii.htm#_Toc1917345
86 . If my explanation of # %: */ didn't shed any light, then I'd refer
you there, as Henry explains it better than I ever could.
-Dan
[1] (f g h) y <==> (f y) g (h y) & execution order:
http://www.jsoftware.com/pipermail/programming/2007-December/009114.html .
The rest of the thread, esp. Henry and Roger's posts, are also interesting.
[2] Excepting pronouns, the interpreter stacks all names by value, in
contradiction of the DoJ which specifies that only proverbs are stacked by
value:
http://www.jsoftware.com/pipermail/programming/2009-August/015810.html . I
think the interpreter is correct (vs the DoJ) in this regard.
[3] This is one reason why PrimitivePrimitives is interesting; it is the
beginning of describing J notation in J notation, as opposed to ambiguous
English: http://www.jsoftware.com/jwiki/PrimitivePrimitives . But is it
possible to have a totally unambiguous specification? Wouldn't that be
equivalent to a (impossible) logical argument which rests on zero
assumptions?
[4] §II.E, see parse table at the bottom
http://www.jsoftware.com/help/dictionary/dicte.htm (as clarified by the rest
of the page).
[5] That is, # %: * precedes / textually, but not grammatically. The
adverb production has a higher precedence than the fork production. So the
interpreter didn't consider # %: * a train at the time it encountered the
adverb. It may have been mulling the option, but it deferred the decision
specifically because it knew it might encounter a higher-precedence rule
(such as an adverb). That is, it is actually the adverb that preceded the
verb phrase, and not the other way around, in the sense that the adverb rule
precedes the fork rule in the precedence table.
With that said, I feel it is a retrospective justification, rather than a
predictive rule. For, if we were to apply the same logic to # %: * +/ ,
knowing that the interpreter only has a 4-token lookahead, then what
conclusion would we reach? At first blush, it might seem that upon
encountering + the interpreter would no longer have to defer the decision
about # %: * because it knows + doesn't trigger a higher-precedence rule
than fork. We could fix this up by noting that the interpreter may now know
the fate of # but may still have to suspend judgment about %: * + for the
same reason as in the preceding argument. But here we enter into an
apologia and should abandon loose English reasoning, and adopt a more
precise approach (say, using trace as I mentioned above).
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
