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".
Thanks, makes sense. > I'm not exactly sure what sort of warning should go here, or how it'd be > detected. Yes, exactly. From one point of view it's working as designed-- to me it felt pretty weird, though. Speculating wildly: could there be a need for a different type of function with different precedence? On 6/21/20, 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? >
