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 - 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
