klebs | ah, gotcha -- thanks for these links | 00:01 | |
thanks for these links -- will take a look | |||
i have another grammar related question which is about proto rules: | 00:03 | ||
i have something like this: ```raku | 00:05 | ||
proto rule expr { * } | |||
rule expr:sym<lit> { <lit> } | |||
rule expr:sym<self> { <SELF> } | |||
rule expr:sym<path-expr> { | |||
<path-expr> | |||
} | |||
rule expr:sym<macro-expr> { <macro-expr> } | |||
rule expr:sym<struct-expr> { <path-expr> '{' <struct-expr-fields> '}' } | |||
rule expr:sym<expr-q> { <expr> '?' } | |||
rule expr:sym<dotted-expr> { <expr> '.' <path-generic-args-with-colons> } | |||
rule expr:sym<dotted-expr-lit> { <expr> '.' <LIT-INTEGER> } | |||
rule expr:sym<expr-eq-expr> { <expr> '=' <expr> } | |||
``` | |||
when I trace the parse, i get: | 00:07 | ||
```raku | |||
#!/usr/bin/env raku | |||
use my-grammar; | |||
my $in = $*IN.slurp.chomp; | |||
my $parsed = MyGrammar.parse($in, rule => "expr"); | |||
say $parsed; | |||
``` | |||
just with something like that^, where input is `self.phase = 1.0` | |||
it basically grabs the expr:sym<self> rule instead of <expr-eq-expr> | 00:08 | ||
my understanding was that this :sym syntax was LTM | 00:09 | ||
what am i missing? i can get it to parse correctly under some circumstances if i change the order of the proto rules | |||
this grammar was generated by parsing a yacc file, so i think there may be some other problems with it... | 00:12 | ||
like for instance i think i may hit some infinite loops | 00:13 | ||
but i still don't expect the parse to short circuit -- i think i am missing some detail but am not quite sure what it is | 00:15 | ||
when i change everything from rule --> regex, it hits one of those infinite loops at dotted-expr | 00:16 | ||
so i think i need to rework the structure somehow so that no rule loops into <expr> | |||
ah, fixing the loops seems to have solved it -- no worries! problem solved i think! | 00:29 | ||
00:40
Manifest0 left
|
|||
guifa | klebs: be aware that all caps names identifiers should be considered reserved | 00:41 | |
for methods, they are explicitly reserved, and for everything else they're recommended to be used for "builtints" (which I read as core/modules, which means the more end-usery-space you're in, the more you should avoid them) | 00:43 | ||
01:46
frost joined
|
|||
klebs | thanks, will fix | 03:28 | |
usually dont write them all caps but this grammar is generated from a yacc file | |||
still fixing it up | |||
im hitting another weird case | |||
i have a rule called token-tree as well as a rule called token-trees | 03:30 | ||
token-trees is just `<token-tree>*` | |||
i am hitting a case where token-tree matches, but token-trees does not | |||
scratching my head trying to figure out why | |||
trying to figure out why | |||
or rather, it hangs | 03:32 | ||
i also tried with a `+`, as well as `<token-tree>* %% <.ws>` | 03:34 | ||
also `<token-tree>+ %% <.ws>` | |||
all hang | |||
but `rule token-trees { <token-tree> <token-tree> }` matches when i duplicate the input | 03:55 | ||
quite odd | |||
i think it might be similar to the problem before -- i found another way to drill down | 04:07 | ||
got it | 04:18 | ||
it was the same kind of thing | 04:19 | ||
07:43
frost left
08:27
Manifest0 joined
09:12
dakkar joined
09:13
frost joined
10:32
frost left
11:07
razetime joined
13:22
razetime left
13:23
razetime joined
13:47
frost joined
14:33
jgaz joined
14:49
jgaz left
14:52
jgaz joined
15:00
jgaz left
16:09
razetime left
17:34
dakkar left
18:26
discord-raku-bot left,
discord-raku-bot joined
18:30
discord-raku-bot left
18:31
discord-raku-bot joined
|
|||
today i have another kind of infinite loop in this grammar, where a block-expr can be a match-expr, where `rule match-expr { 'MATCH' <expr-nostruct> '{' <match-expr-body '} }` and expr-nostruct can be a block-expr. this creates a cycle and thus an infinite loop. are there any known strategies for solving this type of problem? | 20:18 | ||
today i found another infinite loop in this grammar: | |||
a block-expr can be a match-expr, where `rule match-expr { 'MATCH' <expr-nostruct> '{' <match-expr-body '} }` and expr-nostruct can be a block-expr. this creates a cycle and thus an infinite loop. are there any known strategies for solving this type of problem? | |||
today i found another infinite loop in this grammar: | 20:20 | ||
a block-expr can be a match-expr, where `rule match-expr { 'MATCH' <expr-nostruct> '{' <match-expr-body '}' }` and expr-nostruct can be a block-expr. this creates a cycle and thus an infinite loop. are there any known strategies for solving this type of problem? | |||
oh wait | |||
wow | |||
this is the exact same problem as before | |||
🙂 | |||
because it is <MATCH> instead of what i wrote: 'MATCH' | 20:22 | ||
i am thankful you folks are all so helpful and patient 🙂 | |||
it is helpful for me | |||
i need to take care of the all caps rules everywhere asap | |||
i need to take care of the all caps rules everywhere asap it seems | 20:24 | ||
i need to take care of the all caps rules everywhere asap | |||
MasterDuke | Â it's not just caps though. things like e.g., 'identifier', 'token', 'digits', are all *potentially* problematic (i don't remember which ones exactly are, maybe even none in that list) | 20:25 | |
klebs | roger that | 20:26 | |
i think it is possible that in this case some of those (or similar) might trigger | 20:27 | ||
i'll eventually probably update the generator (that went from yacc to raku) to lowercase rule names and avoid keywords | 20:28 | ||
it would have been much easier had i done it that way originally 🙂 but i didnt fully realize what would happen | 20:30 | ||
it is a good thing i have raku to solve this problem! | |||
MasterDuke | i've wanted to add a warning if you use a 'core' name, but haven't gotten around to it, partly because i don't have a good sense of exactly when it *is* a problem | 20:31 | |
klebs | understood -- are you working on raku itself? i hope some of my grammar adventures have at least been helpful to observe in action 🤣 | 20:34 | |
is it a problem to use one of these 'core' names in a sym rule? something like `rule something:sym<continue> { ... }` | 20:35 | ||
MasterDuke | i flail at the keyboard and sometimes it ends up in PRs for rakudo/nqp/moarvm | 20:36 | |
klebs | (continue could also be something like: rule, token, last, next, sub, if, etc) | ||
is it a problem to name these like that? | |||
MasterDuke | i'm not sure. i was trying to think of a good way to search rakudo issues and/or irc logs for prior times people have run into this, but also haven't come up with any good search terms... | 20:37 | |
klebs | yeah it can be tricky to find solutions to these sorts of issues because the terms involved all overlap with other usages (which is one reason i usually ask *here* for this kind of stuff instead of google) | 20:39 | |
it is okay i suppose, i like talking to you folks anyways! other raku people! | 20:45 | ||
```raku | 20:47 | ||
#!/usr/bin/env raku | |||
use global-subparse; | |||
my $bad-rules = SetHash.new; | |||
grammar AllCapsRule does GlobalSubparse { | |||
20:47
discord-raku-bot left,
discord-raku-bot joined
|
|||
i can filter my files through this script to fix the caps issue, just posting it here in case it is useful to anybody else | 20:49 | ||
MasterDuke | it didn't make it to irc (bot got disconnect due to excess flood), probably best to put it in a gist somewhere and paste the link | 20:50 | |
klebs | good idea | 21:05 | |
jaguart thanks @CIAvash @MasterDuke @guifa - thanks for the POD6 pointers, will follow-up. | 22:29 | ||
gfldex | PWC 154-2 is a nice one. Well worth the head scratching. theweeklychallenge.org/blog/perl-w...lenge-154/ | 22:54 |