(Long post. Those not interested in angels and pinheads may skip it.)
I wrote:
> I'm pretty sure the DoJ uses "proverb" elsewhere in a
> sense incompatible with Raul's proposal.
In §II (Grammar) [1], we read:
The name "area" thus assigned is a /pronoun/ and, as in
English, it plays the role of a noun. Similar remarks
apply to names assigned to verbs, adverbs, and conjunctions.
which settles the matter to my satisfaction. A proverb plays the role of a
verb (ie. can only refer to a verb, and not to an adverb or conjunction).
Thus, Raul's proposal [2]:
> Apparently, the term "proverb"
> also includes named adverbs and
> conjunctions.
is inadmissible. So, unless someone can propose another resolution, we
must conclude there is a discrepancy between J (the specification) and j
(the implementation).
In practice, the discrepancy is minor and effectively only applies to
adverb trains and bonded conjunctions. The only time it inconveniences me
personally is when I engage in "adverbial programming", an unpopular
sport. So perhaps we can just admit it and accept it.
OTOH, though it is not an "important" discrepancy, it does exist in a
fundamental, "important" part of the language: the parser. So I think it
warrants further attention, and perhaps resolution.
Obviously, one way to resolve it is to make j agree with J, and stack only
proverbs by name. At first blush, this is the path I prefer. But other
paths are available, and it might be interesting to explore them. For one
thing, I often use "edges" like this to give myself leverage to (ab)use
the language in interesting ways, that perhaps weren't intended.
For another, I think j's parsing rules are simpler, and perhaps more
elegant, than J's.
That is, both J and j have rules prescribing when to stack a name. J's
rules might be paraphrased as "all names except proverbs are immediately
evoked, and unassigned names are assumed to be proverbs (and hence not
immediately evoked)". But in j the rule might be paraphrased more simply
and concisely as "a name's value is used when it is needed" [3] or "a name
is evoked as late as possible" or "if evoking a name can be put off, it
will be".
We'll never know, but my guess is that when Ken wrote the "proverb" rule,
he had a goal in mind: to make unassigned names useful. He was thinking
ahead to the "an unassigned name being treated as a verb" clause. He
wasn't even considering pro-adverbs or pro-conjunctions, and since the
difference between the prescriptions is subtle and arises so infrequently,
pro-operators never presented themselves for consideration [4].
In short: j's rules are in a way simpler than J's, and Ken's neglection of
pro-operators might've been an oversight, rather than intentional. Given
that, rather than making j agree with J, we might do the reverse.
How would we do that? The simplest emendment I can think of is to delete
the words "proverbs and" from "or their values except in the case of
proverbs and names immediately to the left of a copula" in §II.E [5]. I
believe this change will have the desired effect (making J reflect j).
My argument runs like this: we still have the clause "eligibility for
execution is determined only by the class of each element" which makes it
clear that a word's value is irrelevant to the parser. A name's value is
only relevant when a production (execution) is invoked -- that is, when
the value is actually needed. This passes the buck out of §II.E and
brings J into agreement with j.
If that's not clear, perhaps an analogy aid me. I asked in [6]:
> Can someone show me where the Dictionary promises the grammar productions
> verb noun and noun verb noun are guaranteed to produce nouns?
The answer is: they're not. The grammar productions don't guarantee any
such thing. What the grammar productions guarantee is [5]:
EDGE VERB NOUN ANY 0 Monad
EDGE+AVN VERB VERB NOUN 1 Monad
EDGE+AVN NOUN VERB NOUN 2 Dyad
That is, when these token-patterns (sequence of nameclasses) are
encountered, an execution takes place. The details of that execution, and
what it produces, is not in parser's purview (the parser doesn't know that
monads produce nouns -- but once monadic execution takes place and
subsequently produces a noun, the parser will dutifully stack it and
continue).
If you want to know what monadic or dyadic execution is, you'll have to
refer to §II.B [7], which says:
The dyadic definition applies if the verb is preceded by a
suitable left argument, ... otherwise the monadic definition
applies.
which pinpoints when the "definition" (or value) is needed (or even
relevant) [8].
With all that said, I don't know that deleting "proverbs and" won't have
any side effects, or if Ken didn't put it in there for some subtle reason
that hasn't occurred to me. In the end, that's Roger's call. Though I'd
be interested in discussing it [9].
-Dan
[1] http://www.jsoftware.com/help/dictionary/dict2.htm
[2] http://www.jsoftware.com/pipermail/programming/2009-August/015865.html
[3] E.G., name-values are never needed to the left of a copula,
a noun-name's value is needed immediately, a verb's value is
needed when it's given a noun argument or two, etc.
[4] Of course I could be way off base. For example,
giving special treatment to proverbs might've been an acknowledgement
of the primacy of verbs in J programming.
[5] http://www.jsoftware.com/help/dictionary/dicte.htm
[6] http://www.jsoftware.com/pipermail/programming/2009-August/015767.html
[7] http://www.jsoftware.com/help/dictionary/dictb.htm
[8] You'll notice, however, that even §II.B doesn't guarantee that the
result of a monad or dyad is a noun. So to answer my question
completely ("where does the DoJ guarantee that V N and N V N
produce N?"), we note that II.B defines monads and dyads to be
verbs, and refer to §II [1] which reads:
Verbs act upon nouns to produce noun results
and so we have come full circle.
[9] In order to open communication about this, I reported the discrepancy
as a bug:
http://www.jsoftware.com/jwiki/System/Interpreter/Bugs#passingtheproverbialbuck
In truth, I expect that no change will be made. The discrepancy (if
it exists)
is minor in practice, and since we'd have to change II.E to resolve it,
it is perhaps safer to let it persist.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
