Incunabulum
Roger Hui
> ...
> In August1989 Arthur Whitney visited Ken and Roger Hui at Ken's farm
> outside Toronto and put together a rudimentary interpreter in C on
> Ken's AT&T 3B1 computer, and Roger used this to begin working on an
> interpreter for J. On October 30 1989 I got a message from Roger
> asking me to stop by his office when I got to Toronto. He wanted to
> show me a partial implementation of hook and fork.
The Kiln Farm event is also recounted in Appendix A of my book
"An Implementation of J"; Arthur's one-page interpreter is
recorded therein. As well, the ATT 3B1 computer now sits on
my desk (one foot away as I write), and the files are all there.
Although Arthur's one-page interpreter was the final impetus that
led to J, the language owes much more to "A Dictionary of APL",
both in the language design and in the system architecture.
I studied the one-page for about a week for its organization and
programming style, but I'd studied the dictionary through its
various drafts and precursors of the dictionary for about ten years,
and had modelled extensive parts of the language (see "Some Uses of
{ and }", APL87).
In particular, the J interpreter was designed and built around the
parse table in Table 2 of the dictionary (p. 38). I'd previously
modelled the parser at least two different ways, and when I sat
down to write J I set an objective for myself that I can show the
parser in the C source to Ken and have him verify its correctness.
(Ken is not a C programmer.) I don't recall that Ken ever did that
(he seems to just trust me to do it correctly ...), but the effects
of trying to meet the objective are entirely beneficial.
Looking at the parser, more precisely, the parse table, it is
clear that "any syntactic form can be given meaning", at least
any form that involves looking at no more than 4 tokens. If the
rules pertaining to fork and hook are removed, one'd get rationalized
APL\360 (i.e. assuming removal of the anomalous [;]). Fork and hook
are meanings assigned to constructs that would be errors in APL,
and do not affect existing interpeted expressions; therefore,
fork and hook are compatible extensions and are (I believe) permitted
by the APL standard.
As recounted in "An Implementation of J", the first line of code
was written on Sunday, August 27, 1989, at about 4 o'clock in
the afternoon. ("J" was christened the first time it became
necessary to save the source file.) By late October, with an
intervening 2-week vacation in the Far East, all the elements of
the interpreter were in place (the architecture has not changed
to this day). My msg to Eugene mentioned only hook and fork,
but I was being sly, hoping to spring a big surprise on him when
he showed up in Toronto. Alas, he got wind of what J really was,
and I did not surprise him.
Ken's paper "A Personal View of APL" in the IBM Systems Journal,
1991 12, also recounts events from that period. In the paper,
Ken said he "showed this fragment [Arthur's one page] to others"
and "soon recruited Roger Hui". Funny, I always thought that
_I_ recruited _him_. With Ken, the surprise was total: he showed
me the one-page, and I came back a 2-3 weeks later with an
interpreter which had the parser implemented, and was definitely
recognizably APL.
I'd recently told Arthur that I wish he'd written two pages
instead of one that August afternoon in 1989 -- the influence
on the J programming style would have been that much greater.
(Someone once asked Peggy Lee who she thought was the best
jazz singer. Her answer was, "You mean besides Ella?" Likewise,
the answer to the question "Who's the best programmer?" is
"Besides Arthur?")
> Fork is firmly in the language. Hook is more tenuously fixed. At one
> time Ken and Roger notified me that they were removing it. I pleaded
> with them to reinstate it. Subsequently I have had an opportunity to
> talk at great length with Arthur Whitney about his new programming
> language K. In K the sequence (f g)x means function composition, that
> is, f g x. Arthur makes a strong argument for the greater utility of
> his convention.
Hook, being a dyad, can be readily defined as a conjunction
with an assigned symbol (h., say). Therefore, all but one of
the reasons for (f g) denoting hook (x=<.x, x+%x, etc.) would
still be satisfied by having h. (you'd write =h.<., +h.%, etc.),
and there are in fact advantages to having an explicit symbol
instead of mere juxtaposition. The one remaining reason for
assigning a meaning to (f g), is so that a sequence of functions
of any length would be interpreted.
But that property can be satisfied by assigning _any_ meaning
to (f g). With hindsight, I now wish we'd gone ahead and moved
hook to h., because if (f g) is interpreted as f@:g, then
(f g) <-> ([: f g) and (f g h i) <-> ([: f g h i), etc., and
that would remove the main reason for having [: . It does
mean that, since fork is necessarily of higher priority,
for the composition f(g(h(x))) one'd write (f (g h)) instead
of (f g h). Anyway, this is all water under the bridge:
we are committed to having a compatible interpreter for
future releases; moving hook would be incompatible; so hook
is safe.