Newest at the top
| 2025-10-05 00:38:55 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-10-05 00:35:35 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-10-05 00:34:44 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-05 00:33:25 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-10-05 00:29:20 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-10-05 00:25:05 +0200 | tromp | (~textual@2001:1c00:3487:1b00:79b7:f1d9:214a:8b71) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-10-05 00:22:49 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-05 00:12:10 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-10-05 00:08:46 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-10-05 00:07:22 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-04 23:57:01 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-10-04 23:56:22 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-10-04 23:55:54 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2025-10-04 23:51:58 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-04 23:49:05 +0200 | tromp | (~textual@2001:1c00:3487:1b00:79b7:f1d9:214a:8b71) |
| 2025-10-04 23:42:37 +0200 | desuua_ | (~desuua@user/desuua) (Quit: Leaving) |
| 2025-10-04 23:41:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2025-10-04 23:36:35 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-04 23:36:00 +0200 | tromp | (~textual@2001:1c00:3487:1b00:79b7:f1d9:214a:8b71) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-10-04 23:25:49 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-10-04 23:21:37 +0200 | Square | (~Square@user/square) (Ping timeout: 264 seconds) |
| 2025-10-04 23:21:13 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-04 23:18:49 +0200 | <monochrom> | haha |
| 2025-10-04 23:18:40 +0200 | <[exa]> | I'm bookmarking that comic for lisp reasons |
| 2025-10-04 23:17:40 +0200 | <monochrom> | Yeah *parsec will do fine. |
| 2025-10-04 23:15:39 +0200 | <[exa]> | anyway yeah the lookahead here is very bounded |
| 2025-10-04 23:15:19 +0200 | <[exa]> | yeah but do you want to compile LL(k) manually to the state tables? :D |
| 2025-10-04 23:13:36 +0200 | morj_away | (~morj@user/morj) (Quit: Konversation terminated!) |
| 2025-10-04 23:11:52 +0200 | <monochrom> | Another way to say it is you have bounded backtracking or trial-and-error so it doesn't count as the bad kind of backtracking :) |
| 2025-10-04 23:10:18 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-10-04 23:10:16 +0200 | <monochrom> | I haven't checked, but I guess that if your lookahead is bounded-length, then you still enjoy LL(k) efficiency. |
| 2025-10-04 23:08:20 +0200 | <monochrom> | Whenever I teach CFG, I show this comic to students: https://www.smbc-comics.com/comic/language |
| 2025-10-04 23:07:34 +0200 | <[exa]> | ok megaparsec just backtracks, not as good as I hoped for but in the above case I guess it's valid (the lookahead ends quickly and prevents extra logic elsewhere) |
| 2025-10-04 23:06:37 +0200 | <monochrom> | "returned from deep recursion" :) |
| 2025-10-04 23:06:22 +0200 | [exa] | resurfaces |
| 2025-10-04 23:05:50 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 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 |