It seems to me that arbitrarily changing the precedence of a function
would produce a horrible maintenance nightmare.
It would mean recognising what had been done, interpreting the first
example found in a different way than any other code, then tracking
down any other place the trick had been
You're quite correct Brad, so maybe I mis-stated my observation:
> any( eq any())
any(any(False, False))
> eq any()
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
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
I evaluated Joe's code using Patrick's explanation of parentheses-less
parsing (in the REPL):
> say(so(any( eq any(;
False
> say any( eq any());
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
> I would suggest calling .any on the list, that gives you just the tight
> preference you want; even if there were no .any method available on the
> object you've got, or you want a different function, you can .
That's a good thought. The code wouldn't read as nicely, though (the
syntax is
On 22/06/2020 20:12, Joseph Brenner wrote:
> > Speculating wildly: could there be a need for a different type of >
function with different precedence?
I would suggest calling .any on the list, that gives you just the tight
preference you want; even if there were no .any method available on the
On Mon, 22 Jun 2020, Elizabeth Mattijsen wrote:
> BEGIN trait_mod:(, :tighter(:<*>));
>
> comes to mind, but that doesn't seem to do the trick.
>
My guess: tighter and looser are only consulted by the parser
in contexts where 'any' was recognized as an *operator*.
BEGIN trait_mod:(, :tighter(:<*>));
comes to mind, but that doesn't seem to do the trick.
> On 22 Jun 2020, at 21:11, Tobias Boege wrote:
>
> On Mon, 22 Jun 2020, Joseph Brenner wrote:
>> Patrick R. Michaud wrote:
>>
>>> The "any" function is just like any other function taking an arbitrary
On Mon, 22 Jun 2020, Joseph Brenner wrote:
> Patrick R. Michaud 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
Patrick R. Michaud 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
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 eq any ;
parses like
say(so(any( eq
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() eq any(); # True (as expected)
say so any() eq any(); # False (as expected)
say so any eq any ;
12 matches
Mail list logo
