You're quite correct Brad, so maybe I mis-stated my observation: > any(<a b c> eq any(<c d>)) any(any(False, False)) > <a b c> eq any(<c d>) any(False, False) >
Would the first line of code above code (wrapping an 'eq' call inside an any-junction, along with another any-junction) be written by a Raku programmer? If so, what would his/her objective be? Doesn't the second line of code suffice? In Joseph's/Patrick's code, the external 'any' seems to only resolve to a taking a single (internal, nested) any-junction argument, while in your example, the external 'any' takes three internal, nested any-junction arguments. Best, Bill. On Wed, Jun 24, 2020 at 5:57 PM Brad Gilbert <b2gi...@gmail.com> wrote: > > It does actually make sense to call any on any > > say (1, 2, 3).any + (4, 5, 6).any > # any(any(5, 6, 7), any(6, 7, 8), any(7, 8, 9)) > > On Wed, Jun 24, 2020 at 6:22 PM William Michels via perl6-users > <perl6-us...@perl.org> wrote: >> >> I evaluated Joe's code using Patrick's explanation of parentheses-less >> parsing (in the REPL): >> >> > say(so(any(<a b c> eq any(<c d>)))); >> False >> > say any(<a b c> eq any(<c d>)); >> any(any(False, False)) >> > >> >> Q1. Does it make any sense to call "any" on "any" (i.e. nested "any" >> calls)? Could this anti-pattern be used to generate a warning, i.e. >> 'Useless use of nested any-junctions, did you mean...' or something >> similar? >> >> > say any(<a b c> eq any(<c d>)); >> any(any(False, False)) >> > say any(<c d> eq any(<a b c>)); >> any(any(False, False, False)) >> > >> >> Q2. Swapping the first argument <a b c> to the binary infix operator >> 'eq' with the second argument <c d> results in two different code >> evaluations (above). Can this be used to alert the user to a potential >> violation of the commutative property of equality? Again, maybe useful >> for generating a warning (at least in the REPL), " Warning: >> Commutativity--code without parentheses evaluates differently based on >> LHS vs RHS ordering of arguments to "eq" operator... ." >> >> (note, the second suggestion won't help if each argument to the "any" >> calls surrounding 'eq' are an equivalent number of elements). >> >> HTH, Bill. >> >> >> >> On Sun, Jun 21, 2020 at 8:12 PM Patrick R. Michaud <pmich...@pobox.com> >> wrote: >> > >> > The "any" function is just like any other function taking an arbitrary >> > list of arguments (including user-defined functions). As such it parses >> > with lower precedence than comparison operators -- so "eq" binds more >> > tightly than "any". >> > >> > Thus >> > >> > say so any <a b c> eq any <c d>; >> > >> > parses like >> > >> > say(so(any(<a b c> eq any(<c d>)))); >> > >> > which is indeed False. >> > >> > I'm not exactly sure what sort of warning should go here, or how it'd be >> > detected. But perhaps others have ideas. >> > >> > Pm >> > >> > >> > On Sun, Jun 21, 2020 at 07:00:23PM -0700, Joseph Brenner wrote: >> > > I was just playing around with junctions a bit today, and I >> > > noticed that if you weren't religious about using parenthesis >> > > with them you could get quietly tripped up: >> > > >> > > say so any(<a b c>) eq any(<c d>); # True (as expected) >> > > say so any(<a b c>) eq any(<d e f>); # False (as expected) >> > > say so any <a b c> eq any <c d>; # False (something's wrong) >> > > >> > > Basically, you need the parens on that first use of any. >> > > >> > > Is there a reason you don't at least get a warning if you don't?
