bill lam wrote:
> What is the current behavior for m...@.n or m...@.v if n or result of v is
> non-scalar (also non-box)?
It's different for m...@.n and m...@.v if the result of v is non-scalar (the
topic of this thread).
For m...@.n with open (non-boxed) n the result is effectively (n { m)`:6
, ie the list of gerunds n is selected from m and executed to produce
a train. If m...@.n has an argument or two then the train is applied to
(or between) those arguments.
For m...@.v if the result if v is non-scalar, an error is raised. Pepe
and I proposed this error be replaced by the identity m...@.v y <--> m...@.(v
y) y (hence the same as m...@.n y ) and analogously for x m...@.v y .
Roger seems to think the idea has merit.
-Dan
PS: There is also a useful definition for m...@.n where n is boxed.
Effectively the train produced is parenthesized according to the boxing.
I made use of this obscure feature in my "tacit evoke" tool.
If you're interested in how @.(boxes) is useful, see my message that
Jose quotes at the bottom of
http://www.jsoftware.com/pipermail/general/2009-August/033224.html (I
can't link to the original message because it was truncated). If you want
to see the actual implementation, the script itself is at
http://www.jsoftware.com/svn/DanBron/trunk/environment/anonymous_evoke2.ijs
.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
