I believe the paper where rank was introduced (to) is Bernecky, R., ''An introduction to function rank'', APL Quote-Quad, Volume 18, Number 2, 1987-12 (next issue after A Dictionary of APL; should be added to A Bibliography of APL and J at Wiki).
The mention of the SAC language raises some interesting points. Well, they surely saluted to a mainstream language--an admited and much succeeded approach C++ took. But there are other approaches, maybe even better: by, instead, providing a (OOP) library so that you could even keep your favorite langauge, but still do arrays. However, SAC sacrificed most of the notation, giving back only scarse syntactic sugars like with(). Albeit having C-like syntax, their interface with real C raises some doubts: (1) it requires a SAC2C compilation and (2) the C-calling code does not look pretty, the same standard APL hand-coded wrapper interface with custom array types, etc. Now compare this with J DLL and COM interfaces: J engine takes on the burden of allocating and converting the structures, so the C code looks like calling another native library. J COM interface provides natural conversion to Variant types and arrays, and for free gives the same natural interface to .NET thanks to .NET interop. All this is done over dynamic J scripts, naturally without any compilation. With our pcall experiments it was shown that a C-callable interface can be generated with J in memory at runtime without traditional file-based compilation. Now with pcall in j602 we can continue this effort hopefully to something practical. However, the real question--"when you turn it on, does it return the favor"--still is: the control structures as first-class citizens. http://www.jsoftware.com/pipermail/chat/2007-November/000644.html http://www.jsoftware.com/pipermail/chat/2007-November/000648.html The problem with array languages is that the raw processor power of imperative loops and branches over primitive types is chained behind the iron curtain of interpretive overhead. A very good example of what this means was demonstrated recently by John Randall with the issues raised by the Meteor problem. http://www.jsoftware.com/pipermail/programming/2007-December/009089.html Now, where would interpreted* SAC be on the performance scale between 0.15s C++, Java 1.64s, J 50s, and Ruby 100s? http://shootout.alioth.debian.org/gp4/benchmark.php?test=meteor _______ *) I know of considerable effort put in compiling APL, so I'd refrain from my reasons here. --- Robert Bernecky <[EMAIL PROTECTED]> wrote: > 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 > > On Fri, 2007-12-21 at 10:11 +0800, Chris Burke wrote: > > Morten Kromberg wrote: > > > However, Mark D. Niemiec wrote: > > > > > >> J has abandoned a lot of the ugly and irregular archaism of APL, > > >> making its syntax more elegant. To wit: > > >> - bracket indexing y[x] being unlike other functions; replaced by > > >> regular x}y > > >> - bracket syntax u[n] being unlike other operators; replaced by u"n > > >> - irregular axis-operator semantics replaced by regular rank-operator > > >> semantics > > >> - many APL primitives (such as rotate/reverse, compress/reduce, > > >> expand/scan) > > >> have two versions with different default axes. J eliminate this > > >> redundancy > > >> by the more general and consistent rank mechanism. > > >> - ; having different precedence from all other verbs > > >> - unique syntax of outer product. > > >> - while APL has some adverb (/ \) and conjunctions (.), > > >> these are special-cased to only work on certain subset of primitives, > > >> while J allows them to be used generally. > > >> - APL's scan operator \ is replaced by the much more useful J prefix > > >> operator, > > >> which can emulate scan (via /\) but the converse is not possible. > > >> - J's tacit verb mechanism allows an entire level of elegance and > > >> succinct expression of functional concepts totally unheard of in APL. > > > > > > J has indeed abandoned much of what one could argue is was shown to "bad" > > > design in original > APL (mostly in terms of making it harder to extend the language - not > necessarily in terms of > making the language easy to use). While APL systems have not abandoned > anything due to the > installed user base, many more modern alternatives are now available. J grew > out of the APL > community 20 years ago, and much of the bad or inconsistent design was well > recognized at the > time. Many of the fundamental ideas like rank, dual and "from" were designed > and implemented in > SHARP APL (with Ken Iverson as a driving force). So although much "special > syntax" involving > square brackets and semicolons does remain, some of the items on the above > list is are not > really fair to APL: > > > > > > - In APL, indexing can be done with "squad" and "pick" indexing (no merge > > > - yet) > > > - Rank was actually implemented in SHARP APL before it appeared in J. > > > Although the APL2 > paradigm of axis specification has been dominant in the rest of the APL > community, I think we > will see rank in other APL interpreters in the future. (And for some > expressions, the use of > axis does allow slightly more elegant code than rank - even if it is less > "general"). > > > - It is simply not true that APL operators are limited to certain > > > primitives, at least not > in the APL I use. We have user-defined operators, too. > > > > Nevertheless, APL operators are special-cased. For example: > > > > A {gets} 2 3 {rho} {iota} 6 > > > > {transpose}[1] A > > SYNTAX ERROR > > > > +/[1]A > > 5 7 9 > > sum {gets} {+/{omega}} > > sum[1] A > > SYNTAX ERROR > > > > There is nothing wrong with the syntax in either case - even the error > > message is wrong. > > > > > The one really nice thing J has done that I don't see how APL can follow > > > (due to the > installed user base) it to make the first dimension the default for many > operations. The > interaction between this and notion of rank is really elegant. > > > > The interaction is probably essential. Rank works well in J because it > > is complemented with other features that are not yet in APL - item > > functions, prefix agreement, tolerant assembly. Without these, rank may > > not have the utility that it does in J. > > > > > Dyalog APL has "Dynamic Functions" (lambda-style expressions similar in > > > spirit to KEI's > "Direct Definition" ideas), and they SEEM to bring us much of the practical > benefits that tacits > provide, in a less succinct, but more easily digestible form. This may be > because we are > reaching for a slightly broader programming audience, with a bit less focus > on the mathematical > aspects of the notation. > > > > Dfns are very useful and a nice step forward, but they correspond to J's > > explicit definition, not tacit definition, i.e. the following are > > essentially the same: > > > > avg=: 3 : '(+/y) % #y' > > > > and > > > > avg {gets} {(+/{omega}) {div} {rho}{omega}} > > > > The only significant difference here is that the J expression is just a > > normal part of the language (i.e. the result of an operator expression), > > whereas the APL is a special syntax that treats the curly braces as a > > function definition. > > > > J's tacit definitions correspond to APL's operator expressions; there > > are just more of them, and J also includes phrasal forms. Dyalog has > > already done a lot in this area, and presumably could do more. ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
