Hm, this must be *the* newbie question, it was the first one I asked, too! For better or for worse, J has the concept of trains (hooks and forks) which - while simplifying some tasks - cause a disparity between "inline" code interpreted as a one-liner and code made up of functions.
The problem, if you consider it such, arises in part with the left-associative nature of J. So, in your example, */ >: i.5 is executed as (*/ (>: ( i.5))) However, if you have fact =. (*/ >:i.) then, like you say, it becomes a fork - three verbs in a row - and since the monadic case of a fork, i.e. (fgh)y is equiv to (fy) g (hy) when you evaluate fact 5, you end up evaluating (*/ 5) >: (i.5) => 5 >: (0 1 2 3 4) => 1 1 1 1 1 since 5 is indeed greater than the numbers 0-4 Now, the fork (fgh), in its monadic form, can be very useful in some cases, for instance you can say sinpluscos =. 1&o. + 2&o. and then (sinpluscos 1) will give you 1.38177 which is what you want, ((sin 1) + (cos 1)) So in such cases it's great. It is less great when - as in your example - you have a cascade of verb applications, i.e. a composition of verbs, where you want (f(g(h))) y to evaluate to (f (g (h y))) i.e (f © g © h) y (excuse the silly "of"/compose symbol, ©, email limitations) Here the composition has to be stated explicitly, and for this you have to use @: or @ although I won't go into the difference between the two here. So (*/ @: >: @: i. ) gives you what you want. Another way to "fight" this unwanted effect of forks, is to use the fork itself (fight forks with forks, so to speak), along with the verb [: cap, which is kind of a null, do-nothing function (someone else will explain better). For example ([: >: i.) becomes (>: @: i.) and ([: */ [: >: i.) => (*/ @: ([: >: i.)) => (*/ @: >: @: i.) The two are equivalent notations, and each seems to have its own adherents, as you will see if you follow the conversations on this list. For those of us who are used to seeing the defined and the inline forms without any differences, however, the notation can be a bit disconcerting. I shall need several more years of J experience before I can have an opinion as to whether it was a good design decision or not! Seems to cause a few problems for beginners, though! If we made a FAQ, this would probably be q1 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
