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-us...@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-us...@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-us...@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-us...@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 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? 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).
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.