True, and I am well and truly baffled by my example where the 1st bad line
incorrectly is labelled good, the 2nd bad line is correctly labelled bad,
and the 3rd good like is correctly labelled good.
-y
On Sun, Jun 14, 2020 at 6:04 PM Joseph Brenner <doom...@gmail.com> wrote:
> > Just to be be clear, my idea is the second line is wrong, and it
> should flag that one as a problem....
>
> Oh, but if you go literally with the code I posted, *both* the first
> and second lines have incorrect descriptions, and only the third line
> ("corn dogs") matches.
>
> (That was a mistake when I wrote it up, but whatever.)
>
>
>
> On 6/14/20, Joseph Brenner <doom...@gmail.com> wrote:
> > Well, with the first one it rejects all of my lines, and with the
> > second one it passes all of them.
> >
> > Just to be be clear, my idea is the second line is wrong, and it
> > should flag that one as a problem....
> >
> >
> >
> > On 6/14/20, yary <not....@gmail.com> wrote:
> >> https://docs.raku.org/language/regexes#Regex_interpolation gave me some
> >> ideas
> >>
> >> Try matching against / (^P\d+) \s+ %products{$0} /
> >>
> >> This one also works, in a roundabout way
> >> / (^P\d+) \s+ {"%products{$0}"} /
> >> -y
> >>
> >>
> >> On Sun, Jun 14, 2020 at 4:44 PM Joseph Brenner <doom...@gmail.com>
> wrote:
> >>
> >>> In part because of the recent discussion here, I decided to
> >>> play around with using Raku code embedded in a regexp.
> >>> I came up with a contrived example where I was going to
> >>> examine a product listing in a text block to see if the product
> >>> descriptions matched the product codes. The valid associations
> >>> I have in a hash, so I'm (1) matching for product codes; (2)
> >>> using embedded code to look-up the associated description in the hash;
> >>> (3) using the returned description inside the regex.
> >>>
> >>> my %products = ( 'P123' => "Green Labels That Say Magenta",
> >>> 'P666' => 'Darkseid For President Bumpersticker',
> >>> 'P912' => "Corn dogs",
> >>> );
> >>>
> >>> my $text = q:to/END/;
> >>> P123 Viridian Green Label Saying Magenta
> >>> P666 Yoda puppets
> >>> P912 Corn dogs
> >>> END
> >>>
> >>> my @lines = $text.lines;
> >>> say @lines;
> >>>
> >>> for @lines -> $line {
> >>> say "checking line: $line";
> >>> ## This line works, but it's not a complete solution:
> >>> if $line ~~ / (^P\d+) \s+ <{ %products{$0}.subst(/\s+/, '\s', :g) }>
> >>> /
> >>> {
> >>> say "Matched, line looks good";
> >>> }
> >>> else {
> >>> say "NO: bad line.";
> >>> }
> >>> }
> >>>
> >>> I'd thought that a line like this would work:
> >>>
> >>> if $line ~~ / (^P\d+) \s+ <{ %products{$0} }> / {
> >>>
> >>> The trouble though is I've got spaces inside the descriptions,
> >>> so if the returned string is treated as a regexp, I get these
> >>> warnings:
> >>>
> >>> Potential difficulties:
> >>> Space is not significant here; please use quotes or :s
> >>> (:sigspace) modifier (or, to suppress this warning, omit the space, or
> >>> otherwise change the spacing)
> >>>
> >>> Reading a bit, I thought this should work
> >>>
> >>> if $line ~~ / (^P\d+) \s+ $( %products{$0} ) / {
> >>>
> >>> That's supposed to use the return string as a literal match.
> >>> Instead I get a lot of strange messages like:
> >>>
> >>> Use of Nil in string context in regex
> >>>
> >>> Flailing around I considered lots of variations like this:
> >>>
> >>> if $line ~~ / (^P\d+) \s+ Q[<{ %products{$0}}>] / {
> >>>
> >>> But I think that ends up treating everything inside the Q[]
> >>> literally, so you never do the hash lookup.
> >>>
> >>> Another thing that might solve this problem is some sort of
> >>> regexp quote function I could use inside the code before
> >>> returning the string, but I don't know what that would be...
> >>>
> >>
> >
>
