Henry's analysis and recollection are essentially correct. In preparation to answering Johann Hibschman's question, One question though: why is the particular form (result=:c}b,:a singled out, rather than the general (c}b,:a)? I did the following benchmarks:
a=: 1e6 ?@$ 0 b=: 1e6 ?@$ 0 c=: 1e6 ?@$ 2 ts=: 6!:2 , 7!:2@] 10 ts 'c}b,:a' NB. ben0 0.0656868 4.19441e7 10 ts 'r=: c}b,:a' NB. ben1 0.01968 8.38976e6 10 ts 'b=: c}b,:a' NB. ben2 0.0142325 1152 10 ts 'a=: c}b,:a' NB. ben3 0.0142765 1152 It is right and proper that ben2 and ben3 should be the fastest and leanest, because the interpreter can go through c and (a or b) just once, modifying a or b according to c. It is also expected that ben1 would also be fast (but slightly slower) but take more space, because the interpreter has to transfer a or b to a new array. But why is ben0 so much slower and fatter than ben1? (That's Johan Hibschman's question.) The immediate answer can be found in file w.c of the J source, function jtenqueue(). The special code for x=:c}b,:a<http://www.jsoftware.com/help/release/iamend.htm>and friends is recognized not at parse time (parse in the sense of Section IIE of the dictionary <http://www.jsoftware.com/help/dictionary/dicte.htm>), but in a small gray area between word formation and parsing, implemented by jtenqueue(). After word formation<http://www.jsoftware.com/help/dictionary/d332.htm>, the words are put into a form required by the parser, and it is at that stage that a few special forms abc=: pqr (xyz}) abc abc=: abc,blah abc=: abc xyz}~ pqr abc=: pqr}x,y,...,:z are recognized. This is done for every sentence you enter in your session, and for every line of an explicit definition at the time of definition. This procedure avoids modifying the parser, avoids slowing down the parser, etc. It does of course slow down every sentence you enter in your session and the definition of every explicit definition. In this I exercised my right as the "holder of the pencil", and deemed the trade-off worthwhile. Tacit expressions too have a similar thing happen, with logic that is more dispersed. What you enter (for example) blah0 f/. blah1 whether assigned or not, within the /. adverb the interpreter looks at f and decides to do all manner of weird and wonderful things. If this is assigned, as for example in keysum=:+//., then the analysis happens only once, but you get the benefit every time you apply the named verb. If this is not assigned, then you benefit just once, and the result of the analysis is thrown away when the parser is done with this part of the sentence. The execution of f/. and the definition of keysum=:+//. are slowed down minutely as a result of this analysis, but no other verb, adverb, or conjunction is affected, nor is the parsing of a sentence not involving /. affected. I imagine that in the future, it is possible that one of Henry's bright young students can carry this further, and do all sorts of analysis and optimization at the time that a script is loaded or saved. Come to my talk at the J Conference<http://www.jsoftware.com/jwiki/Community/Conference2012>, and I will tell you more about this and other marvels ☺ On Thu, Dec 22, 2011 at 10:44 AM, Henry Rich <henryhr...@nc.rr.com> wrote: > > I think Raul has the right idea. > > Consider execution of > > q} a,b,c,:d > > This goes right-to-left and the c,:d is executed long before the q} is > ever seen by the parser (and remember, the q} could actually be a > defined name). To prevent the execution of c,:d would require either > > - a full analysis of the names in the stack > or > - designation of a special case that will get fast treatment. > > Roger has said that he was very loath to slow down the parser, because > that would cost on every sentence executed. So the parser recognizes a > few special cases for those combinations that cannot be turned into a > single compound verb. > > > In addition to avoiding the ,: there is the greater payoff of performing > in-place operation when you have the form > > name =: q} a,:name > > Similar arguments apply. The given variant is in-place, while the > equivalent > > name =: a q}@:,: name > > is not. > > Henry Rich > > > > On 12/22/2011 1:26 PM, Raul Miller wrote: > > I think (but I do not know for sure) that in the explicit case, the > > code gets flagged for special handling when the verb (or adverb or > > conjunction) is being defined. And, I think the code that is doing > > the flagging is rather simple -- it's checking to make sure there are > > no syntax errors, and is designed to be fast. It sees the assignment > > with this code and builds a special copy of the representation of that > > line. > > > > So... if this was correct... the underlying mechanisms (that the > > recognition code is built on) are not there for the more general case. > > This means that the interpreter does not have to pay a speed penalty > > for the general case (and, while the actual evaluation is faster you > > need to also keep in mind that the code analysis is not instant, and > > you have to wait for it to execute every time it runs). > > > > If J were redesigned to perform this kind of code analysis every time > > } was used, it might, for example, delay execution of ,: which would > > cause other problems: > > > > Every operation would be slower (because every operation would now > > have to check to see if it was being passed a delayed ,: before it > > could do anything else). > > > > J would be a larger program (because every operation would need new code). > > > > J would probably have new bugs (because all of this new code will need > > to be debugged after it's implemented). > > > > So that particular implementation is probably a bad idea. > > > > Another variation might involve a re-designed parser (which would also > > add complexity and add new opportunities for bugs). This one might > > actually be worthwhile, if it could do a better job of supporting > > special code than the current one does. But designing a new parser > > system which does not change the language syntax and does the analysis > > needed for this kind of special code (and which is still fast enough) > > is no small task. But you if you feel like designing and implementing > > one, it would be a very interesting project. > > > > (I imagine that an "efficient" implementation would introduce and > > manage the deferred execution needed for the various sorts of special > > code. It's "just a small matter of engineering" to make that kind of > > thing worth using.) > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
