Yes, Roger -- I am a closet J user. I fess up. I admit it. Oh, the shame of it all... What will I do when Mom finds out?
Back in the Dark Days of Adaytum, I wrote a fair bit of J code. Using a bit of memory-mapped files and other Good Things, I was able to take stuff that ran for several days (converting hypercubes to relational databases) and made it run in just over five minutes. I do periodically work with J, just because it does some things very well. However, the extent of my experience, or lack thereof, with J is not the main source of my discomfort with some of the design choices made in APL and J. Rather, as I thought was evident from my earlier message, it derives from extending the semantics of language constructs so that errors disappear, automatically, often in the name of "user convenience". The singleton-extension of the scalar functions (and others) in APL is an example of this, which was rightly forbidden in J and APEX. Indexing with negative numbers is another area that I, as one who has trouble getting loop bounds correct the first time, find troublesome. We spent a lot of time seeking these sorts of conforming extensions in SHARP APL; my opinion as to their value has changed over time. I am of the opinion that the language should be strict and minimal, and that extensions to it, such as tolerance in frame-building or cell shape lamination, should be under the control of higher-order functions. With suitable optimizations, this approach can offer a more powerful language without compromising performance or, I believe, readability. I am also looking more closely at the J language today because of an interest in compiling J to generate highly efficient code. That may explain some of my concerns about what I view as frills and/or problem areas. Bob On Fri, 2007-12-21 at 21:32 -0800, Roger Hui wrote: > Bob, I wonder where you got your experience > with tolerant frame building, sufficient experience that > you grew to dislike it. It can not be with mainframe > SHARP APL because it did not have it, and in any case > only primitives can be used with operators so any such > experience would be incomplete. It can not be with > SAX because you were not even sure that non-primitive > fns can be used as arguments to the rank operator. > Have you been a J user in secret all these years? > > > > ----- Original Message ----- > From: Robert Bernecky <[EMAIL PROTECTED]> > Date: Friday, December 21, 2007 15:47 > Subject: Re: Subject: Re: [Jchat] J readability > To: Chat forum <[email protected]> > > > Not so: it seemed like a good idea at the time > > we did it. I grew to dislike the tolerant > > frame-building later on, after I saw it in > > action for a while. > > > > I think I'd like it to be under the control of > > a higher-order function, as the present behavior can > > mask program bugs. On even-numbered days, it's OK, though. > > > > Bob > > > > On Fri, 2007-12-21 at 15:33 -0800, Roger Hui wrote: > > > > You are correct that SHARP APL did not have > > > > prefix agreement, nor did it support tolerant > > > > frame building. I'm remain unconvinced that either of > > > > these are good things to have at a primitive level. > > > > Like negative indexing, it turns domain errors into > > > > results, and there's no way to turn it off. > > > > I'd prefer to introduce conjunctions or > > > > adverbs to enable that behavior when I want it. > > > > > > That being the case, then I suppose the > > > tolerant frame building in the monad >y in > > > mainframe SHARP APL was specified and > > > implemented over your objections? > > > > > > > > > > > > ----- Original Message ----- > > > From: Robert Bernecky <[EMAIL PROTECTED]> > > > Date: Friday, December 21, 2007 14:04 > > > Subject: Re: Subject: Re: [Jchat] J readability > > > To: Chat forum <[email protected]> > > > > > > > > > > > On Fri, 2007-12-21 at 13:06 -0800, Roger Hui wrote: > > > > > 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 > > > > > > > > You are correct, Roger. Ken and I tried a number of approaches > > > > over a year or so, but were never satisfied with any of > > them, because > > > > they were nightmares to look at. For example, we thought about > > > > providing something along the lines of dyadic transpose > > > > left arguments for the items specifying treatment of left > > > > and right arguments of dyads, and right arguments of monads. > > > > This led us to "X foo AXIS (monadic;dyadicleft;monadicright) Y" > > > > and and the like. I did not like the idea of implementing > > > > anything like this, nor did I like the idea of having to > > > > write APL that used it. > > > > > > > > I believe we were at the APL conference > > > > in Heidelberg when Arthur came up with the key idea of > > > > defining operations on leading axes, rather than on trailing axes, > > > > and offering the idea that a single number (rank) could then > > > > be used in lieu of shape vector selection. I recall > > > > its simplicity as being a breath of fresh air. > > > > > > > > I implemented the rank conjunction over a weekend, just before > > > > a SHARP APL release cutoff. The restriction to primitive function > > > > operands was intended as a short-term nonce error, and > > > > was not the intended design. By this time, the SHARP APL > > > > architecture was showing its age, and re-engineering > > > > it was a non-trivial task that could not be performed > > > > over a weekend. Or a month, for that matter. > > > > The obvious extensions to non-primitive > > > > functions, as desirable as they are, were considered > > > > "important, but not strategic" by the new management. > > > > Remember the time-frame when this was happening... > > > > > > > > I suspect the SAX interpreter, of more recent > > > > vintage than the mainframe one, > > > > did have the composition capability. > > > > > > > > You are correct that SHARP APL did not have > > > > prefix agreement, nor did it support tolerant > > > > frame building. I'm remain unconvinced that either of > > > > these are good things to have at a primitive level. > > > > Like negative indexing, it turns domain errors into > > > > results, and there's no way to turn it off. > > > > I'd prefer to introduce conjunctions or > > > > adverbs to enable that behavior when I want it. > > > > > > > > I'm not sure offhand what J does with rank when a > > > > frame shape contains a zero and a non-uniform function > > > > is being applied. I should have signalled nonce > > > > error... > > > > > > > > Bob > > > > > > > > > - 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. > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
