Front page | perl.perl6.users |
Postings from June 2020
Re: junctions and parenthesis
Thread Previous
|
Thread Next
From:
Brad Gilbert
Date:
June 25, 2020 00:57
Subject:
Re: junctions and parenthesis
Message ID:
CAD2L-T1P+MJc8xpt7835gBm01HGHExThTqx_ZeWO5DQCR9nh-A@mail.gmail.com
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-users@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 <pmichaud@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?
>
Thread Previous
|
Thread Next