On Fri, May 21, 2021 at 4:36 PM Ralph Mellor wrote:
>
> * Things multiply. If *two* function arguments are junctions, and
> each junction has, say, three elements, the function is set to be
> called *six* times.
That should have been *nine* times.
> * The combination has to follow precedence
t: Tuesday, May 25, 2021 4:04 PM
To: perl6-users@perl.org
Subject: Re: File::Find using a junction with exclude
CAUTION - EXTERNAL:
Well spotted, Gianni!
user@mbook:~$ raku -e 'my int $x = 2โถยณ-1;say ++$x;'
-9223372036854775808
user@mbook:~$ raku --version
Welcome to ๐๐๐ค๐ฎ๐๐จโข v2020.10
Well spotted, Gianni!
user@mbook:~$ raku -e 'my int $x = 2โถยณ-1;say ++$x;'
-9223372036854775808
user@mbook:~$ raku --version
Welcome to ๐๐๐ค๐ฎ๐๐จโข v2020.10.
Implementing the ๐๐๐ค๐ฎโข programming language v6.d.
Built on MoarVM version 2020.10.
On Tue, May 25, 2021 at 8:38 AM Gianni Ceccarelli
wrote:
>
On Tue, 25 May 2021 15:16:03 +
Andy Bach wrote:
> > However I had to use "Int" instead of "int":
> Ah, "int" is the "lower" level, native integer and "Int" is the raku.
> An "int" is immutable or something?
It's a bug in the REPL. The example from the documentation works when
fed to the comp
_______
From: William Michels
Sent: Monday, May 24, 2021 11:47 PM
To: perl6-users
Subject: Re: File::Find using a junction with exclude
CAUTION - EXTERNAL:
Hi Andy,
A quick test with my (older) Raku install and I was able to get one of the
examples (Daniel's) below
$) { ++$d }('a'|'b,b'|'c');
> Cannot find method 'qast' on object of type NQPMu
>
> > my int $f = 0;
> 0
> > sub foo($) { ++$f }('a' | 'b,b' | 'c');
> Cannot find method 'qast' on object o
Apologies, that should be spelled "intriguing".
--B.
On Mon, May 24, 2021 at 12:41 PM William Michels
wrote:
> WATs are everywhere, and (I'm not trying to pick on one language
> here), I find this SO question to be intruiging:
>
> https://stackoverflow.com/q/58340585/7270649
>
> Joseph (and Ral
'b,b' | 'c');
Cannot find method 'qast' on object of type NQPMu
but my raku's a tad long in tooth
$ raku -v
This is Rakudo version 2020.05.1 built on MoarVM version 2020.05
________
From: William Michels
Sent: Monday, May 24, 2021 2:41
On 2021-05-24 William Michels via perl6-users
wrote:
> Daniel: Thank you for your confirmation on EVAL. Also, I tried parsing
> the ATOM SYMBOL character to look at classification, and this is the
> best I could do (in the Raku REPL):
>
> > say "โ".uniprop
> So
Not-terribly-human-friendly abbrev
WATs are everywhere, and (I'm not trying to pick on one language
here), I find this SO question to be intruiging:
https://stackoverflow.com/q/58340585/7270649
Joseph (and Ralph): thanks for starting off this conversation!
Fernando and Vadim: amazed at your code!
Andy: good questions always welcom
> Oh, and WAT is [short for] "Weird/will Ass Thing"?
No, it's not an abbreviation for anything โ it's the word "what", but
pronounced in a way that
indicates the speaker is surprised/confused. More specifically, it's a
reference to the WAT talk (a
really good one, even if it is about a different
'c');
say $c;
I was sort of hanging on by my fingertips (this completely lost me:
>Or, taking about tricks:
('a' | 'b,b' | 'c')ยป.&(-> $ { ++โ$c });
) but what's that cabbage thing before $c? Oh, and WAT is" Weird/will Ass
Thing"?
__
');
> say $c;
>
> I was sort of hanging on by my fingertips (this completely lost me:
>
>> Or, taking about tricks:
>
> ('a' | 'b,b' | 'c')ยป.&(-> $ { ++โ$c });
>
> ) but what's that cabbage thing before $c? Oh, and WAT i
>
> ) but what's that cabbage thing before $c? Oh, and WAT is" Weird/will Ass
> Thing"?
> From: Vadim Belman mailto:vr...@lflat.org>>
> Sent: Monday, May 24, 2021 8:53 AM
> To: perl6-users mailto:perl6-users@perl.org>>
> Subject: Re: File::Find using
#x27;s that cabbage thing before $c? Oh, and WAT is" Weird/will Ass
Thing"?
From: Vadim Belman
Sent: Monday, May 24, 2021 8:53 AM
To: perl6-users
Subject: Re: File::Find using a junction with exclude
CAUTION - EXTERNAL:
Still ugly but much more reliable trick
Still ugly but much more reliable trick would be to use a sub and a counter
variable:
my atomicint $c = 0;
sub foo($) { ++โ$c }('a' | 'b,b' | 'c');
say $c;
Or, taking about tricks:
('a' | 'b,b' | 'c')ยป.&(-> $ { ++โ$c });
Apparently, this one is not ugly by semantics, but by its notation too. A
> It can be done without the EVAL:
>
>> any('a', 'b', 'c').raku.substr(4, *-1).split(',').elems
>
> 3
Yeah, but only at the cost of some fragility:
> any('a', 'b,b', 'c').raku.substr(4, *-1).split(',').elems
4
I suppose you could do:
> any('a', 'b,b', 'c').elems.raku.substr(4, *-1).split(',')
It can be done without the EVAL:
> any('a', 'b', 'c').raku.substr(4, *-1).split(',').elems
3
On Mon, May 24, 2021 at 1:07 PM Daniel Sockwell
wrote:
> > But .EVAL is evil, right?
>
> Indeed! And
> any('a', 'b', 'c').raku.substr(3).EVAL.elems;
> arguably deserves _extra_ evil points for usin
> But .EVAL is evil, right?
Indeed! And
any('a', 'b', 'c').raku.substr(3).EVAL.elems;
arguably deserves _extra_ evil points for using the .EVAL method which, unlike
the
EVAL sub, doesn't even warn about how dangerous it is (even though it probably
should).
But .EVAL is evil, right? --B.
On Sun, May 23, 2021 at 9:38 PM Daniel Sockwell wrote:
>
> > For example, you can't get a count of the number of elements in a junction
>
> Well, if you're willing to stoop to ugly enough hacks, there's _always_ a
> way :D
>
> any('a', 'b').raku.substr(3).EVAL.elem
> For example, you can't get a count of the number of elements in a junction
Well, if you're willing to stoop to ugly enough hacks, there's _always_ a
way :D
any('a', 'b').raku.substr(3).EVAL.elems # OUTPUT ยซ3ยป
> My guess would be that the `ACCEPTS` method for a Junction
is special cased to ha
On Sun, May 23, 2021 at 9:15 PM Joseph Brenner wrote:
>
> Junctions continue to surprise me:
That must be either that your mental model doesn't match the
default design, or you're being tripped up by DWIMs, or WATs
that can't be removed due to the overall DWIM of junctions
(which usually work gre
On Sun, May 23, 2021 at 9:12 PM Joseph Brenner wrote:
>
> my impression was that junctions, by design aren't supposed to be
> treated as compound data structures, they're a *single* thing but
> with multiple values that co-exist with each other in "superposition".
That's correct.
Until they're e
On Sun, May 23, 2021 at 3:22 AM Joseph Brenner wrote:
>
> > That is a large part of the beauty of the junction design. All functions
> > (and thus all operators) automatically get a very useful and powerful
> > junctional behavior for free. They don't even know junctions exist.
>
> I can see the p
You're wrong in your expectations. Smartmatch as such is implemented by ACCEPTS
method of its RHS. It is Junction.ACCEPTS in our case. Unfortunately, the
method is not documented for Junction, but it considers itself a boolean
context and, correspondingly, collapses the junction.
Not it is tr
This:
$junction>>.say;
works the way it is because the junction is passed as an argument to the hyper
operator where the normal rules apply. Try it this way:
say $junction>>.say;
and it will result in:
a
b
c
any((True), (True), (True))
Best regards,
Vadim Belman
> On May 23, 2021, at 4:12 P
Junctions continue to surprise me:
my $junction = any( 'a', 'b', 'c' );
my $char = 'b';
say $char ~~ $junction; # True
say $char eq $junction; # any(False, True, False)
$char = 'e';
say $char ~~ $junction; # False
say $char eq $junction; # any(False, False, False)
I w
William Michels wrote:
> my $exclude3 = ( rx/<|w>mothera$/, rx/<|w>camel$/ );
> my @files3 = find( dir => $loc, type => 'file', exclude => $exclude3>>.any
> );
> say "Exclude3: ", @files3;
> #Exclude3: ["/Users/me/test_folder/.DS_Store".IO
> "/Users/me/test_folder/godzilla".IO "/Users/me/test_fol
Ralph Mellor wrote:
> A junction passed as an argument is immediately expanded unless
> a function is specifically coded to handle junctions for that argument.
>
> That is a large part of the beauty of the junction design. All functions
> (and thus all operators) automatically get a very useful a
Vadim Belman wrote:
>> Joseph Brenner wrote:
>>
>>> I just gave a few other variants a try-- passing a junction in a
>> variable, passing a code block containing a [junction]-- without any
>> luck.
> To my view, this behavior of File::Find is going against DWIM and is
> certainly LTA.
Thanks,
On Fri, May 21, 2021 at 9:39 PM Joseph Brenner wrote:
>
> Thanks, yes the actual result is certainly consistent with the
> junction applied at the top level, and not internally, which is
> what I was expecting.
A junction passed as an argument is immediately expanded unless
a function is specific
I tried this--from your original file, not your most recent attempt--and
couldn't get it to work. If you look below, "mothera" never gets excluded,
except the last test (Exclude4), which is the control case (single regex,
no any junction):
my @exclude1 = ( rx/<|w>mothera$/, rx/<|w>camel$/ );
my @f
To my view, this behavior of File::Find is going against DWIM and is certainly
LTA. Anyway, what you you probably is looking for is something like
exclude => { $_ ~~ any(@exclude) }
BTW, the only thing File::Find needs to work with junctions is to declare
:$exclude as Mu. In this case the cal
> I just gave a few other variants a try-- passing a junction in a
variable, passing a code block containing a function-- without any
luck.
Sorry, I mean a code block containing a *junction* or course.
Like:
my @exclude = ( rx/<|w>mothera$/, rx/<|w>camel$/ );
my $any_exclude = any(@e
Thanks, yes the actual result is certainly consistent with the
junction applied at the top level, and not internally, which is what I
was expecting.
Is there actually no way to pass a junction in to a function so that
it can be used later in an internal smartmach? That's been my rough
impression
Your results are what I would expect.
The hand crafted regex puts the exclusion logic in the *single*
regex that's applied by the *single* call to the `find` function.
The `any` value results in calling the `find` function *twice*,
with 'mothera' excluded one time, and 'camel' excluded the
second
The documentation for File::Find says that the exclude argument
is applied via a smart-match, so I thought that I could use a
junction, like so:
use File::Find
my @files = find( dir => $loc, type => 'file', exclude => any(
@exclude_pats ) );
But instead of getting an array of file names (ei
37 matches
Mail list logo
