On Fri, 2007-12-21 at 13:06 -0800, Roger Hui wrote: > Bob Bernecky wrote: > > > ... and it WAS one of the > > primary reasons Ken and I worked to develop a proper > > conjunction to supplant axis brackets, that I introduced into > > SHARP APL as the rank conjunction. > > A few relevant facts: > > - The rank operator was invented by Arthur Whitney in 1982, > who both recognized the problem with the axis operator and > invented its superior replacement. > See http://keiapl.org/rhui/remember.htm#22
You are correct, Roger. Ken and I tried a number of approaches over a year or so, but were never satisfied with any of them, because they were nightmares to look at. For example, we thought about providing something along the lines of dyadic transpose left arguments for the items specifying treatment of left and right arguments of dyads, and right arguments of monads. This led us to "X foo AXIS (monadic;dyadicleft;monadicright) Y" and and the like. I did not like the idea of implementing anything like this, nor did I like the idea of having to write APL that used it. I believe we were at the APL conference in Heidelberg when Arthur came up with the key idea of defining operations on leading axes, rather than on trailing axes, and offering the idea that a single number (rank) could then be used in lieu of shape vector selection. I recall its simplicity as being a breath of fresh air. I implemented the rank conjunction over a weekend, just before a SHARP APL release cutoff. The restriction to primitive function operands was intended as a short-term nonce error, and was not the intended design. By this time, the SHARP APL architecture was showing its age, and re-engineering it was a non-trivial task that could not be performed over a weekend. Or a month, for that matter. The obvious extensions to non-primitive functions, as desirable as they are, were considered "important, but not strategic" by the new management. Remember the time-frame when this was happening... I suspect the SAX interpreter, of more recent vintage than the mainframe one, did have the composition capability. You are correct that SHARP APL did not have prefix agreement, nor did it support tolerant frame building. I'm remain unconvinced that either of these are good things to have at a primitive level. Like negative indexing, it turns domain errors into results, and there's no way to turn it off. I'd prefer to introduce conjunctions or adverbs to enable that behavior when I want it. I'm not sure offhand what J does with rank when a frame shape contains a zero and a non-uniform function is being applied. I should have signalled nonce error... Bob > - The rank operator in SHARP APL worked only on > primitive function arguments. e.g. you can not say +/ rank 1 > > - The rank operator in SHARP APL only had "scalar agreement". > i.e. The two arguments must have the same shape, or > one argument must be a single cell. The rank operator > in J has prefix agreement (also suggested by Whitney). > See http://www.jsoftware.com/jwiki/Essays/Rank > > - The rank operator in SHARP APL did not have > tolerant frame building. > > > > ----- Original Message ----- > From: Robert Bernecky <[EMAIL PROTECTED]> > Date: Friday, December 21, 2007 6:54 > Subject: Re: Subject: Re: [Jchat] J readability > To: Chat forum <[email protected]> > > > Hi, Chris, > > > > I think your comments on the "axis-bracket notation" is a bit > > of a cheap shot. That notation is NOT an operator, although > > it certainly has some of that appearance, and it WAS one of the > > primary reasons Ken and I worked to develop a proper > > conjunction to supplant axis brackets, that I introduced into > > SHARP APL as the rank conjunction. > > > > The reasons I say that axis brackets are not an operator/conjunction > > are: > > > > - its syntax is anomalous. This is annoying > > - its semantics are custom-defined for EACH primitive. > > This is the primary reason it's a notation, > > rather than > > an operator: its operation on an arbitrary > > verb cannot be > > defined. > > > > My personal favorite example of the complete > > uselessness of > > axis brackets is the APL2 definition of > > ravel, which grows from > > a paragraph for ravel to three pages for > > ravel-with-axis-brackets. > > > > - the implementation of axis bracket notation within > > the interpreters > > has to be special-cased (as you noted) for > > EACH verb. > > > > Rather, axis brackets are a bit of archaic notation that > > would have been, were it not for The Installed User Base, > > discarded with no regrets. Sort of like cap, in J? > > We all make design (and implementation) mistakes; > > sometimes we can fix them. > > > > There is no doubt in my mind that J does represent, with > > some exceptions, a cleaner and leaner definition of an > > array language than does APL. We did learn from the > > experience of APL. > > > > However, we might also learn from > > the experience of Sven-Bodo Scholz and the SAC > > designers, who took the array concepts of APL and > > implemented them in a functional subset of C. > > They went beyond APL, J, and C in specifying > > a formal mechanism to (Gasp!) let a function return > > several results (as Dyalog has done). Furthermore, > > SAC supports user-defined data types, which neither > > J nor APL do. Finally, they realized that nearly all > > array primitives, if defined in standard libraries as > > SAC code, rather than as bolted-in primitives, > > offer substantial advantages to all: > > > > - the language core becomes simpler, > > > > - stdlib-defined primitives are exposed to > > compiler optimizers, with substantial performance > > benefits, > > > > - extending "primitives" to new, user-defined data types > > is trivial for a user to do, and > > > > - if you don't like the supplied definition of a > > "primitive", you can supply your own or enhance/alter > > the supplied one, adding it to your own private > > libraries. > > This approach allows us to move away from The Tyranny > > Of The Implementor, which I personally feel has been > > a much greater weakness of the array languages. > > > > Bob > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
