The conflicts start happening when get into variants and try making them work together.
This kind of process inherently leads to ambiguities and of course the computer has to have predefined rules that it will use to resolve them. It takes some thought to decide how to best resolve those ambiguities. In this case, we have 'if' and 'unless' which have the same definitions and we have the distinctive code in 'else' and 'then'. This works, but another approach would be to add a third component to the result from 'if' and 'unless' so they are distinct and then alter the definition of 'else' (or maybe 'then') to respect that distinction. A much harder problem would be the 'dangling else' problem. When 'else' is optional that does all sorts of nasty things to the parser (especially if it is to emit meaningful error messages). This problem is perhaps best avoided by making 'else' required, but some people like exploring those painful consequences. Thanks, -- Raul On Wed, Feb 5, 2014 at 10:12 AM, Michal Wallace <michal.wall...@gmail.com> wrote: > On Tue, Feb 4, 2014 at 10:22 AM, Raul Miller <rauldmil...@gmail.com> wrote: >> Let me know if you want any explanation of either this variant or of >> the variant at > http://jsoftware.com/pipermail/programming/2014-February/034884.html >> - questions can help. > > Thanks, but it was pretty readable. :) Once I understood `:6 I tried > recreating your solution without looking a couple times, and it makes sense > to me now. > > Here's a variant that lets you express logical negation of the condition a > bit more naturally: > > unless =: 2 : 'u"_`(v"_)' NB. exactly the same as 'if' > then =: 2 : 'v"_`(0{m)@.([: -. (1{m)`:6)' > > (] unless (e. & 1 3) then _)"0 i.5 > 0 _ 2 _ 4 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
