2025/04/19

Newest at the top

2025-04-19 22:21:21 +0200sixfourtwelve(~ethanmorg@82.18.82.103) (Quit: leaving)
2025-04-19 22:20:53 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-04-19 22:16:25 +0200notdabs(~Owner@2600:1700:69cf:9000:9d19:fe87:a9a8:9d05)
2025-04-19 22:16:18 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-19 22:13:08 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-04-19 22:08:40 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-04-19 22:01:38 +0200adamCS(~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 +0200merijn(~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 +0200jmcantrell_jmcantrell
2025-04-19 21:54:25 +0200jmcantrell(~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 +0200merijn(~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 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds)
2025-04-19 21:42:16 +0200euleritian(~euleritia@p5b00a7f4.dip0.t-ipconnect.de)
2025-04-19 21:42:02 +0200euleritian(~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 +0200merijn(~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 +0200euleritian(~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 +0200euleritian(~euleritia@p5b00a7f4.dip0.t-ipconnect.de) (Ping timeout: 276 seconds)
2025-04-19 21:31:22 +0200merijn(~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 +0200ChanServ+v haskellbridge
2025-04-19 21:26:49 +0200haskellbridge(~hackager@syn-024-093-192-219.res.spectrum.com) hackager
2025-04-19 21:25:55 +0200haskellbridge(~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection)
2025-04-19 21:20:31 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2025-04-19 21:19:44 +0200fp(~Thunderbi@hof1.kyla.fi) fp
2025-04-19 21:19:24 +0200fp(~Thunderbi@hof1.kyla.fi) (Remote host closed the connection)