ljdickey@water.waterloo.edu (L.J.Dickey) (09/28/90)
In article <Sep.25.16.10.08.1990.1736@klaatu.rutgers.edu> josh@klaatu.rutgers.edu (J Storrs Hall) writes: > [...] >Assuming my guess is right, that should make for a notably >easier job for an optimizer trying to do structure-sharing; >it makes one suspect a compiler of some kind is planned. Work on a compiler is now underway at Snake Island Research, Toronto. >(On the other hand, the rest of J seems designed to be as >hard as possible to compile!) Contrary to this appearance, the opposite is probably closer to the truth. Here are two versions of a "nub" function. One mentions the arguments explicitly, and the other makes tacit use of the arguments. The point about the second one is that its execution is done without having to re-parse the function body. Is this not "compilation" ? o=. 0 0 $ ' useful bit of nothingness :-)' comment =. {: & o comment ' Explicit nub (function arguments explicitly mentioned).' nub0 =. '( ( i. # y. ) = i.~ y.) # y.' :: '' nub0 +----------------------------+--++ |( ( i. # y. ) = i.~ y.) # y.|::|| +----------------------------+--++ comment ' A tacit nub (function arguments tacitly assumed).' comment ' Notice that both hook and fork phrasal forms are used.' nub1 =. #~ i.&# = i.~ nub1 +-----+-------------------+ |+-+-+|+--------+-+------+| ||#|~|||+--+-+-+|=|+--+-+|| |+-+-+|||i.|&|#|| ||i.|~||| | ||+--+-+-+| |+--+-+|| | |+--------+-+------+| +-----+-------------------+ comment ' Examples:' a =. 'neon napoleon' nub0 a neo apl nub1 a neo apl comment ' Some random rows: ' b =. ( ? 7$4 ) { i. 4 3 b 0 1 2 9 10 11 3 4 5 6 7 8 0 1 2 0 1 2 6 7 8 nub0 b 0 1 2 9 10 11 3 4 5 6 7 8 nub1 b 0 1 2 9 10 11 3 4 5 6 7 8
josh@klaatu.rutgers.edu (J Storrs Hall) (09/29/90)
ljdickey writes:
nub0 =. '( ( i. # y. ) = i.~ y.) # y.' :: ''
nub1 =. #~ i.&# = i.~
I would assume any good compiler would reduce either of these
definitions to the dataflow graph:
value
\
#
/ \
= \
/ \ \
i. i. \
\ /\ /
# \/ /
\/ /
\/
\
argument
and produce identical code for each. The only problem the '...'::''
form might produce is that a name used in the code might change
definition sufficiently to invalidate the original parse of the
string. APL has this problem (problem from the compiler writer's
point of view), but few other languages do. Even in Scheme, where
function definitions can be thrown around with mad abandon, reparsing
is never necessary.
However, what I meant by my original remark was that J has even
fewer of the kinds of dependencies between code and actual data
type and shape and size, than APL does. An APL compiler (like
Tim Budd's) depends heavily on gleaning "clues" from the code
about the size and shape of the data.
From the programmer's point of view, of course, this is very
laudable: the J program for nub you exhibited works on a range
of data it would take several APLSV programs to cover, or dozens
of C programs. The necessary concommitant is that the compiler
has to be able to extract all of those programs from the J code.
--JoSH