This channel is intended for people just starting with the Raku Programming Language (raku.org). Logs are available at irclogs.raku.org/raku-beginner/live.html Set by lizmat on 8 June 2022. |
|||
01:47
MasterDuke joined
06:25
kjp left
06:26
kjp joined
06:27
kjp left
06:28
kjp joined
|
|||
nahita3882 | hi, sorry for the late response. You are right!: m/.../; automatically matches against $_; m { ... } is actually the same as m/.../ only using a different separator for regex: {} pairs instead of || -- this is for convenience, e.g., if your regex to contain a lot of forward slashes, you would need to escape it to not confuse with the ending delimeter (or you must quote it). | 08:58 | |
rx { ... } on the other hand performs no match but makes a Regex object | |||
a12l | @nahita3882 Thanks! | 09:03 | |
I want to write a regex that match against any character that isn't A, C, G, or T. My current attempt is / <-[A | C | G | T]> /, but doesn't work. It does work if I only specify two letters. | 09:06 | ||
09:07
jaguart joined
|
|||
kjp | a12l: / <-[ACGT]> / works for me | 09:20 | |
nahita3882 | yeah the | is treated literally in there (in the character class), not as an "or" switch | 09:35 | |
jaguart | what does this signature mean? ``multi MAIN(:h(:$help)!)`` | 11:32 | |
lizmat | m: sub a(:h(:$help) { dd $help ); a :h; a :help | 11:58 | |
camelia | ===SORRY!=== Error while compiling <tmp> Missing block at <tmp>:1 ------> sub a(:h(:$help) ⏏{ dd $help ); a :h; a :help |
||
lizmat | m: sub a(:h(:$help) { dd $help }; a :h; a :help | ||
camelia | ===SORRY!=== Error while compiling <tmp> Missing block at <tmp>:1 ------> sub a(:h(:$help) ⏏{ dd $help }; a :h; a :help |
||
lizmat | m: sub a(:h(:$help)) { dd $help }; a :h; a :help | ||
camelia | Bool::True Bool::True |
||
lizmat | heh | ||
basically, it allows both --h and --help | 11:59 | ||
if such a signature is used on MAIN | |||
nahita3882 | docs.raku.org/language/signatures#...nt_aliases | 12:05 | |
to link the documentation | 12:06 | ||
12:32
habere-et-disper joined
|
|||
a12l | kjp, @nahita3882: Thought that the pattern would match against the first substring "ACGT" | 13:20 | |
If I would like to match against the substring ACGT, should I have quoted the letters? | 13:29 | ||
Or even against several different substrings? E.g. "abc", "def", "ghi"? How do I OR them? | 13:32 | ||
nahita3882 | <[ACGT]> actually forms a character class -- it means "match any of the characters I put in there" | 13:38 | |
<-[ACGT]> is the negation of that (fun fact: we can actually do <+[ACGT]> but + is redundant) | 13:39 | ||
> If I would like to match against the substring ACGT, should I have quoted the letters? yeah you need to write it without the <[...]> stuff. Since neither of those characters are special, you can write it directly, but writing it in quotes will do the same thing | 13:40 | ||
and for consistency, i think it's better to do in quotes and never think about special characters' escaping | 13:41 | ||
> Or even against several different substrings? E.g. "abc", "def", "ghi"? How do I OR them? ORing is with || | |||
examples: | |||
raku # With a character class -- any of the characters A, C, G, T In [1]: "A" ~~ / <[ACGT]> / 「A」 # Match literally the four-char sequence ACGT In [2]: "A" ~~ / ACGT / Nil # Same as above, quoting not necessary since no special characters (like "-") but safe, consistent In [3]: "A" ~~ / "ACGT" / Nil # Character class again -- only A part is matched In [4]: "ACGT was here" ~~ / <[ACGT]> / 「A」 # | 13:47 | ||
Literal -- full sequence is matched In [5]: "ACGT was here" ~~ / ACGT / 「ACGT」 # Same as above but in quotes (safer, cooler) In [6]: "ACGT was here" ~~ / "ACGT" / 「ACGT」 # Matching against alternatives: either literally ACGT *or* TTGA In [7]: "TTGA was here" ~~ / "ACGT" || "TTGA" / 「TTGA」 | |||
as a "corollary", / <[ACGT]> / is the same as / A || C || G || T / or with quotes / 'A' || 'C' || 'G' || 'T' / if that makes sense | 13:49 | ||
a12l | Thanks for the examples @nahita3882 ! | 14:07 | |
Btw, when is it necessary to group the characters in a subexpression? | 14:08 | ||
nahita3882 | hmm, not sure I understood but for precedence, we might want to use grouping like: perl > "text-end" ~~ / "text" || "no" "-end" / 「text」 > "text-end" ~~ / ["text" || "no"] "-end" / 「text-end」 | 14:13 | |
in the first one, alternatives are "text" OR "no-end", and so it matches "text" | |||
but what's wanted is "text-end" OR "no-end"; of course we can write "text-end" || "no-end", but to "factor out" and not repeat -end again, we made the first attempt | 14:14 | ||
but the precedence kicked in and didn't reach the desired result; for that, we use non-capturing grouper [ ] and it's all set | 14:15 | ||
in the second one, it's "either "text" OR "no", followed by "-end"" | |||
14:19
habere-et-disper left
|
|||
a12l | I'm thinking of why raku > "abcd" ~~ / <[abc]> / 「a」 > "abcd" ~~ / <abc> / No such method 'abc' for invocant of type 'Match'. Did you mean 'abs'? in block <unit> at <unknown file> line 1 in any <main> at /nix/store/g1bz1z20yh9n8dg7913r68grnkgg3584-rakudo-2024.01/share/perl6/runtime/perl6.moarvm line 1 in any <entry> at | 17:33 | |
/nix/store/g1bz1z20yh9n8dg7913r68grnkgg3584-rakudo-2024.01/share/perl6/runtime/perl6.moarvm line 1 | |||
I'm thinking of why raku > "abcd" ~~ / <[abc]> / 「a」 > "abcd" ~~ / <abc> / No such method 'abc' for invocant of type 'Match'. Did you mean 'abs'? in block <unit> at <unknown file> line 1 in any <main> at /nix/store/g1bz1z20yh9n8dg7913r68grnkgg3584-rakudo-2024.01/share/perl6/runtime/perl6.moarvm line 1 in any <entry> at | 17:34 | ||
/nix/store/g1bz1z20yh9n8dg7913r68grnkgg3584-rakudo-2024.01/share/perl6/runtime/perl6.moarvm line 1 | |||
What I understand, grouping is only necessary you want to group characters in another order than is specified by the default precedence rules. | 17:35 | ||
My (obvious wrong) understanding is that abc is the same as [abc] when enclosed in angle brackets. But that mental model is obviously wrong. What have I misunderstood? | 17:36 | ||
librasteve | m: say "abcd" ~~ / abc / | 17:44 | |
Raku eval | 「abc」 | ||
librasteve | @a12l - no need for angle brackets unless you are using a regex (aka sub-expression), doing interpolation or (with <[...]> angle-square combo) need a char class | 17:46 | |
<abc> is neither a predefined regex (aka a predefined char class like <alpha>) nor is it one you defined like my regex abc { \w } | 17:48 | ||
/ abc / will match a then b then c, / <[abc]>{3} / will match a or b or c 3 times | 17:50 | ||
a12l | What I'm wondering is why grouping a regex inside angle brackets automatically create a char class | 18:01 | |
librasteve | it doesn't - there is just some syntax for regex <...> and some other syntax for char classes <[...]> - they just look similar | 18:02 | |
a12l | Wait, so < ... > (named subexpression), [ ... ] (grouping), and <[ ... ]> (create a char class) are totally different things? | 18:09 | |
librasteve | yep | 18:10 | |
a12l | And do I understand char classes correctly that they are "anonymous subexpressions", compared to named sub expressions (my regex foo { ... })? | 18:12 | |
librasteve | I ... don't think so ... feels like you are over analysing this | 18:13 | |
a12l | I'm just trying to figure out the relation between the different constructs. | 18:15 | |
librasteve | they just look a bit similar - otherwise there is no relation | ||
a12l | There so much syntactic overlap in Raku, but the docs don't (I think) make they difference clear when they talking about different stuff. | 18:16 | |
librasteve | well, by definition, there is no syntactic overlap (since the syntax leads to determined results), but I agree that raku is very syntactically dense - it is surely not python | 18:19 | |
a12l | Thanks your patience @librasteve ! | 18:21 | |
librasteve | you are looking at regex also which, with the need to have character level syntax that maps closely to the char patterns in the input string, is very syntactically dense, raku is less extreme in other areas (eg OO, concurrency, file IO and so on) | ||
np | |||
I learn (or relearn) aspects of raku every time I try to answer a question! | 18:22 |