A regex doesn't have to match the entire string.
'abcd' ~~ / bc /
# ｢bc｣
A string has to match exactly with the smart-match. (`ff` and `fff` do
smart-match)
'abcd' ~~ 'bc' # False
'abcd' ~~ 'abcd' # True
A string inside of a regex only makes that a single atom, it does not make
it match like just a string.
'abcd' ~~ / 'bc' /
# ｢bc｣
'aBaBaB' ~~ / aB+ /
｢aB｣
'aBaBaB' ~~ / "aB"+ /
｢aBaBaB｣
In fact a string inside of a regex doesn't do much more than square
brackets.
'aBaBaB' ~~ / [aB]+ /
｢aBaBaB｣
If you want the regex to match fully, add a beginning of string and end of
string marker.
'abcd' ~~ / ^ bc $ /
# Nil
'abcd' ~~ / ^ abcd $ /
# ｢abcd｣
---
Since `ff` can begin and end at the same time, the following is turning on
and off at almost every iteration of the loop after it starts.
$ raku -ne '.put if /star {print q[on ]}/ ff /start {print q[off ]}/ ;'
startling.txt
on star
on off start
on off startl
on off startli
on off startlin
on off startling
On Tue, Jul 28, 2020 at 1:43 PM William Michels <w...@caa.columbia.edu>
wrote:
> Thank you, Brad and Larry, for explaining the "ff" and "fff" infix
> operators in Raku to me!
>
> I have to admit that I'm still fuzzy on the particulars between "ff"
> and "fff", since I am not familiar with the sed function. I can
> certainly understand how useful these functions could be to 'pull out
> all PGP signatures' from a file (which was the Perl5 example given in
> the Oracle Linux Blog). So I can now pull out the html "head" section
> from the page _ https://raku.org/fun/ _ (saved locally as file
> "fun.txt") using the following Raku code:
>
> user@mbook:~$ raku -ne '.put if Q[<head>] ff Q[</head>]' fun.txt
> <head>
> <meta charset="utf-8">
> <meta http-equiv="X-UA-Compatible" content="IE=edge">
> <meta name="viewport" content="width=device-width, initial-scale=1">
> <title>Raku is optimized for fun!</title>
>
>
> <link href="/favicon.ico" rel="shortcut icon" type="image/x-icon">
> <link href="/bootstrap/css/bootstrap.min.css" rel="stylesheet">
> <link href="/bootstrap/css/bootstrap-theme.min.css" rel="stylesheet">
> <link href="/style.css?v=1" rel="stylesheet">
>
> </head>
> user@mbook:~$
>
> What I'm less clear on is how the code below is functioning. I first
> print out file named "startling.txt" with 'cat': it's supposed to
> stand in for a text delimited linewise by "header 1", "header 2", etc.
> After the 'cat' example, I show three examples with Perl(v5.26.3) and
> three examples with Raku(2020.06), generally comparing literal vs
> regex arguments.
>
> The first two Perl5 examples returns nothing; the third Perl5 example
> returns everything after the "star" line. For the Raku code, the
> 'DWIMmiest' output below is the first Raku example, which returns two
> lines, "star" and "start". This is what I expected/desired. But I'm
> not really understanding what's happening with the other 2 Raku
> examples (which return everything after the "star" line):
>
> user@mbook:~$ cat startling.txt
> s
> st
> sta
> star
> start
> startl
> startli
> startlin
> startling
>
> user@mbook:~$ perl -nE 'print if "star" .. "start" ;' startling.txt
> user@mbook:~$ perl -nE 'print if /"star"/ .. /"start"/ ;' startling.txt
> user@mbook:~$ perl -nE 'print if /star/ .. /start/ ;' startling.txt
> star
> start
> startl
> startli
> startlin
> startling
> user@mbook:~$ raku -ne '.put if "star" ff "start" ;' startling.txt
> star
> start
> user@mbook:~$ raku -ne '.put if /"star"/ ff /"start"/ ;' startling.txt
> star
> start
> startl
> startli
> startlin
> startling
> user@mbook:~$ raku -ne '.put if /star/ ff /start/ ;' startling.txt
> star
> start
> startl
> startli
> startlin
> startling
> user@mbook:~$
>
> I'm all in favor of improving the "ff" and "fff" functions in Raku
> over their Perl5 counterparts, but I'm hoping to gain a better
> (mnemonic?) way of remembering the expected return values with literal
> vs regex arguments.
>
> Any assistance appreciated, Bill.
>
>
>
>
>
>
> On Sun, Jul 26, 2020 at 10:04 AM Larry Wall <la...@wall.org> wrote:
> >
> > On Sat, Jul 25, 2020 at 04:32:02PM -0500, Brad Gilbert wrote:
> > : In the above two cases ff and fff would behave identically.
> > :
> > : The difference shines when the beginning marker can look like the end
> > : marker.
> >
> > The way I think of it is this: You come to the end of "ff" sooner, so
> you
> > do the end test immediately after passing the start test. You come to
> the
> > end of "fff" later, so the end test is delayed to the next iteration from
> > the start test. (Same mnemonic for .. and ... in Perl, by the way, since
> > ff and fff were modeled on .. and ... (in their scalar form), but we
> stole
> > .. and ... in Raku for ranges and sequences so we needed something else.)
> >
> > I suppose if you're musical you can come up with mnemonics based on "fff"
> > being louder than "ff", so it echoes longer before it stops... :)
> >
> > Larry
>
