> 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
Not so. See the references in the Rank essay http://www.jsoftware.com/jwiki/Essays/Rank and its opening paragraph: Verb (function) rank was introduced by Iverson [1978 ยง6], further developed in Iverson [1983, 1987, 1995], and implemented in SHARP APL, SHARP APL/HP, SAX, A, and J (see Bernecky et al. [1983, 1987], Hodgkinson [1986], Steinbrook [1986], Whitney [1989], and Hui et al. [1990], respectively). There is no paper recording Arthur Whitney's invention of the rank operator in 1982 because he was/is disinclined to write papers. He just invents and implements 'em, not write about 'em. ----- Original Message ----- From: Oleg Kobchenko <[EMAIL PROTECTED]> Date: Saturday, December 22, 2007 1:31 Subject: Re: [Jchat] J readability To: Chat forum <[email protected]> > 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. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
