I understand. Its something I will just add to jpp.
I found an interesting parsing anomaly that I am not sure was intentional all
along, but is cool.
Y=: (&({::))(@:])
]@1 Y i.3 NB. @n is new functionality, but the result is identical to ]@(1 Y)
1
+:@:+/ 1 2 3
22
(+:@:+)/ 1 2 3
22
+:@:(+/) 1 2 3
12
](@1) Y NB. identical result as if no parentheses were applied.
]@1&({::)@:]
The "cool" thing happening here is that ]@1 gets processed first, but then 1 Y
is, and finally (]@). The cool part is that @n does not need to parenthesize
the entire verb train that @v is intended to apply to, if n is the rightmost
element of that verb train.
>
If the main advantage is the removal of one space at the cost of adding
a ':', I doubt whether your proposal will gain enough user support to
make it worth considering. But that's for users to decide.
Henry Rich
On 3/3/2020 12:05 AM, 'Pascal Jasmin' via Programming wrote:
> Forgot for a moment the main reason for {::: proposal.
>
> Parsing rules allow for 1{::: as 2 separate tokens
>
> They dont allow for 1Y. or (1i. for that matter)
>
>
>
> On Monday, March 2, 2020, 06:15:08 p.m. EST, Raul Miller
> <[email protected]> wrote:
>
>
>
>
>
> X. and Y. require shift keys on my keyboard.
>
> Meanwhile, as a general rule, if things have gotten to be complicated
> enough that you need boxed arguments for a dyad, it's pushing things
> to refer to the contents of those boxes numerically.
>
> I mean, certainly, I've done that -- but I prefer other approaches.
>
> (I should probably take my comments here to chat@ -- I'll do that next
> time, I guess?)
>
> Thanks,
>
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
