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
