Roger Hui <[email protected]> wrote:
> What is needed in theory is a description of how a given implementation
> of J differs from the dictionary. The only implementation that currently
> exists is for a serial machine.
I always felt that the section "II E. Parsing and Execution" enforced
too much serialization (and determinism) onto J. This is the
section with the parse table and the rule "1. Execution proceeds
from right to left. ...".
The nice definition
(f g h) y <==> (f y) g (h y)
wouldn't limit the fork's ordering if the order of execution were not
so fixed on the right side already.
So why is the execution order so rigidly prescribed? It's required
because you need it in order to do syntax analysis at runtime.
J's language design allows one to use a few different variations
of runtime flexibility. One can say "fee + fee fi fo" without
having explicit predeclarations for names the until the expression is
encountered, leaving open:
(a) the type classification (numeric/literal/boxed) of noun names,
(b) the actual J code behind verb/adverb/conjunction names.
(c) the grammatical classification (CAVN) of the names,
(d) and, if you are so inclined, you can even switch "fee" from
noun to verb while executing the line.
(e) I am (after all these years) still unsure about the exact meaning
of II.C. Are adverbs restricted to return verbs or not? Anyway,
for conjunctions, I definitely know that I can write a conjunction
c so that (1 c 0) yields an adverb and (1 c 1) a verb, with
corresponding consequences for the parsing of an verb left to it.
(f) For completeness' sake: runtime execution qua Do (".).
While this is the classical bane of compiler writers, this is
syntactically very static in J: a verb which always operates
on a (string) noun and returns a noun; there's nothing dynamic
in grammatical terms here.
My guesses are that
- everybody likes (a) & (b) (type flexibility of nouns, and hey: you
may fix your bugs in verbs!)
- nobody needs (c) or (d) (runtime-switching of syntactical categories);
in fact many people would prefer if this simply could not happen.
(Or: ... could not happen simply.)
- (e): I never exploit this, but we all depend on ":" which does.
Sacrificing the (c), (d), and (e) liberties would allow a classic
grammar for J. We'd have simple precedence and associativity rules
and "static syntax analysis" (prior to and independent of actual
execution) would be possible. At the same time, one could get rid
of the currently defined sequence points required to establish parsing
and give more freedom to implementations to reorder/parallelize things.
I am unsure about (e):
Besides ":", do we have primitive conjunctions or adverbs
which return anything other than verbs?
Does anyone have non-primitive C/As which do not return V?
Martin
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
