Re: File::Find using a junction with exclude
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 rules. I forget what > they are, but the general scheme is that there are two levels > and they do what's most natural. This will of course sound very > odd so I'll leave it as a thing to explore if you explore this. :) I just looked in the doc and didn't see discussion of this. And my investigations began to confuse me. Here's a relatively gentle start focusing on the *operator precedence* of the *junction literal constructor operators*: ``` say 1 & 2 | 3 & 4; # any(all(1, 2), all(3, 4)) say 1 | 2 & 3 | 4; # any(1, all(2, 3), 4) ``` So the `&` junction op has higher operator precedence than `|`. This is covered in the doc, starting at: https://docs.raku.org/language/operators#Junctive_AND_(all)_precedence The compiler rejects mixing of `|` or `&` infix ops with `^` without parens to disambiguate, and there is no `none` infix op, so the above is the only precedence issue to consider for the junction literal creation infix ops. Next comes combining two or more junctions with other ops / functions. The focus now is on "precedence" due to combining junctions with functions (or operators) that aren't themselves junction constructors: So this isn't about *operator* precedence but instead *junction data* precedence. I'll again start with a gentle example, switching to functions (methods) to avoid confusion with *operator* precedence: ``` say(1,2).all le (1, 2).one; # all(one(True, True), one(False, True)) say so (1,2).all le (1, 2).one; # False say(1,2).one le (1, 2).all; # all(one(True, True), one(False, True)) say so (1,2).one le (1, 2).all; # False ``` This indicates that `one` junctions have higher "precedence" than `all`. I'm going to stop at this point because I got confused about the exact "precedence" relationship between the four sorts of junctions and felt this was potentially a good launch point for others. If no one else does look into this I may return to this another day but no promises. -- love, raiph
Re: File::Find using a junction with exclude
> It's a bug in the REPL. The example from the documentation works when fed to the compiler directly So is the error Cannot find method 'qast' on object of type NQPMu any use in finding the REPL bug? From: William Michels via perl6-users Sent: 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. Implementing the 퐑퐚퐤퐮™ programming language v6.d. Built on MoarVM version 2020.10. On Tue, May 25, 2021 at 8:38 AM Gianni Ceccarelli mailto:dak...@thenautilus.net>> wrote: On Tue, 25 May 2021 15:16:03 + Andy Bach mailto:andy_b...@wiwb.uscourts.gov>> 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 compiler directly:: $ raku -e 'my int $x = 2⁶³-1;say ++$x;' -9223372036854775808 -- Dakkar - GPG public key fingerprint = A071 E618 DD2C 5901 9574 6FE2 40EA 9883 7519 3F88 key id = 0x75193F88 CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary. Exercise caution when opening attachments or clicking on links.
Re: File::Find using a junction with exclude
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 compiler directly:: > > $ raku -e 'my int $x = 2⁶³-1;say ++$x;' > -9223372036854775808 > > -- > Dakkar - > GPG public key fingerprint = A071 E618 DD2C 5901 9574 > 6FE2 40EA 9883 7519 3F88 > key id = 0x75193F88 > >
Re: File::Find using a junction with exclude
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 compiler directly:: $ raku -e 'my int $x = 2⁶³-1;say ++$x;' -9223372036854775808 -- Dakkar - GPG public key fingerprint = A071 E618 DD2C 5901 9574 6FE2 40EA 9883 7519 3F88 key id = 0x75193F88
Re: File::Find using a junction with exclude
> 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? The page
https://docs.raku.org/language/numerics#Native_numerics
has:
my int $x = 2⁶³-1;
say $x; # OUTPUT: «9223372036854775807»
say ++$x; # OUTPUT: «-9223372036854775808»
But I see
> my int $x = 2⁶³-1
9223372036854775807
> say $x
9223372036854775807
> say ++$x
Cannot find method 'qast' on object of type NQPMu
NQP (Not Quite Perl) Mu has no "qast" method - qast is the successor to past,
Parrot AST and AST is Abstract Syntax Tree. I guess $x *is * the int, not an
container/variable holding an int value.
Man, there's a lot I don't know about raku! That section on colon pairs
cleared up a lot.
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 to work. However I had to use "Int" instead of "int":
user@mbook:~$ raku
Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
Implementing the 퐑퐚퐤퐮™ programming language v6.d.
Built on MoarVM version 2020.10.
To exit type 'exit' or '^D'
> my int $f = 0;
0
> sub foo($) { ++$f }('a' | 'b,b' | 'c');
Cannot find method 'qast' on object of type NQPMu
> my Int $g = 0;
0
> sub foo($) { ++$g }('a' | 'b,b' | 'c');
any(1, 2, 3)
>
HTH, Bill.
On Mon, May 24, 2021 at 2:40 PM Andy Bach
mailto:andy_b...@wiwb.uscourts.gov>> wrote:
> Cannot sent this email in 'plain text' mode as ATOM SYMBOL disappears.
I was impressed I could copypasted that in the text/terminal sesion of raku's
REPL and have it work. As a matter of fact:
> sub foo($) { ++⚛$c }('a' | 'b,b' | 'c');
any(1, 2, 3)
> say $c;
3
but, trying it without the cabbage, er, atomic symbol
> my atomicint $d = 0;
0
> sub foo($) { ++$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 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 mailto:w...@caa.columbia.edu>>
Sent: Monday, May 24, 2021 2:41 PM
To: perl6-users mailto:perl6-users@perl.org>>
Subject: Re: File::Find using a junction with exclude
CAUTION - EXTERNAL:
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 welcome!
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
> dd "⚛".comb>>.uniprop
("So",)
Nil
> say "{uniparse 'ATOM SYMBOL'}"
⚛
> say "{uniparse 'ATOM SYMBOL'}".uniprop
So
> say "{uniparse 'ATOM SYMBOL'}".uniprop('Alphabetic')
False
HTH, Bill.
PS. Cannot sent this email in 'plain text' mode as ATOM SYMBOL disappears.
On Mon, May 24, 2021 at 11:28 AM Daniel Sockwell
mailto:dan...@codesections.com>> wrote:
> 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 language)
https://www.destroyallsoftware.com/talks/wat
(All of that is pretty much strait from the glossary, by the way)
https://docs.raku.org/language/glossary#index-entry-WAT
– codesections
CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary. Exercise
caution when opening attachments or clicking on links.
CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary. Exercise
caution when opening attachments or clicking on links.
Re: File::Find using a junction with exclude
Hi Andy,
A quick test with my (older) Raku install and I was able to get one of the
examples (Daniel's) below to work. However I had to use "Int" instead of
"int":
user@mbook:~$ raku
Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
Implementing the 퐑퐚퐤퐮™ programming language v6.d.
Built on MoarVM version 2020.10.
To exit type 'exit' or '^D'
> my int $f = 0;
0
> sub foo($) { ++$f }('a' | 'b,b' | 'c');
Cannot find method 'qast' on object of type NQPMu
> my Int $g = 0;
0
> sub foo($) { ++$g }('a' | 'b,b' | 'c');
any(1, 2, 3)
>
HTH, Bill.
On Mon, May 24, 2021 at 2:40 PM Andy Bach
wrote:
> > Cannot sent this email in 'plain text' mode as ATOM SYMBOL disappears.
>
> I was impressed I could copypasted that in the text/terminal sesion of
> raku's REPL and have it work. As a matter of fact:
> > sub foo($) { ++⚛$c }('a' | 'b,b' | 'c');
> any(1, 2, 3)
> > say $c;
> 3
>
> but, trying it without the cabbage, er, atomic symbol
> > my atomicint $d = 0;
> 0
> > sub foo($) { ++$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 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 PM
> *To:* perl6-users
> *Subject:* Re: File::Find using a junction with exclude
>
>
> *CAUTION - EXTERNAL: *
> 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 welcome!
>
> 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
> > dd "⚛".comb>>.uniprop
> ("So",)
> Nil
> > say "{uniparse 'ATOM SYMBOL'}"
> ⚛
> > say "{uniparse 'ATOM SYMBOL'}".uniprop
> So
> > say "{uniparse 'ATOM SYMBOL'}".uniprop('Alphabetic')
> False
>
> HTH, Bill.
>
> PS. Cannot sent this email in 'plain text' mode as ATOM SYMBOL disappears.
>
>
> On Mon, May 24, 2021 at 11:28 AM Daniel Sockwell
> wrote:
>
> > 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 language)
> https://www.destroyallsoftware.com/talks/wat
>
> (All of that is pretty much strait from the glossary, by the way)
> https://docs.raku.org/language/glossary#index-entry-WAT
>
> – codesections
>
> *CAUTION - EXTERNAL EMAIL:* This email originated outside the Judiciary.
> Exercise caution when opening attachments or clicking on links.
>
Re: File::Find using a junction with exclude
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 Ralph): thanks for starting off this conversation!
> Fernando and Vadim: amazed at your code!
> Andy: good questions always welcome!
>
> 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
> > dd "⚛".comb>>.uniprop
> ("So",)
> Nil
> > say "{uniparse 'ATOM SYMBOL'}"
> ⚛
> > say "{uniparse 'ATOM SYMBOL'}".uniprop
> So
> > say "{uniparse 'ATOM SYMBOL'}".uniprop('Alphabetic')
> False
>
> HTH, Bill.
>
> PS. Cannot sent this email in 'plain text' mode as ATOM SYMBOL disappears.
>
>
> On Mon, May 24, 2021 at 11:28 AM Daniel Sockwell
> wrote:
>
>> > 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 language)
>> https://www.destroyallsoftware.com/talks/wat
>>
>> (All of that is pretty much strait from the glossary, by the way)
>> https://docs.raku.org/language/glossary#index-entry-WAT
>>
>> – codesections
>>
>
Re: File::Find using a junction with exclude
> Cannot sent this email in 'plain text' mode as ATOM SYMBOL disappears.
I was impressed I could copypasted that in the text/terminal sesion of raku's
REPL and have it work. As a matter of fact:
> sub foo($) { ++⚛$c }('a' | 'b,b' | 'c');
any(1, 2, 3)
> say $c;
3
but, trying it without the cabbage, er, atomic symbol
> my atomicint $d = 0;
0
> sub foo($) { ++$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 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 PM
To: perl6-users
Subject: Re: File::Find using a junction with exclude
CAUTION - EXTERNAL:
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 welcome!
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
> dd "⚛".comb>>.uniprop
("So",)
Nil
> say "{uniparse 'ATOM SYMBOL'}"
⚛
> say "{uniparse 'ATOM SYMBOL'}".uniprop
So
> say "{uniparse 'ATOM SYMBOL'}".uniprop('Alphabetic')
False
HTH, Bill.
PS. Cannot sent this email in 'plain text' mode as ATOM SYMBOL disappears.
On Mon, May 24, 2021 at 11:28 AM Daniel Sockwell
mailto:dan...@codesections.com>> wrote:
> 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 language)
https://www.destroyallsoftware.com/talks/wat
(All of that is pretty much strait from the glossary, by the way)
https://docs.raku.org/language/glossary#index-entry-WAT
– codesections
CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary. Exercise
caution when opening attachments or clicking on links.
Re: File::Find using a junction with exclude
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 abbreviation for "Symbol, other", see also
https://en.wikipedia.org/wiki/Unicode_character_property#General_Category
> > say "{uniparse 'ATOM SYMBOL'}".uniprop('Alphabetic')
> False
> say '⚛'.uniprop('Symbol')
1
> say '⚛'.uniprop('Letter')
0
> say '⚛'.uniprop('Alphabetic')
False
(I feel that `False` is out of place…)
--
Dakkar -
GPG public key fingerprint = A071 E618 DD2C 5901 9574
6FE2 40EA 9883 7519 3F88
key id = 0x75193F88
Re: File::Find using a junction with exclude
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 welcome!
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
> dd "⚛".comb>>.uniprop
("So",)
Nil
> say "{uniparse 'ATOM SYMBOL'}"
⚛
> say "{uniparse 'ATOM SYMBOL'}".uniprop
So
> say "{uniparse 'ATOM SYMBOL'}".uniprop('Alphabetic')
False
HTH, Bill.
PS. Cannot sent this email in 'plain text' mode as ATOM SYMBOL disappears.
On Mon, May 24, 2021 at 11:28 AM Daniel Sockwell
wrote:
> > 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 language)
> https://www.destroyallsoftware.com/talks/wat
>
> (All of that is pretty much strait from the glossary, by the way)
> https://docs.raku.org/language/glossary#index-entry-WAT
>
> – codesections
>
Re: File::Find using a junction with exclude
> 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 language) https://www.destroyallsoftware.com/talks/wat (All of that is pretty much strait from the glossary, by the way) https://docs.raku.org/language/glossary#index-entry-WAT – codesections
Re: File::Find using a junction with exclude
> As to "this completely lost me": there was a mistype and "taking" shoud've
> been "talking". Sorry for this.
No, that's wasn't what lost me, it was the code
('a' | 'b,b' | 'c')».&(-> $ { ++⚛$c });
>> Oh, and WAT is" Weird/will Ass Thing"?
> "Weird/will Ass Thing" made me totally lost as I've no idea what this means.
Typo there, too s/b "Weird/Wild". "WAT" was featured heavily in a previous
post, in opposition to DWIM, which I took be Do What I Mean.
____
From: Vadim Belman
Sent: Monday, May 24, 2021 9:31 AM
To: perl6-users
Subject: Re: File::Find using a junction with exclude
CAUTION - EXTERNAL:
As to " but what's that cabbage thing before $c?": we have this great
https://docs.raku.org site. And it has great search capability:
https://docs.raku.org/type/atomicint
https://docs.raku.org/language/unicode_ascii#index-entry-%E2%9A%9B
As to "this completely lost me": there was a mistype and "taking" shoud've been
"talking". Sorry for this.
"Weird/will Ass Thing" made me totally lost as I've no idea what this means.
Best regards,
Vadim Belman
On May 24, 2021, at 10:11 AM, Andy Bach
mailto:andy_b...@wiwb.uscourts.gov>> wrote:
my atomicint $c = 0;
sub foo($) { ++⚛$c }('a' | 'b,b' | '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"?
____________
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 a junction with exclude
CAUTION - EXTERNAL:
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. Also
worth noting that the hyper-op is needed here because pointy blocks are not
auto-threaded over junctions and take them as-is:
-> $v { say $v.WHAT }(1|2); # (Junction)
Best regards,
Vadim Belman
> On May 24, 2021, at 8:42 AM, Daniel Sockwell
> mailto:dan...@codesections.com>> wrote:
>
>> 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(',').elems
> 3
>
> but I'm not sure that's _that_ much better than EVAL – either way, we're
> depending on the Str
> representation of inherently non-Str data, which seems like the main sin of
> EVAL.
>
> – codesections
>
CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary. Exercise
caution when opening attachments or clicking on links.
CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary. Exercise
caution when opening attachments or clicking on links.
Re: File::Find using a junction with exclude
> but what's that cabbage thing before $c?
It's the Atomic Symbol, U+269B. (Tangent: when looking up that unicode value, I
learned
that Unicode puts the atomic symbol in the Religious Symbols subcatigory.
Slightly troubling!)
Here, it's being used as part of the atomic prefix increment operator,
https://docs.raku.org/type/atomicint#prefix_++⚛ (As Vadim already mentioned).
That operator is exactly like the regular prefix ++, except that it's
guaranteed to avoid
race conditions in multithreaded use. It's appropriate to use with Junctions,
because they're
theoretically multitheadable. On the other hand, they *aren't* yet
multithreaded in any
implementation, so for now
my $c = 0;
sub foo($) { ++$c }('a'|'b,b'|'c');
say $c;
works just as well (though the semantics are technically wrong!)
> Also worth noting that the hyper-op is needed here because pointy blocks are
> not auto-threaded
> over junctions and take them as-is
Interesting – I didn't realize that. Is the hyper op the only thing that
triggers auto-threading
for Blocks?
Here's a slightly different take on the same basic idea, which avoids leaking
$c:
{my atomicint $len; sub ($) { ++⚛$len }($_); $len}('a'|'b,b'|'c')
May 24, 2021 10:11 AM, "Andy Bach" wrote:
> my atomicint $c = 0;
> sub foo($) { ++⚛$c }('a' | 'b,b' | '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"?
>
> ___
>
> 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 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. Also
> worth noting that the
> hyper-op is needed here because pointy blocks are not auto-threaded over
> junctions and take them
> as-is:
>
> -> $v { say $v.WHAT }(1|2); # (Junction)
>
> Best regards,
> Vadim Belman
>
>> On May 24, 2021, at 8:42 AM, Daniel Sockwell wrote:
>
> 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(',').elems
>> 3
>>
>> but I'm not sure that's _that_ much better than EVAL – either way, we're
>> depending on the Str
>> representation of inherently non-Str data, which seems like the main sin of
>> EVAL.
>>
>> – codesections
>
> CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary.
> Exercise caution when
> opening attachments or clicking on links.
Re: File::Find using a junction with exclude
As to " but what's that cabbage thing before $c?": we have this great
https://docs.raku.org site. And it has great search capability:
https://docs.raku.org/type/atomicint
https://docs.raku.org/language/unicode_ascii#index-entry-%E2%9A%9B
As to "this completely lost me": there was a mistype and "taking" shoud've been
"talking". Sorry for this.
"Weird/will Ass Thing" made me totally lost as I've no idea what this means.
Best regards,
Vadim Belman
> On May 24, 2021, at 10:11 AM, Andy Bach wrote:
>
> my atomicint $c = 0;
> sub foo($) { ++⚛$c }('a' | 'b,b' | '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"?
> 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 a junction with exclude
>
> CAUTION - EXTERNAL:
>
>
> 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. Also
> worth noting that the hyper-op is needed here because pointy blocks are not
> auto-threaded over junctions and take them as-is:
>
> -> $v { say $v.WHAT }(1|2); # (Junction)
>
> Best regards,
> Vadim Belman
>
> > On May 24, 2021, at 8:42 AM, Daniel Sockwell
> > wrote:
> >
> >> 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(',').elems
> > 3
> >
> > but I'm not sure that's _that_ much better than EVAL – either way, we're
> > depending on the Str
> > representation of inherently non-Str data, which seems like the main sin of
> > EVAL.
> >
> > – codesections
> >
>
> CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary.
> Exercise caution when opening attachments or clicking on links.
Re: File::Find using a junction with exclude
my atomicint $c = 0;
sub foo($) { ++⚛$c }('a' | 'b,b' | '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"?
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 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. Also
worth noting that the hyper-op is needed here because pointy blocks are not
auto-threaded over junctions and take them as-is:
-> $v { say $v.WHAT }(1|2); # (Junction)
Best regards,
Vadim Belman
> On May 24, 2021, at 8:42 AM, Daniel Sockwell wrote:
>
>> 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(',').elems
> 3
>
> but I'm not sure that's _that_ much better than EVAL – either way, we're
> depending on the Str
> representation of inherently non-Str data, which seems like the main sin of
> EVAL.
>
> – codesections
>
CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary. Exercise
caution when opening attachments or clicking on links.
Re: File::Find using a junction with exclude
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. Also
worth noting that the hyper-op is needed here because pointy blocks are not
auto-threaded over junctions and take them as-is:
-> $v { say $v.WHAT }(1|2); # (Junction)
Best regards,
Vadim Belman
> On May 24, 2021, at 8:42 AM, Daniel Sockwell wrote:
>
>> 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(',').elems
> 3
>
> but I'm not sure that's _that_ much better than EVAL – either way, we're
> depending on the Str
> representation of inherently non-Str data, which seems like the main sin of
> EVAL.
>
> – codesections
>
Re: File::Find using a junction with exclude
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 using the .EVAL method which,
> unlike the
> EVAL sub, doesn't even warn about how dangerous it is (even though it
> probably should).
>
--
Fernando Santagata
Re: File::Find using a junction with exclude
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.elems # OUTPUT «3»
>
> > My guess would be that the `ACCEPTS` method for a Junction
> is special cased to handle the junction
>
> I'm not sure that it's all _that_ much of a special case – it seems like
> it mostly follows from the fact that ~~ *both* calls .ACCEPT *and* creates
> a boolean context
> (https://docs.raku.org/language/contexts#index-entry-Boolean_context)
>
> In other words, `'e' ~~ 'e'` is _not_ technically equivalent to `'e' eq 'e'`
> – it's actually equivalent to `?('e' eq 'e')`. Of course, in that case the
> boolean context didn't make a difference because the comparison already
> returned a Bool. But it does make a difference in the Junction case:
>
> any('d', 'e', 'f') ~~ 'e';
> # is the same as
> ?(any('d', 'e', 'f') eq 'e');
>
> And, indeed, both return True.
>
> Hope that helps at least a bit!
>
> – codesections
Re: File::Find using a junction with exclude
> 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 handle the junction
I'm not sure that it's all _that_ much of a special case – it seems like
it mostly follows from the fact that ~~ *both* calls .ACCEPT *and* creates
a boolean context
(https://docs.raku.org/language/contexts#index-entry-Boolean_context)
In other words, `'e' ~~ 'e'` is _not_ technically equivalent to `'e' eq 'e'`
– it's actually equivalent to `?('e' eq 'e')`. Of course, in that case the
boolean context didn't make a difference because the comparison already
returned a Bool. But it does make a difference in the Junction case:
any('d', 'e', 'f') ~~ 'e';
# is the same as
?(any('d', 'e', 'f') eq 'e');
And, indeed, both return True.
Hope that helps at least a bit!
– codesections
Re: File::Find using a junction with exclude
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 great). > my $junction = any( 'a', 'b', 'c' ); > my $char = 'b'; > say $char ~~ $junction; # True Does that function (`~~`) do the default thing with junctions or is it a special case? As a general point, hopefully you're seeing why we want to *avoid* special casing as far as is reasonable. Each special case needs to really pull far more than its *individual* weight because there's an inevitable *overall* weight as one needs to get a clear mental model of the default situation *and* the special cases. My guess would be that the `ACCEPTS` method for a Junction is special cased to handle the junction as a single thing rather than not doing so. I mean, special case a Junction function to treat itself as a Junction? That makes sense to me! It's the sort of thing I find easy to, er, accept. *This* is OK to me. Especially if it supports functionality that could not be supported without the special case, which applies in this case. > say $char eq $junction; # any(False, True, False) I'd guess that `eq` is just like 99.9% of functions. And so it is: * The `eq` is called three times. * The results are gathered together and a junction of the appropriate kind that combines the results is returned. The special case here is the `say` (or rather the `gist` that `say` calls). > I would've thought that there'd be no difference there Right, because you're not allowing for DWIMs. (Yet, ironically, asking for a DWIM for the `find` case, when the justification for it is on much less firm ground.) > The smartmatch checks that it's comparing string types, > and does something like an eq on them, right? > So why would going straight to an eq be different? Because Larry felt it was a suitable DWIM. worth the WAT you've just experienced. > But then, there are other cases where junction-in, > junction-out is the only thing that makes sense: > > say $junction ~ 'z'; > # any(az, bz, cz) Right. That's `~`, which, like 99.9% of all functions/ops, is not special cased. -- love, raiph
Re: File::Find using a junction with exclude
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 expanded, they're a single thing. By default, when you call a function (or use an operator, because operators are functions) that isn't special cased to accept an unexpanded junction for a parameter, any argument that's a junction is expanded before calling the function, and the function is applied once per combination of each junction argument's elements. > For example, you can't get a count of the number of elements in a junction: > > my $junction = any( 'a', 'b', 'c' ); > say $junction.elems; # any(1, 1, 1) Right. Like about 99.99% of all functions, `elems` isn't special cased. > But then, this actually works: > > $junction>>.say; > # a > # b > # c Right. Hypers also aren't special cased. So that works as expected (if you expect the very simple rules that drive how it works by default). (It's one hyper call on `a`, one on `b`, one on `c`. The hyper operator does *not* see a junction. It gets call three times, each time with a different invocant.) > So going the other way, using a hyper operator to create a > junction isn't such a silly thing to look at... To *create* one? Sure. But that's unrelated to what's going on in the above. > Though really then this idiom creates an array of multiple any > junctions with single values, which would behave just like the > individual values themselves: > > my $values = < A B C >; > my $junction2 = $values>>.any; > say $junction2; > # (any(A) any(B) any(C)) The `>>` is called three times, once with `A` as its invocant, and so on. The result is a `List` of three `any` junctions, each containing a single element. The variable `$junction2` contains that `List`, not a junction. Now we *do* arrive at the first and only special case among your examples, the `say`, which uses `gist`. The `gist` of a junction is special cased to be a single string providing a human friendly gist of a junction, rather than multiple strings, once for each element of the junction. Thus you get the result you see. This is where some of the *costs* of DWIMs starts to creep in. There are behaviors that don't follow the norm, and thus WATs that need to be explained. Provided the explanations sit well enough with those who experience them for them to get over the shock, all is good, and perhaps even great (one can learn *better* due to a shock than merely things working as expected). The key things are for PL designers and construct/object/function creators to be very judicious about choosing which DWIMS they are willing to be responsible for, valuing WATs as potential teachable moments, and for users to realize that WATs can be a really good thing. -- love, raiph
Re: File::Find using a junction with exclude
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 point, of course. But then by the same token, > function authors do need to think about junctions if it makes > sense to do it the other way. I'm not sure you've seen the point I hoped you'd see. The point of the design as it is is that: * *Users* of *junctions* should be willing to think about what they're doing when they *call* functions. * *Authors* of *functions* should NOT *need* to think about junctions *unless they WANT to*. And they should think VERY carefully before introducing a DWIM, because for every DWIM there's one or more WATs. > At least in this File::Find exclude case there doesn't > seem to be anything useful about the current behavior. As an overall set of points, Chinese Farmer always applies, all these things are subject to our own perspectives, and our perspectives change over time. What follows is my current perspective. The way it is now is consistent with what something like 99.9% of all functions do. That has a *large* value all of its own. While judicious DWIMs are considered a net positive in Raku culture, injudicious ones are damaging. Here be dragons. And what is the cost of leaving it as it is? There's a teachable moment, one we're going through right now. That has value too. And there are easy ways to express the same thing some other way. And what is the benefit of adding a DWIM? There's no great value. If the sole justification for a DWIM is to whack a WAT, what about new WATs? Consider, for example, the DWIM added to `say` and cousins. One can write `say 42 | 99` and get `any(42,99)`. That's a DWIM. What `say` used to do was write `42` on one line and `99` on the next. This is a WAT and the decision was to make `gist` special case. But at what cost? I currently think it was well worth the cost, but there is a cost. Folk will then expect `say` to work like any other function with junctions, but it's a special case. I think there *is* another aspect that's worth discussing that isn't a DWIM. I'll discuss that in another email. -- love, raiph
Re: File::Find using a junction with exclude
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 true with eq which is a normal routine and Raku autothreads over it. It still works well in conditions because they're boolean context and collapse the resulting junction. Best regards, Vadim Belman > On May 23, 2021, at 4:14 PM, Joseph Brenner wrote: > > 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 would've thought that there'd be no difference there > The smartmatch checks that it's comparing string types, > and does something like an eq on them, right? > So why would going straight to an eq be different? > > But then, there are other cases where junction-in, > junction-out is the only thing that makes sense: > >say $junction ~ 'z'; ># any(az, bz, cz) >
Re: File::Find using a junction with exclude
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 PM, Joseph Brenner wrote: > > 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_folder/mothera".IO >> "/Users/me/test_folder/rhodan".IO] > > I wasn't really sure what bill was thinking there, because 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". > > For example, you can't get a count of the number of elements in a junction: > >my $junction = any( 'a', 'b', 'c' ); >say $junction.elems; # any(1, 1, 1) > > But then, this actually works: > >$junction>>.say; ># a ># b ># c > > So going the other way, using a hyper operator to create a > junction isn't such a silly thing to look at... > > Though really then this idiom creates an array of multiple any > junctions with single values, which would behave just like the > individual values themselves: > >my $values = < A B C >; >my $junction2 = $values>>.any; >say $junction2; ># (any(A) any(B) any(C)) >
Re: File::Find using a junction with exclude
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 would've thought that there'd be no difference there The smartmatch checks that it's comparing string types, and does something like an eq on them, right? So why would going straight to an eq be different? But then, there are other cases where junction-in, junction-out is the only thing that makes sense: say $junction ~ 'z'; # any(az, bz, cz)
Re: File::Find using a junction with exclude
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_folder/mothera".IO > "/Users/me/test_folder/rhodan".IO] I wasn't really sure what bill was thinking there, because 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". For example, you can't get a count of the number of elements in a junction: my $junction = any( 'a', 'b', 'c' ); say $junction.elems; # any(1, 1, 1) But then, this actually works: $junction>>.say; # a # b # c So going the other way, using a hyper operator to create a junction isn't such a silly thing to look at... Though really then this idiom creates an array of multiple any junctions with single values, which would behave just like the individual values themselves: my $values = < A B C >; my $junction2 = $values>>.any; say $junction2; # (any(A) any(B) any(C))
Re: File::Find using a junction with exclude
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 and powerful > junctional behavior for free. They don't even know junctions exist. I can see the point, of course. But then by the same token, function authors do need to think about junctions if it makes sense to do it the other way. At least in this File::Find exclude case there doesn't seem to be anything useful about the current behavior.
Re: File::Find using a junction with exclude
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, that's certainly my impression, at least in this case.
> Anyway, what you you probably is looking for is something like
>
> exclude => { $_ ~~ any(@exclude) }
Ah, yes, that works:
my @files = find( dir => $loc, type => 'file', exclude => { $_ ~~
any(@exclude) } );
And I see this works, too:
my @files = find( dir => $loc, type => 'file', exclude => * ~~
any(@exclude) );
> BTW, the only thing File::Find needs to work with junctions is to declare
> :$exclude as Mu. In this case the call to find will not be auto-threaded.
That's an interesting point. I'll think about opening an issue with
File::Find, it might be worth at least thinking about making that
change.
Re: File::Find using a junction with exclude
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 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 and powerful
junctional behavior for free. They don't even know junctions exist.
> Is there actually no way to pass a junction in to a function so that
> it can be used later in an internal smartmach?
(This is Raku. The safer bet is to presume there's a way and you
just don't know what it is.)
My guess is that < 0.1% of Raku functions have the additional
code you're suggesting. But it's easy enough. I haven't tested
this but something like should work, doing whatever it is you
think makes sense for the ... bits:
```
sub find (Junction :$exclude, |rest) {
...
... File::find ..., |rest
...
}
```
Explicitly catching the `Junction` type in the signature means the
"autothreading" doesn't happen.
> That's been my rough impression of what junctions are for,
> a way to have a compound value that's treated as a single
> one until it's used.
If Raku did *not* expand junctions by default, then functions
would have to explicitly decide when to "use" them, which
means all of them would have to A) know about junctions,
B) include explicit code to handle them. It would be awful!
--
love, raiph
Re: File::Find using a junction with exclude
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 @files1 = find( dir => $loc, type => 'file', exclude => @exclude1>>.any
);
say "Exclude1: ", @files1;
#Exclude1: ["/Users/me/test_folder/.DS_Store".IO
"/Users/me/test_folder/godzilla".IO "/Users/me/test_folder/mothera".IO
"/Users/me/test_folder/rhodan".IO]
#
my $exclude2 = ( rx/<|w>mothera$/, rx/<|w>camel$/ );
my @files2 = find( dir => $loc, type => 'file', exclude => any($exclude2) );
say "Exclude2: ", @files2;
#Exclude2: [any(("/Users/me/test_folder/.DS_Store".IO
"/Users/me/test_folder/godzilla".IO "/Users/me/test_folder/mothera".IO
"/Users/me/test_folder/rhodan".IO))]
#
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_folder/mothera".IO
"/Users/me/test_folder/rhodan".IO]
#
my $exclude4 = ( rx/mothera/ );
my @files4 = find( dir => $loc, type => 'file', exclude => $exclude4 );
say "Exclude4: ", @files4;
#Exclude4: ["/Users/me/test_folder/.DS_Store".IO
"/Users/me/test_folder/godzilla".IO "/Users/me/test_folder/rhodan".IO]
HTH, Bill.
On Fri, May 21, 2021 at 1:41 PM Joseph Brenner wrote:
> > 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(@exclude);
> my @files = find( dir => $loc, type => 'file', exclude => {
> $any_exclude } );
> say @files;
> # ["/home/doom/tmp/monster_island/godzilla".IO
> "/home/doom/tmp/monster_island/mothera".IO
> "/home/doom/tmp/monster_island/rhodan".IO]
>
>
> On 5/21/21, 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.
> >
> > 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 of what junctions are for, a way to have a compound value
> > that's treated as a single one until it's used.
> >
> > 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.
> >
>
Re: File::Find using a junction with exclude
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 call to find will not be auto-threaded.
Best regards,
Vadim Belman
> On May 21, 2021, at 4:41 PM, Joseph Brenner wrote:
>
>> 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(@exclude);
> my @files = find( dir => $loc, type => 'file', exclude => {
> $any_exclude } );
> say @files;
> # ["/home/doom/tmp/monster_island/godzilla".IO
> "/home/doom/tmp/monster_island/mothera".IO
> "/home/doom/tmp/monster_island/rhodan".IO]
>
>
> On 5/21/21, 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.
>>
>> 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 of what junctions are for, a way to have a compound value
>> that's treated as a single one until it's used.
>>
>> 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.
>>
>
Re: File::Find using a junction with exclude
> 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(@exclude);
my @files = find( dir => $loc, type => 'file', exclude => {
$any_exclude } );
say @files;
# ["/home/doom/tmp/monster_island/godzilla".IO
"/home/doom/tmp/monster_island/mothera".IO
"/home/doom/tmp/monster_island/rhodan".IO]
On 5/21/21, 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.
>
> 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 of what junctions are for, a way to have a compound value
> that's treated as a single one until it's used.
>
> 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.
>
Re: File::Find using a junction with exclude
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 of what junctions are for, a way to have a compound value that's treated as a single one until it's used. 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.
Re: File::Find using a junction with exclude
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 time.
Thus the result is an `any` junction, with two lists, one with
two files in it, the other with all three.
Consider a one arg function `function`, a one element junction `junction`,
and the following function call:
function junction
This will execute the function `function` once, using the single element
in the junction `junction`, then return a new junction of the same kind as
`junction` with one element, which will be the result of having called the
function `function` with the single element from the original junction
`junction` as the function `function`'s (only) argument.
Hopefully that makes sense, or hopefully the following example will.
Presume there is a single file in the current directory, `file.txt`. Thus:
say find: dir => '.', type => 'file', exclude => any rx/exe/ #
any("file.txt".IO)
You have provided more than one element for the `any` junction.
So `find` is called multiple times, once for each element of the `any`.
You have provided *two* elements in a junction used for the value
of one argument, namely `any( rx/<|w>mothera$/, rx/<|w>camel$/`.
Therefore `find` is called *twice*, once with each of the `rx`s, and
the result is an `any` containing the results from those two calls.
Hopefully the foregoing has made some sense, though you might
want to get up and go for a walk contemplating what it means for
something to be two things at once.
Assuming the foregoing has made sense, I'll drop in one other
wrinkle to consider. If you pass *multiple* arguments as junctions,
you have to take into account two aspects:
* Things multiply. If *two* function arguments are junctions, and
each junction has, say, three elements, the function is set to be
called *six* times.
* The combination has to follow precedence rules. I forget what
they are, but the general scheme is that there are two levels
and they do what's most natural. This will of course sound very
odd so I'll leave it as a thing to explore if you explore this. :)
--
love, raiph
On Fri, May 21, 2021 at 12:53 AM Joseph Brenner wrote:
>
> 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 (either strings or
> IO objects would be fine), that returns an any junction of IO
> objects, built-up from a peculiar set of hits.
>
> Does that make sense to anyone?
>
> Here's some code that demos the problem:
>
> use v6;
> use File::Find;
>
> ## create some files to find
> my $loc = "/tmp/monster_island";
> mkdir( $loc );
> chdir( $loc );
> my @monsters = < godzilla mothera rhodan >;
> for @monsters -> $name {
> $name.IO.spurt("The $name attacks!");
> }
>
> ## without exclude, we find all 3 files
> my @files_all = find( dir => $loc, type => 'file' );
> say @files_all.elems; # 3
>
> ## with a handcrafted regex we find only 2, skipping mothera as expected
> my @files_trimmed = find( dir => $loc, type => 'file', exclude =>
> rx/<|w>[mothera|camel]$/ );
> say @files_trimmed.elems; # 2
>
> ## Trying to do the same with an any junction doesn't work:
> my @exclude = ( rx/<|w>mothera$/, rx/<|w>camel$/ );
> my @files = find( dir => $loc, type => 'file', exclude => any(@exclude) );
> say @files;
> # [any(("/home/doom/tmp/monster_island/godzilla".IO
> "/home/doom/tmp/monster_island/rhodan".IO),
> ("/home/doom/tmp/monster_island/godzilla".IO
> "/home/doom/tmp/monster_island/mothera".IO
> "/home/doom/tmp/monster_island/rhodan".IO))]
> ##
> ## (1) we end up with a single "any" junction in the first element
> ## (2) there are five hits, two redundant rhodan and godzillas, plus
> one mothera slips through (?)
>
> ## but note that this works:
> for @monsters {
> .say unless $_ ~~ any(@exclude)
> }
> # godzilla
> # rhodan
>
>
>
> raku --version
> Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
> Implementing the 퐑퐚퐤퐮™ programming language v6.d.
> Built on MoarVM version 2020.10.
File::Find using a junction with exclude
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 (either strings or
IO objects would be fine), that returns an any junction of IO
objects, built-up from a peculiar set of hits.
Does that make sense to anyone?
Here's some code that demos the problem:
use v6;
use File::Find;
## create some files to find
my $loc = "/tmp/monster_island";
mkdir( $loc );
chdir( $loc );
my @monsters = < godzilla mothera rhodan >;
for @monsters -> $name {
$name.IO.spurt("The $name attacks!");
}
## without exclude, we find all 3 files
my @files_all = find( dir => $loc, type => 'file' );
say @files_all.elems; # 3
## with a handcrafted regex we find only 2, skipping mothera as expected
my @files_trimmed = find( dir => $loc, type => 'file', exclude =>
rx/<|w>[mothera|camel]$/ );
say @files_trimmed.elems; # 2
## Trying to do the same with an any junction doesn't work:
my @exclude = ( rx/<|w>mothera$/, rx/<|w>camel$/ );
my @files = find( dir => $loc, type => 'file', exclude => any(@exclude) );
say @files;
# [any(("/home/doom/tmp/monster_island/godzilla".IO
"/home/doom/tmp/monster_island/rhodan".IO),
("/home/doom/tmp/monster_island/godzilla".IO
"/home/doom/tmp/monster_island/mothera".IO
"/home/doom/tmp/monster_island/rhodan".IO))]
##
## (1) we end up with a single "any" junction in the first element
## (2) there are five hits, two redundant rhodan and godzillas, plus
one mothera slips through (?)
## but note that this works:
for @monsters {
.say unless $_ ~~ any(@exclude)
}
# godzilla
# rhodan
raku --version
Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
Implementing the 퐑퐚퐤퐮™ programming language v6.d.
Built on MoarVM version 2020.10.
