I meant that $_ is set to the left value while the right value is being evaluated, and also while .ACCEPTS is called.
LEFT ~~ RIGHT (Where LEFT and RIGHT represent some expression to be executed during runtime.) Imagine that underneath the hood, something like this is happening: my $L-value = LEFT.evaluate(); given $L-value { # $_ is temporarily the result of the LEFT expression my $R-value = RIGHT.evaluate(); return $R-value.ACCEPTS($L-value); } So this: « a b c ».join() ~~ S/b/y/ is functionally the same as: do given « a b c ».join() { my $R-value = S/b/y/; $R-value.ACCEPTS($_) } Note that $R-value will be "ayc" "ayc".ACCEPTS("abc") == False --- > $_.say (Any) > « a b c ».join() ~~ -> $a { say "\$a = $a\n\$_ = $_" } $a = abc $_ = abc > « a b c ».join() ~~ ($_.say, -> $a { say "\$a = $a\n\$_ = $_" }).tail abc $a = abc $_ = abc > $_.say (Any) On Mon, Dec 9, 2019 at 7:34 PM William Michels <w...@caa.columbia.edu> wrote: > Thank you Brad, for your in-depth reply. > > There are parts of your reply that make perfect sense to me, and also > parts where I am still confused. I feel I understand your first three > examples (1,2,3) explaining how the smartmatch operator relates to > ACCEPTS(). However in the second three examples explaining "S///" > (also numbered 1,2,3), I'm confused on Your Step 2. I've tried > numerous examples, a few of which are reproduced below: > > mbook:~ homedir$ perl6 > To exit type 'exit' or '^D' > 1> my $a = « a b c ».join() > abc > 2> say $a ~~ s/b/y/ > 「b」 > 3> say $a > ayc > 4> my $probe = "AGCT" > AGCT > 5 > say $/ if $probe ~~ /"TCGA"/ ; > () > 6> say $/ if $probe ~~ /"AGCT"/ ; > 「AGCT」 > 7> say $/ if $probe ~~ s/"AGCT"/"TCGA"/ ; > 「AGCT」 > 8> say $probe > "TCGA" > 9> say $/ if $probe ~~ S/"TCGA"/"AGCT"/ ; > Potential difficulties: > Smartmatch with S/// is not useful. You can use given instead: > S/// given $foo > ------> say $/ if $probe ~~ S/"TCGA"/"AGCT"/ ; > () > 10> say $probe > "TCGA" > 11> say $_ > abc > 12> $*VM > moar (2019.07.1) > > > > For "S///" in your Step 1 the LHS is evaluated first (your Join > example) and the LHS is temporarily set to $_. Then (your Step 2) the > RHS is evaluated. Do you mean the RHS is evaluated in the context of > $_ from the LHS?? Using your "abc" example I don't understand--if you > **solely** look at the "S/b/./" operation--how the letters "a" and > "c" show up in your Step 2 intermediate result. Of course, Raku/Perl6 > may be far cleverer than I imagined--clever enough based on position > and regex-rules (maybe) to simplify the two sides of the "S///" > operator into a simple formula that can then be applied to the LHS. > > So in pseudocode, are you saying the following regarding "s///" > (destructive-substitution) operation? > > 1. LHS: > eval( "probe" ) --> $_ ; > > 2. RHS regex "target" between first two solidi of s/// or S/// : > eval( "target".ACCEPTS( $_) ); > > 3. for s///, if above evaluates to TRUE match from above gets assigned > to $/ and LHS "probe" gets overwritten with appropriate "substitution" > characters between second two solidi of s/// or S/// : > ( "match" --> $/ ) ; ( RHS_"substitution" --> "probe" ) ; > > [ 4. for S///, there is no possibility that Step 2 will evaluate to > TRUE, so $/ is Nil and LHS "probe" remains as unchanged ]. > > If I'm close, please let me know. Meanwhile I will: 1) read over what > you wrote again, and 2) play around with a little more example code, > to gain a better understanding of what Raku/Perl6 is doing > under-the-hood. > > Best Regards, Bill. > > > > On Sun, Dec 8, 2019 at 12:42 PM Brad Gilbert <b2gi...@gmail.com> wrote: > > > > smartmatch is among the most complex parts of the language. > > > > That complexity has to managed or it will be too complex to use > effectively. > > > > To that end, the rules and order of operations are never altered. > > > > 1. The left side is evaluated first, and the resulting value captured > > > > > say('left') ~~ say('right') > > left > > right > > > > 2. $_ is temporarily set to that value, and the right side is executed > > > > > 'ab' ~ 'c' ~~ say($_) > > abc > > > > 3. The result of that execution is matched against the left value > > > > > 'abc' ~~ 'abb'.succ() > > True > > > > Specifically `.ACCEPTS` is called with the left value. > > So the following two lines are roughly equivalent. > > > > > 'abc' ~~ 'abb'.succ() > > > 'abb'.succ().ACCEPTS('abc') > > > > So in the case of S/// and ~~ this is the order that things happen: > > > > 1. The left side is executed > > > > « a b c ».join() ~~ S/b/./ > > > > 'abc' ~~ S/b/./ > > > > 2. $_ is temporarily set to that value, and the right side is executed > > > > 'abc' ~~ S/b/./ > > > > 'abc' ~~ 'a.c' > > > > 3. the result of the right side is matched against the left value > > > > 'abc' ~~ 'a.c' > > > > 'a.c'.ACCEPTS('abc') # False > > > > So basically if S/// changes the value, the result is False. > > If S/// doesn't change it, the result is True. > > > > Which means the following two lines are functionally identical. > > > > 'abc' ~~ S/b/./ > > 'abc' !~~ /b/ > > > > So the resulting value will never be the string you wanted! > > It will be True or False. > > > > --- > > > > The reason for the two stage execution is for the following. > > > > 'abc' ~~ .contains('b') > > 'abc' ~~ { .contains('b') } > > 'abc' ~~ m / b / > > 'abc' ~~ rx / b / > > > > Those four lines work basically the same, but for two different reasons. > > > > The first one works because $_ is set to the left value, and > True.ACCEPTS() always returns True > > > > The second one works because CODE.ACCEPTS() always runs the code with > the same parameter list. > > > > The third one works for the same reason as the first one > > > > The fourth one works for the same reason as the second one > > > > 1. Left side executed > > > > 'abc' ~~ .contains('b') > > 'abc' ~~ { .contains('b') } > > 'abc' ~~ m / b / > > 'abc' ~~ rx / b / > > > > 2. Right side executed > > > > 'abc' ~~ True > > 'abc' ~~ { .contains('b') } > > 'abc' ~~ True > > 'abc' ~~ rx / b / > > > > 3. R-VALUE .ACCEPTS( L-VALUE ) > > > > True.ACCEPTS('abc') > > { .contains('b') }.ACCEPTS('abc') > > True.ACCEPTS('abc') > > rx / b /.ACCEPTS('abc') > > > > Note again that CODE.ACCEPTS(VALUE) is the same as CODE.(VALUE). > > (Note also that a regex is a code object.) > > > > True.ACCEPTS('abc') > > { .contains('b') }.('abc') > > True.ACCEPTS('abc') > > rx / b /.('abc') > > > > --- > > > > So then why does this work? > > > > 'abc' ~~ { S/b/./ } > > > > As I said CODE.ACCEPTS() always runs CODE with the same parameter list. > > > > { S/b/./ } .ACCEPTS( 'abc' ) > > > > { S/b/./ } .( 'abc' ) > > > > --- > > > > So why does the warning tell you to use `given` instead of what I just > wrote? > > > > The ~~ is intended mostly for resolving some sort of truthiness. > > So I just misused the feature for something it was not intended for. > > > > `given` is intended for temporarily setting $_, so it is the appropriate > tool for the job. > > > > S/b/./ given 'abc' > > > > If you don't like `given`, then just use `.subst()` > > > > 'abc'.subst( 'b', '.' ) > > > > On Sun, Dec 8, 2019 at 1:32 AM William Michels <w...@caa.columbia.edu> > wrote: > >> > >> Apologies, looks like the smartmatch operator is listed in the > >> Operator Precedence table (15th row: under "Chaining infix"): > >> > >> https://docs.raku.org/language/operators#Assignment_operators > >> > >> However, am I correct in stating that the assignment operator ("=") is > >> on the 19th row ("Item assignment")? Therefore in the absence of > >> parentheses, etc., all smartmatch operations take precedence over > >> assignment operations? > >> > >> Best Regards, Bill. > >> > >> > >> On Sat, Dec 7, 2019 at 10:27 PM William Michels <w...@caa.columbia.edu> > wrote: > >> > > >> > Wow Brad, that's interesting and informative. > >> > > >> > I haven't seen the S/// operator before, so I had to look it up. On > >> > the first page I found the docs say (quite informatively): "S/// uses > >> > the same semantics as the s/// operator, except it leaves the original > >> > string intact and returns the resultant string instead of $/ ($/ still > >> > being set to the same values as with s///)." > >> > > >> > https://docs.raku.org/syntax/S$SOLIDUS$SOLIDUS$SOLIDUS > >> > > >> > I was then able to find an overview on regexes, which more explicitly > >> > names the "S///" operator as "Non-disruptive substitution". I suppose > >> > I could quibble and request that the phrase "Non-disruptive > >> > substitution" be added to the operator page (above), but no > >> > matter--it's easy enough to find: > >> > > >> > > https://docs.raku.org/language/regexes#S///_non-destructive_substitution > >> > > >> > So I think I understand that (as Brad has said): "smartmatch with S/// > >> > (or TR///) is not useful." Conversely, I've also found another > >> > smartmatch construct that is useless (i.e. disallowed): > >> > > >> > > my $r = 'abc' ~~ { S/b/./ } > >> > a.c > >> > > my $s = 'abc' ~~ { s/b/./ } > >> > Cannot modify an immutable Str (abc) > >> > in block <unit> at <unknown file> line 1 > >> > > > >> > > >> > No matter how "discouraged' a particular syntax is, people are going > >> > to run into these disallowed syntaxes and wonder why. Could it be due > >> > to precedence? These two prohibited operations beg the question: can a > >> > definitive statement be made regarding the precedence of the > >> > smartmatch operator relative to either lowercase-triple-solidus > >> > operators such as s/// and tr/// , or relative to > >> > uppercase-triple-solidus operators such as S/// and TR/// ? > >> > > >> > This really makes me wonder if anyone has plans to add "~~" (the > >> > smartmatch operator) to the precedence table that can be found > >> > below--and where in the table the smartmatch operator would precisely > >> > sit: > >> > > >> > https://docs.raku.org/language/operators#Operator_precedence > >> > > >> > Best Regards, Bill. > >> > > >> > > >> > > >> > > >> > On Sat, Dec 7, 2019 at 7:53 AM Brad Gilbert <b2gi...@gmail.com> > wrote: > >> > > > >> > > The return value of s/// is the same as $/ > >> > > > >> > > If you want the resulting string instead you can use S/// instead. > >> > > > >> > > > $_ = 'abc' > >> > > > my $r = S/b/./ > >> > > > say $r > >> > > a.c > >> > > > >> > > Note that it warns you try to use S/// with ~~ > >> > > > >> > > > my $r = 'abc' ~~ S/b/./ > >> > > Potential difficulties: > >> > > Smartmatch with S/// is not useful. You can use given > instead: S/// given $foo > >> > > ------> my $r = 'abc' ~~ S/b/./ > >> > > False > >> > > > >> > > Which gives you an indicator of how to fix it > >> > > > >> > > > my $r = S/b/./ given 'abc' > >> > > a.c > >> > > > >> > > Note that the `given` happens before the `=` > >> > > > >> > > So it works the same as > >> > > > >> > > > my $r = ( S/b/./ given 'abc' ) > >> > > a.c > >> > > > >> > > --- > >> > > > >> > > The reason ~~ doesn't work with S/// has to do with the dual pass > nature of ~~. > >> > > > >> > > Without getting into details, you can avoid that by delaying the > S/// until the second pass. > >> > > > >> > > > my $r = 'abc' ~~ { S/b/./ } > >> > > a.c > >> > > > >> > > Or you can just set $_ to the value. > >> > > (Which is basically what the previous line is doing.) > >> > > > >> > > > my $r = S/b/./ given 'abc' > >> > > > >> > > > given 'abc' { > >> > > > my $r = S/b/./ > >> > > > … > >> > > > } > >> > > > >> > > > my $_ = 'abc' > >> > > > my $r = S/b/./ > >> > > > >> > > > my $r = 'abc' ~~ -> $_ { S/b/./ } > >> > > > >> > > > my $r = 'abc' ~~ sub ( $_ ) { S/b/./ } > >> > > > >> > > > my $r = 'abc' ~~ anon sub foo ( $_ ) { S/b/./ } > >> > > --- > >> > > > >> > > One of design goals of Raku is to have as few special cases as > possible. > >> > > Which is why ~~ and S/// haven't been made to just work. > >> > > > >> > > (It could be argued that in this case an exception could be made. > But I'm not going to argue for it.) > >> > > > >> > > On Fri, Dec 6, 2019 at 10:37 PM William Michels via perl6-users < > perl6-us...@perl.org> wrote: > >> > >> > >> > >> Hello All, > >> > >> > >> > >> Todd put up some interesting code yesterday using the Raku/Perl6 > REPL, > >> > >> which I reproduced with no problem. Additionally I tried some > >> > >> variations removing and/or moving parentheses to a different > location, > >> > >> and have numbered the relevant REPL lines 1 through 6: > >> > >> > >> > >> mbook:~ homedir$ perl6 > >> > >> To exit type 'exit' or '^D' > >> > >> 1> my $x = Q[word</b><br>] ; > >> > >> word</b><br> > >> > >> 2> (my $y = $x) ~~ s/ '<' .* //; say $/; say $x; say $y; > >> > >> 「</b><br>」 > >> > >> word</b><br> > >> > >> word > >> > >> 3> my $a = Q[word</b><br>] ; > >> > >> word</b><br> > >> > >> 4> my $b = ($a ~~ s/ '<' .* //); say $/; say $a; say $b; > >> > >> 「</b><br>」 > >> > >> word > >> > >> 「</b><br>」 > >> > >> > my $c = Q[word</b><br>] ; > >> > >> word</b><br> > >> > >> > my $d = $c ~~ s/ '<' .* //; say $/; say $c; say $d; > >> > >> 「</b><br>」 > >> > >> word > >> > >> 「</b><br>」 > >> > >> 7> $*VM > >> > >> moar (2019.07.1) > >> > >> > >> > >> Working in groups of 2, lines 1 and 2 replicate the code Todd put > up > >> > >> (parenthesis surrounding everything to the left of the smartmatch > >> > >> operator). I get the same result as Todd. What interests me are > lines > >> > >> 3 through 6. Lines 3 and 4 are the virtually the same code but with > >> > >> parentheses surrounding everything to the right hand side (RHS) of > the > >> > >> assignment operator (" = "). As people will note, lines 2 and > lines 4 > >> > >> give different results. Removing parentheses entirely in line 6 > gives > >> > >> the same result as in line 4. Because the results in line 4 and > line 6 > >> > >> are the same, this says that as far as parentheses are concerned, > the > >> > >> smartmatch operator "~~" takes precedence over the assignment > operator > >> > >> "=". > >> > >> > >> > >> What's not clear to me in the code above (lines 4 and 6) is why > >> > >> variables $b and $d get assigned to $/. I would have expected in > line > >> > >> 4 that $a would have been matched against the smartmatch, and the > >> > >> result ("word") would have been simply copied into variable $b. > Have I > >> > >> misunderstood? > >> > >> > >> > >> Anyway, I'm just hoping to start a conversation on the topic of > >> > >> precedence in general, and hopefully getting some feedback as to > where > >> > >> to look in the docs for further instruction. > >> > >> > >> > >> Best Regards, Bill. > >> > >> > >> > >> > >> > >> On Fri, Dec 6, 2019 at 12:15 AM ToddAndMargo via perl6-users > >> > >> <perl6-us...@perl.org> wrote: > >> > >> > > >> > >> > On 2019-12-05 23:19, ToddAndMargo via perl6-users wrote: > >> > >> > > On 2019-12-05 03:09, William Michels via perl6-users wrote: > >> > >> > >> What happens when you type "perl6" or "raku" at the bash > command prompt? > >> > >> > > > >> > >> > > Hi William, > >> > >> > > > >> > >> > > On my shop machine, it jumps to the next line with an > >> > >> > > empty flashing cursor > >> > >> > > > >> > >> > > On my office machine, it told me to install > >> > >> > > zef install Readline > >> > >> > > > >> > >> > > After that, I get: > >> > >> > > > >> > >> > > $ perl6 > >> > >> > > To exit type 'exit' or '^D' > >> > >> > > > > >> > >> > > > >> > >> > > and > >> > >> > > > >> > >> > > > say "hello World" > >> > >> > > hello World > >> > >> > > > say "B" ~ Q[:\] ~ " drive dismounted" > >> > >> > > B:\ drive dismounted > >> > >> > > > > >> > >> > > > >> > >> > > and sticking an obvious booboo into it > >> > >> > > > >> > >> > > > if 3 % 2 = 1 {say "odd"}; > >> > >> > > Cannot modify an immutable Int (1) > >> > >> > > in block <unit> at <unknown file> line 1 > >> > >> > > > >> > >> > > Plus I can use the arrow keys to recall previous lines too. > >> > >> > > > >> > >> > > Time up update my Perl6 on my shop computer! > >> > >> > > > >> > >> > > No more hassling with `perl6 -e` !!! > >> > >> > > > >> > >> > > Dude! THANK YOU !!!!!! > >> > >> > > > >> > >> > > -T > >> > >> > > >> > >> > You've created a monster!! > >> > >> > > >> > >> > perl6 > >> > >> > To exit type 'exit' or '^D' > >> > >> > > my $x = Q[</b><br>] > >> > >> > </b><br> > >> > >> > > say $x > >> > >> > </b><br> > >> > >> > > (my $y = $x ) ~~ s/ Q[<] .* //; > >> > >> > ===SORRY!=== Error while compiling: > >> > >> > Unrecognized regex metacharacter < (must be quoted to match > literally) > >> > >> > ------> (my $y = $x ) ~~ s/ Q[<] .* //; > >> > >> > > my $x = Q[abc</b><br>] > >> > >> > abc</b><br> > >> > >> > > (my $y = $x ) ~~ s/ '<' .* //; > >> > >> > 「</b><br>」 > >> > >> > > (my $y = $x ) ~~ s/ '<' .* //; say $y > >> > >> > abc > >> > >> > > (my $y = $x ) ~~ s/ '<' .* //; say $x; say $y > >> > >> > abc</b><br> > >> > >> > abc > >> > >> > > >> > >> > > >> > >> > Thank you! > >> > >> > > >> > >> > > >> > >> > -- > >> > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> > >> > Computers are like air conditioners. > >> > >> > They malfunction when you open windows > >> > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >