Newest at the top
2025-04-19 22:21:21 +0200 | sixfourtwelve | (~ethanmorg@82.18.82.103) (Quit: leaving) |
2025-04-19 22:20:53 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-04-19 22:16:25 +0200 | notdabs | (~Owner@2600:1700:69cf:9000:9d19:fe87:a9a8:9d05) |
2025-04-19 22:16:18 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-04-19 22:13:08 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-04-19 22:08:40 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-04-19 22:01:38 +0200 | adamCS | (~adamCS@pool-173-52-72-35.nycmny.fios.verizon.net) adamCS |
2025-04-19 21:59:14 +0200 | <EvanR> | 🤔 |
2025-04-19 21:58:53 +0200 | <c_wraith> | Which is a pretty fundamentally important distinction when writing parsers in practice. |
2025-04-19 21:58:10 +0200 | <c_wraith> | ReadP gives you distributive semantics between Alternative and Applicative, but parsec-likes don't. |
2025-04-19 21:57:53 +0200 | <EvanR> | ReadP -- read parallel |
2025-04-19 21:57:50 +0200 | <EvanR> | ReadS -- read serial |
2025-04-19 21:57:16 +0200 | <c_wraith> | That really only works if you can share parsing semantics across implementations |
2025-04-19 21:56:57 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
2025-04-19 21:56:49 +0200 | <c_wraith> | But how you write parsers is different enough that you can't do like the trifecta thing of "first run the fast parser, and if it fails run the parser that generates good error messages" |
2025-04-19 21:56:10 +0200 | <c_wraith> | having used ReadP for AoC, I like it as long as I don't need to extract useful parse errors. |
2025-04-19 21:54:26 +0200 | jmcantrell_ | jmcantrell |
2025-04-19 21:54:25 +0200 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 248 seconds) |
2025-04-19 21:54:23 +0200 | <c_wraith> | I have no idea. |
2025-04-19 21:53:02 +0200 | <EvanR> | ReadP, the P stands for parallel? |
2025-04-19 21:51:39 +0200 | <EvanR> | lol |
2025-04-19 21:51:21 +0200 | <c_wraith> | But hey. No backtracking! |
2025-04-19 21:50:31 +0200 | <c_wraith> | it's just a different set of tradeoffs, and a different set of requirements for how you write the parser. |
2025-04-19 21:49:49 +0200 | <c_wraith> | It can potentially use exponential space, as you point out |
2025-04-19 21:49:32 +0200 | <EvanR> | nice |
2025-04-19 21:49:15 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-04-19 21:49:03 +0200 | <c_wraith> | https://hackage.haskell.org/package/base-4.21.0.0/docs/Text-ParserCombinators-ReadP.html |
2025-04-19 21:48:21 +0200 | <c_wraith> | exploring each alternative in parallel is what ReadP does |
2025-04-19 21:48:16 +0200 | <EvanR> | in the pattern p* one implementation goes like... save input state, try running p. If it succeeds, discard the save and repeat. Else restore state and succeed. I wonder if there is a similar parallel alternative for p* |
2025-04-19 21:45:23 +0200 | <EvanR> | if they would fail soon does that automatically make the classic implementation not use much backtracking |
2025-04-19 21:43:14 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
2025-04-19 21:42:16 +0200 | euleritian | (~euleritia@p5b00a7f4.dip0.t-ipconnect.de) |
2025-04-19 21:42:02 +0200 | euleritian | (~euleritia@dynamic-176-006-138-003.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
2025-04-19 21:37:48 +0200 | <EvanR> | the situation where a lot of parallel patterns start building up would be when there is heavy ambiguity with long prefixes that match most of the patterns |
2025-04-19 21:35:57 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-04-19 21:34:04 +0200 | <EvanR> | ok p1 p2 or p3 might contain | patterns |
2025-04-19 21:33:46 +0200 | euleritian | (~euleritia@dynamic-176-006-138-003.176.6.pool.telefonica.de) |
2025-04-19 21:32:31 +0200 | <EvanR> | only at most 3 at a time? |
2025-04-19 21:32:15 +0200 | euleritian | (~euleritia@p5b00a7f4.dip0.t-ipconnect.de) (Ping timeout: 276 seconds) |
2025-04-19 21:31:22 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-04-19 21:31:16 +0200 | <geekosaur> | now you're saving potentially any amount of continuations |
2025-04-19 21:30:36 +0200 | <EvanR> | run p1 p2 and p3 until all of them succeed or fail or use 1 character of input. Then discard the character and repeat |
2025-04-19 21:29:58 +0200 | <EvanR> | how stupid is this alternative: |
2025-04-19 21:29:36 +0200 | <EvanR> | in the pattern p1 | p2 | p3, one matching implementation goes like... save input state, try running p1. If it succeeds fine, else restore state and try p2, etc. Which might mean saving any amount of data from the stream |
2025-04-19 21:26:49 +0200 | ChanServ | +v haskellbridge |
2025-04-19 21:26:49 +0200 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
2025-04-19 21:25:55 +0200 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection) |
2025-04-19 21:20:31 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
2025-04-19 21:19:44 +0200 | fp | (~Thunderbi@hof1.kyla.fi) fp |
2025-04-19 21:19:24 +0200 | fp | (~Thunderbi@hof1.kyla.fi) (Remote host closed the connection) |