> On Sat, 2007-12-22 at 01:31 -0800, Oleg Kobchenko wrote: > > 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). > > I am not aware of any implementations of the rank conjunction that > predate mine in SHARP APL. I'm not saying there isn't one; I am merely > claiming ignorance.
Oleg says "rank", not "rank operator" or "rank conjunction". The earliest recorded mention of function rank was in Ken's seminal 1978 "Operators and Functions" paper. The earliest published description of the rank operator was in Ken's "Rationalized APL", 1983-01-06. I believe a rank operator would have been in the APL model that Ken and Arthur Whitney worked on between 1981 and 1983. The rank operator was introduced in mainframe SHARP APL by SATN-45, 1983-05-02. ----- Original Message ----- From: Robert Bernecky <[EMAIL PROTECTED]> Date: Saturday, December 22, 2007 9:07 Subject: Re: [Bulk] Re: [Jchat] J readability To: Chat forum <[email protected]> > On Sat, 2007-12-22 at 01:31 -0800, Oleg Kobchenko wrote: > > 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). > > I am not aware of any implementations of the rank conjunction that > predate mine in SHARP APL. I'm not saying there isn't one; I am merely > claiming ignorance. > > > 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(). > > I am not enthralled with the SAC notation, nor of the > (at present) absence of higher-order functions in the language, > but we should bear in mind that SAC is a research compiler, > intended to study problems in high-performance computation > with array languages. I do suspect that introducing OOP libraries > makes the task of optimizing code significantly harder > than it is in a language that actually believes in arrays > as primitive objects. It's hard enough in those languages > that DO believe in them. > > > 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. > > This may have changed recently with Stephan Herhut's > "sac4c" work. I don't run Windows, except under duress, > so can't comment on the DLL/COM stuff. > > > 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. > > This is precisely why I'm working on the compiler side of the > fence. I want to be able to create compiled code (from APL > and/or J) that I can call FROM those interpretive environments > without excessive overheads getting to and from the called code. > Clearly, blindly copying an argument is a net loss that introduces > overhead of about the same order as executing a data-copying > primitive (e.g., 1 drop Vector) in a naive interpreter. > > Once we have the ability to compile unpleasant (in terms > of performance, not readability...) pieces of interpreted APL/J code, > perhaps in a JIT environment, and can call them with minimal > overhead from the interpreted world, problems such as > the meteor problem, dynamic programming, and others no longer > present such a burden to the array language user. > > > 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 have no idea where a SAC interpreter would fit in. > I suspect compiled would do OK, though. > > Bob ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
