avuserow is there a good way to safely determine whether one path is a prefix of another? something like "/foo/bar".IO.is-parent-of("/foo/bar/baz/qux") # True 17:37
antononcube I am not sure "good" this is (it works though): sub is-prefix-path(Str $parent, Str $child) returns Bool { my $path = $parent.IO.absolute; return so $child.IO.absolute ~~ / ^ $path /; } 17:43
avuserow thanks 17:49
slight improvement to prevent "/t" from matching "/tmp": 17:50
m: sub is-prefix-path(Str $parent, Str $child) returns Bool { my $path = $parent.IO.absolute; return so $child.IO.absolute ~~ / ^ $path ["/" | $] /; }; say "/tmp/f".&is-prefix-path("/t"); say "/tmp/f".&is-prefix-path("/tmp")
camelia False
False
avuserow oops I put the params backwards 17:51
m: sub is-prefix-path(Str $parent, Str $child) returns Bool { my $path = $parent.IO.absolute; return so $child.IO.absolute ~~ / ^ $path ["/" | $] /; }; say "/t".&is-prefix-path("/tmp/foo"); say "/tmp".&is-prefix-path("/tmp/foo")
camelia False
True
msiism Is there a way to have loop variables be local to the loops inner scope? 17:54
antononcube There should a better solution that decomposes the paths into lists and compares the those lists for common first elements. Probably, the package "paths" can be used. 17:55
@msiism Hm... I am not sure what you mean. But I think you define them as copy. 17:56
msiism What I mean is, e.g. `$i` not being accessible after the loop in `loop (my $i = 0; $i < 10; ++$i) { say $i; }`. 17:58
The Raku docs say: "In case the initializer involves a variable declaration, the variable is declared as a lexical variable in the loop's outer or containing scope so that it can be used in code following the loop statement." 17:59
I mostly want the opposite, though.
ab5tract msiism: for ^10 -> $i { … } 18:01
There are very few reasons to use loop
The above expression scopes $I only to the block provides to for 18:02
antononcube @ab5tract and @msiism Yeah, my answer above was with for in mind not loop.
msiism Okay, I see. 18:05
ab5tract loop is about the only construct I know that does *not* take a pointy block 18:06
m: while ++$ < 10 andthen $_ -> $i { dd $i }
camelia Bool::True
Bool::True
Bool::True
Bool::True
Bool::True
Bool::True
Bool::True
Bool::True
Bool::True
ab5tract Forget the andthen
m: while ++$ < 10 -> $i { dd $i } 18:07
camelia Bool::True
Bool::True
Bool::True
Bool::True
Bool::True
Bool::True
Bool::True
Bool::True
Bool::True
msiism By the way, why is it that you cannot put parentheses around the "condition" of `for`? 18:08
ab5tract It’s not cannot, it’s no need to :) 18:10
msiism I do get an error from Raku, though, when I put them, like in `for (1..10 -> $n) { say $n; }`. 18:11
The error is: "Unexpected block in infix position" 18:12
nahita3882 syntax is for EXPR BLOCK, e.g., for 1..10 -> $n { ... } is parsed in 3 parts as "for", "1..10" and "-> $n { ...}" 18:26
so the parantheses you had there sabotage this template 18:27
it tries to parse (1..10 -> $n) as an expression, but it cannot, hence the error
msiism So, `1..10 -> $n` is not an expression, right? 18:30
Or is it rather that you can't just put parentheses around every Raku expression? 18:35
nahita3882 it's not an expression yes 18:45
you can put parantheses around every expression 18:46
it may or may not have an undesired effect, e.g., 3 * 5 + 2 != 3 * (5 + 2) kind of stuff 18:47
msiism Yeah, but that's basic maths, so I'd expect it to have that effect. 18:49
nahita3882 yeah 18:50
msiism But good to know I can have parentheses around every expression. I kind of like it that way for conditionals. 18:51
librasteve i think the general idea is that parens are only needed for disambiguation - raku does not need you to put them in just to satisfy some limiting syntax rules 18:53
ab5tract IME it is more readable to be able to say `if (a or b) || (a' or b') { ... }` than `if ((a or b) || (a' or b')) { ...}` 19:40
and then eventually it feels natural to see `if a'' or b'' { ... }` 19:41
msiism Yeah, it just felt a bit wobbly to have to parentheses to cling to, at first. 19:42
s/have to/have no/
librasteve yeah - I still cling to parens often - and often they make the code nicer for humans 19:43
(or not as ab5tract shows ^^) 19:44
if a or b and a' or b' { ... } <== as a human I really want ()s on this one ;-) 19:48
ab5tract definitely :) 19:57
I even wonder whether one of the primary intentions of removing the need for parens was: it makes using a number of parentheticals in a larger expression slightly less cumbersome while writing and quite a bit less cumbersome on the reading side 20:02
lizmat avuserow: perhaps raku.land/zef:lizmat/String::Utils#root could be of use ? 20:37
avuserow interesting, `root($parent, $child) eq $parent` seems pretty nice for this 22:56

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!