(small bug with workaround, but not patch, follows)
Hi, For a User-defined command defined with a lambda, I expect the omega
is "the command entered by the user is passed to APL_fun as an APL string
(starting with the command name)." Consider the case where the interactive
user-defined command typed is: )ret 21 1
Welcome to GNU APL version 1.9 / SVN: 1825
<snip>
' ' ⍷ ')ret 21 1' ⍝ Where are the spaces?
0 0 0 0 1 0 0 1 0
showspace ← { ' '⍷⍵} ⍝ Direct function (lambda)
showspace ')ret 21 1' ⍝ Where are the spaces?
0 0 0 0 1 0 0 1 0
]usercmd )ret { ' '⍷⍵ }
User-defined command )ret installed.
)ret 21 1 ⍝ Huh?
1 1 1 1 1 1 1 1 1
]usercmd )nik showspace
User-defined command )nik installed.
)nik 21 1 ⍝ But this is OK?!
0 0 0 0 1 0 0 1 0
]usercmd )low { (⎕ucs32)⍷⍵}
User-defined command )low installed.
)low 21 1
0 0 0 0 1 0 0 1 0
I surmise the parser is inadvertently stripping spaces in literals in ]ucmd
lambdas but not direct function lambda. This comment in cmd_USERCMD()
indicates awareness, but the lambda definition has already been sliced
into args[].
// lambdas could contain spaces, collect all arguments in one
string
...and reassembly into "one string" has the unwelcome effect of dropping
whitespace.
Cheers,
