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 > _______ > *) 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
