loc@yrloc.ipsa.reuter.COM (Leigh Clayton) (01/30/91)
-----From Peter Biddlecomb, Reuter:file >no. 4885159 filed 15.15.31 tue 29 jan 1991 >from pbid >to clapl >subj How the "OVER" construct works > > >In response to the request from Rudi Rynders, here's an attempt to explain how ><over> works, concentrating on the bits which APL users are likely to have >problems with. It does not attempt to explain terms such as 'item' and 'atom'. >The explanation was arrived at from sevral directions: > >(a) Examining the results of (5!:1 <'over') to get an idea of the work done. >(b) Writing my own version in " monad :: dyad " form. >(c) Reading the 'Parsing and Execution' section of the Dictionary of J, and > the definitions of @ and &. > >As there are at least two versions of <over>, let's note the one we're looking >at and what it does: > > over =. ;@({.;}.)&":@, > z over z+/z=.1+i.3 >+-----+ >?1 2 3? >+-----+ >?2 3 4? >?3 4 5? >?4 5 6? >+-----+ > t=. z+/z [ right arg. of over ] > >We start by inserting the definition of <over> between <z> and <t>: > > z ;@({.;}.)&":@, t > >This of course gives the same result as <z over t>. <over> does exactly the >same job as <iota=.i.> - it gives us a name for a sequence of J primitives. >The causes of bafflement when I try to analyse <over> by eye are: > >(i) large number of primitives - the APL one-liner effect >(ii) unfamiliar symbols (and possibly different implementations of the > primitives they represent) if you're used to APL >(iii) the use of conjunctions - primitives which affect order of execution > >Here's <over> divided into meaningful units: > > ;: 'z ;@({.;}.)&":@, t' > >+-+-+-+-+--+-+--+-+-+--+-+-+-+ >?z?;?@?(?{.?;?}.?)?&?":?@?,?t? >+-+-+-+-+--+-+--+-+-+--+-+-+-+ > > n v c <----v----> c v c v n [this line is NOT provided by ;:] > >The bottom line categorises the contents of each box as Noun, Verb, or >Conjunction. We can mark the fork ({.;}.) as a verb at this stage. > >Now we parse the expression. The crucial point to note is that conjunctions >are executed before verbs, so we analyze them first to get an expression >which consists of nouns and verbs. > The other point to note is that "the left argument of [a] conjunction is the >entire verb phrase that precedes it". So starting with the rightmost >conjunction and using the same notation for its arguments as the dictionary, >we have: > > z ; @ ( {. ; }. ) & ": @ , t > > x <--------u---------> @ v y [ <u> is the verb phrase... ] > >the dictionary tells us that x u @ v y => u x v y: >--+ > ? > <---------u--------> x v y <------------------+ > > ; @ ( {. ; }. ) & ": z , t > > <------u------> & v <-y-> >------------------+ > ? u & v y => u v y > <------u------> v <-y-> <--------------------+ > > ; @ ( {. ; }. ) ": z , t > > u @ <----v-------> <-y-> >------------------+ > ? u @ v y => u & v y > u <----v-------> <-y-> <----------------------+ > > ; ( {. ; }. ) ": z , t > >Now we have an expression which tells us what to do with z and t. The only >barriers to understanding now are differences in symbols and their >implementation, and working out what the fork ( {. ; }. ) does. In detail, we: > >(a) catenate <z> on top of <t> [equivalent to <,[quad-IO]>] >(b) format the result [if we didn't do this, our column headers would be > misaligned for some values of t.] >(c) catenate the boxed first item (row in this case) onto the boxed remaining > items [note that take and drop operate on "items" rather than scalars] >(d) convert the result into a one-column matrix > >We can write a version of <over> which is easier for me to understand: > > over =. '' :: ';({.;}.)":x.,y.' > >Apart from the treatment of the monadic version of <over>, this does just the >same thing. > ><by> can be analysed in the same way, but this is left for you to do! > >Peter Biddlecombe, REUTER:FILE, London > -------And from Roger Hui, Iverson Associates >no. 4885515 filed 16.27.29 tue 29 jan 1991 >from hui >to pbid >cc clapl >subj How the "OVER" construct works >ref 4885159 >expy 0.00.00 1 mar 1991 > >Just one comment: as I pointed out in 4836625, if you simply enter the >name of the verb, you get a boxed display of the verb. This display >tells you J's idea of what squiggle is grouped with what other squiggle, >ie. very much like a tree, ie. the result AFTER parsing. This removes >word formation and syntax from the picture, leaving only the semantics >to be analyzed (meanings of @, &, ":, etc.). > >Of course, this is just another alternative. The approach taken in your >msg can be no less valuable. > > ----------------------------------------------------------- loc@tmsoft.UUCP uunet!mnetor!tmsoft!loc loc@ipsa.reuter.COM (Leigh Clayton)
rrr@hpdmd48.boi.hp.com (Rudi Rynders) (02/06/91)
Many thanks to Peter B. , Leigh and Roger H. Your posting was really helpful! Rudi Rynders (rrr@hpbdmd48.boi.hp.com) P.S. Are there any plans for something equivalent to APL workspaces in J?
rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) (02/08/91)
Workspaces as such are currently achieved in J by the use of scripts. These can be used to suck in files of J, similar to #include files. Not the most efficient, but quite general. Bob Bernecky Snake Island Research Inc.