Newest at the top
| 2025-02-10 15:22:58 +0100 | <haskellbridge> | <Profpatsch> Ah, I see |
| 2025-02-10 15:22:40 +0100 | <dminuoso> | What I do is still a kind of vertical parsing in that sense. |
| 2025-02-10 15:22:34 +0100 | <dminuoso> | haskellbridge: No I get the idea of vertical parsing. |
| 2025-02-10 15:22:26 +0100 | <haskellbridge> | <Profpatsch> 420 :) |
| 2025-02-10 15:22:20 +0100 | <haskellbridge> | <Profpatsch> dminuoso: fwiw I’m not talking conventional parsers (stream of tokens to data struct) but “vertical” parsers (value of high entropy to value of lower entropy) |
| 2025-02-10 15:22:12 +0100 | <dminuoso> | Profpatsch: We should compare notes when I have a little more time, I gotta blaze. |
| 2025-02-10 15:21:53 +0100 | <dminuoso> | s/ready/read/ |
| 2025-02-10 15:21:44 +0100 | <dminuoso> | This should have been named :.: |
| 2025-02-10 15:21:34 +0100 | <dminuoso> | Gah I find prefix Compose hard to ready. |
| 2025-02-10 15:21:05 +0100 | <dminuoso> | (But its limited to when each stage expects a bytestring) |
| 2025-02-10 15:20:56 +0100 | <haskellbridge> | <Profpatsch> but never got to a point where I think it’s super interesting for the general use-case |
| 2025-02-10 15:20:44 +0100 | <dminuoso> | Which makes this >>> notion really simple to do. |
| 2025-02-10 15:20:40 +0100 | <haskellbridge> | <Profpatsch> dminuoso: I tried abstracting the pattern of creating these kinds of parsers a little with https://code.tvl.fyi/tree/users/Profpatsch/my-prelude/src/ValidationParseT.hs |
| 2025-02-10 15:20:33 +0100 | <dminuoso> | And with that, I have this super trivial refocus function: https://gist.github.com/dminuoso/e9026b66182bd438910c895184b97ad5 |
| 2025-02-10 15:19:54 +0100 | <dminuoso> | Because I like the sheer simplicity of that interface. |
| 2025-02-10 15:19:48 +0100 | <dminuoso> | Mine is directly bolted onto flatparse |
| 2025-02-10 15:19:47 +0100 | <haskellbridge> | <Profpatsch> It nearly-but-not-quite fits |
| 2025-02-10 15:19:34 +0100 | <haskellbridge> | <Profpatsch> that throws away errors |
| 2025-02-10 15:19:27 +0100 | <haskellbridge> | <Profpatsch> Ah yeah, you can have a specialized "bind" function usually |
| 2025-02-10 15:19:12 +0100 | <dminuoso> | Though I guess I could make it work too. |
| 2025-02-10 15:18:54 +0100 | <haskellbridge> | <Profpatsch> I don’t like the abstraction very much, but it’s useful for e.g. parsing XML |
| 2025-02-10 15:18:54 +0100 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2025-02-10 15:18:52 +0100 | <dminuoso> | No, its definitely monadic. |
| 2025-02-10 15:18:22 +0100 | <haskellbridge> | <Profpatsch> dminuoso: something like this? https://code.tvl.fyi/tree/users/Profpatsch/my-prelude/src/Parse.hs |
| 2025-02-10 15:18:22 +0100 | <dminuoso> | Which is important since the decoding rules are sort of passed in at runtime. |
| 2025-02-10 15:18:06 +0100 | <dminuoso> | (So I maintain a decoding tree, and while Im parsing Im recursing into my parser function) |
| 2025-02-10 15:18:01 +0100 | <haskellbridge> | <Profpatsch> always a trade-off between unbounded memory usage and good error messages |
| 2025-02-10 15:17:39 +0100 | <haskellbridge> | <Profpatsch> yeah I experimented with this as well |
| 2025-02-10 15:17:25 +0100 | <dminuoso> | I'm doing something like this but the >>> structure follows a tree, based on parsing values. |
| 2025-02-10 15:17:20 +0100 | <haskellbridge> | <Profpatsch> the best abstractions are cute and kinda silly :) |
| 2025-02-10 15:17:10 +0100 | koz | (~koz@121.99.240.58) (Ping timeout: 252 seconds) |
| 2025-02-10 15:16:54 +0100 | <dminuoso> | This is kind of cute. |
| 2025-02-10 15:16:47 +0100 | otbergsten | (~otbergste@user/otbergsten) (Remote host closed the connection) |
| 2025-02-10 15:16:39 +0100 | <haskellbridge> | <Profpatsch> it’s super simple but surprisingly versatile |
| 2025-02-10 15:16:14 +0100 | <haskellbridge> | <Profpatsch> (utf8 >>> signedDecimal) :: FieldParser ByteString Integer |
| 2025-02-10 15:15:48 +0100 | <haskellbridge> | <Profpatsch> dminuoso: composite parsing for simple values |
| 2025-02-10 15:15:30 +0100 | <haskellbridge> | <Profpatsch> dminuoso: but fwiw, there’s the TH slot: https://hackage.haskell.org/package/pa-field-parser-0.3.0.0/docs/FieldParser.html#v:literal |
| 2025-02-10 15:15:23 +0100 | <dminuoso> | Cant quite imagine the usecase. What do you use it for? |
| 2025-02-10 15:15:13 +0100 | <haskellbridge> | <Profpatsch> yeah |
| 2025-02-10 15:14:49 +0100 | <dminuoso> | It should contain some unsafe note about how it should only be used on injective pretty functions. |
| 2025-02-10 15:14:21 +0100 | <dminuoso> | Oh that looks a little bit more dangerous, now. |
| 2025-02-10 15:13:32 +0100 | <haskellbridge> | <Profpatsch> Which fits it into my actual parsing interface |
| 2025-02-10 15:13:24 +0100 | <haskellbridge> | <Profpatsch> dminuoso: I had this as well https://hackage.haskell.org/package/pa-field-parser-0.3.0.0/docs/FieldParser.html#v:invertPretty |
| 2025-02-10 15:12:39 +0100 | <haskellbridge> | <Profpatsch> yeah |
| 2025-02-10 15:12:32 +0100 | <dminuoso> | For the large general case, if you have loads of these and want optimal performance I would use TH anyway. |
| 2025-02-10 15:12:15 +0100 | <haskellbridge> | <Profpatsch> I originally copied it from relude i think |
| 2025-02-10 15:11:58 +0100 | <dminuoso> | I've already adapted it to use Data.List and simplified it a bit. |
| 2025-02-10 15:11:52 +0100 | <haskellbridge> | <Profpatsch> yeah |
| 2025-02-10 15:11:47 +0100 | <dminuoso> | Profpatsch: I think you meant List.lookup/Map.lookup rather than elem, but yeah. |
| 2025-02-10 15:11:07 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f99c4dbaee3a15423f1.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |