Newest at the top
| 2025-10-04 22:58:09 +0200 | <monochrom> | (In the case of PEG, completely banned. In the case of *parsec, backtracking is opt-in, non-default.) |
| 2025-10-04 22:57:57 +0200 | [exa] | dives |
| 2025-10-04 22:57:50 +0200 | <[exa]> | kinda wondering how they implement the lookaheads |
| 2025-10-04 22:57:27 +0200 | <monochrom> | parsec and megaparsec are actually pretty good for PEG. Although independently conceived, both minimized backtracking, that's why. |
| 2025-10-04 22:56:12 +0200 | <[exa]> | (the packrat/pika parser family) |
| 2025-10-04 22:55:59 +0200 | <[exa]> | bwe: yeah for regex the lookaheads are detrimental because they destroy the usual (fast) DFA/NFA-style processing. For general PEGs the lookaheads are the determining property that you can do quite easily that is not really allowed in actual context-free grammars. There are pretty fast PEG parsers where lookaheads are "essentially free" |
| 2025-10-04 22:55:28 +0200 | <EvanR> | first law of parallel programming, if you just do the task N times in parallel it probably hurts |
| 2025-10-04 22:55:02 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-10-04 22:54:49 +0200 | <monochrom> | E.g., remember last time telling cabal-install to do unlimited parallel builds caused a lot of trouble (in the form of thrashing)? |
| 2025-10-04 22:53:59 +0200 | <[exa]> | monochrom: well that use is a programming issue, they lookahead and then have to move manually :] |
| 2025-10-04 22:53:52 +0200 | <monochrom> | Deeply recursive CFG may overwhelm your computer if you parallelize it :) |
| 2025-10-04 22:53:50 +0200 | Everything | (~Everythin@172.232.54.192) (Quit: leaving) |
| 2025-10-04 22:53:48 +0200 | <EvanR> | actual regular expression based parsers can be very fast |
| 2025-10-04 22:53:39 +0200 | tremon | (~tremon@83.80.159.219) tremon |
| 2025-10-04 22:52:51 +0200 | <monochrom> | (Sapir-Worf applies here. 1970s languages forces boolean blindness on you. I reckon that it is unfair to blame beginners.) |
| 2025-10-04 22:52:41 +0200 | <EvanR> | it seems like context free grammar could benefit from parallel |
| 2025-10-04 22:52:38 +0200 | <bwe> | [exa]: I've learned about them at a time I learned regular expressions. And I learned to avoid them (do I remember correctly that they were mostly bad for performance?). So, being burnt like that, I feel hesitant to use them in parser combinators (a reason / alternative for me not to use regexes). |
| 2025-10-04 22:51:52 +0200 | <EvanR> | this sort of parsing is well defined but can't be parallelized |
| 2025-10-04 22:50:22 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-04 22:49:39 +0200 | <monochrom> | (And they would write like that in C because boolean blindness.) |
| 2025-10-04 22:49:14 +0200 | <monochrom> | But no, beginners want to write "c <- lookahead; if c == 'X' then foo else if c == 'Y' then bar else error" because that's what they would write in C. |
| 2025-10-04 22:49:05 +0200 | <bwe> | monochrom: actually, parser combinators are like a tree that is branching, thanks for inspiring this. |
| 2025-10-04 22:48:28 +0200 | <monochrom> | You can easily code that up as simply "foo <|> bar" assuming that foo expects X at the beginning, similarly for Y. |
| 2025-10-04 22:47:59 +0200 | <monochrom> | Suppose your requirement is "there are 2 cases for the next character. If it's X, parse for foo; if it's Y, parse for bar". |
| 2025-10-04 22:47:32 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-10-04 22:46:40 +0200 | <monochrom> | I feel that most beginner uses of lookahead are boolean blindness brought to parsing. |
| 2025-10-04 22:46:37 +0200 | takuan | (~takuan@d8D86B9E9.access.telenet.be) (Remote host closed the connection) |
| 2025-10-04 22:46:09 +0200 | <bwe> | zfnmxt: I have the feeling that composing parsers is just the nesting use case I have on hand :) -- but will see when I walk through the article. Thanks again for sharing. |
| 2025-10-04 22:45:27 +0200 | dfg | (~dfg@user/dfg) dfg |
| 2025-10-04 22:44:46 +0200 | sprout | 🍿 |
| 2025-10-04 22:44:43 +0200 | <[exa]> | (except for the cool new regular expressions that are actually not regular) |
| 2025-10-04 22:44:29 +0200 | <[exa]> | wait wait how's lookahead looking like regular expressions? |
| 2025-10-04 22:44:00 +0200 | dfg | (~dfg@user/dfg) (Quit: I hate quit messages.) |
| 2025-10-04 22:43:58 +0200 | <bwe> | [exa]: Yes, this would fit my case, too. Reminds me of regular expressions. But weren't parser combinators better for leaving regular expressions? |
| 2025-10-04 22:43:28 +0200 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-10-04 22:41:15 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
| 2025-10-04 22:38:56 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-10-04 22:38:37 +0200 | <[exa]> | bwe: if I get it right, you might like the `notFollowedBy` from parsecs for solving this case; since this is PEGs getting parsed you can use the lookahead pretty well for doing good. |
| 2025-10-04 22:35:05 +0200 | <[exa]> | evenin' |
| 2025-10-04 22:32:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-04 22:29:30 +0200 | <zfnmxt> | bwe: Have fun! |
| 2025-10-04 22:26:03 +0200 | <bwe> | zfnmxt: Exciting. I will start with that. It's indeed much more gentle and easier to digest/follow. Less frustration points to be expected. |
| 2025-10-04 22:23:28 +0200 | <tomsmeding> | "your" as in, the good stuff that you know :p |
| 2025-10-04 22:22:48 +0200 | <zfnmxt> | tomsmeding: Most of that good stuff is written by Troels, not me. But will do. |
| 2025-10-04 22:22:08 +0200 | <zfnmxt> | bwe: Don't think the repo is directly linked there, but it's here: https://github.com/diku-dk/ap-e2025-pub (see week 3 and a3 in particular) |
| 2025-10-04 22:21:30 +0200 | <tomsmeding> | zfnmxt: thank you, please hang around more and share all your good stuffs |
| 2025-10-04 22:21:10 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-10-04 22:20:28 +0200 | <zfnmxt> | bwe: You mind find these notes a bit gentler and easier to understand (there are corresponding exercises and an assignment on the repo too): https://diku-dk.github.io/ap-notes/chapter_3.html |
| 2025-10-04 22:19:59 +0200 | <bwe> | I need to give it another try -- the last time I tried it didn't work too well for me |
| 2025-10-04 22:18:45 +0200 | <bwe> | the thing I am not grasping is the nesting, so using some parser combinators once I am in the parenthesis, for example |