Newest at the top
| 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) |
| 2025-02-10 15:11:02 +0100 | <haskellbridge> | <Profpatsch> Cause scanning a list is lower overhead at small size |
| 2025-02-10 15:10:50 +0100 | <haskellbridge> | <Profpatsch> dminuoso: now that I think about this, since usually the difference between maxBound and minBound is small for enums, using List.elem instead of Map.elem should be better actually |
| 2025-02-10 15:06:33 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-02-10 15:05:16 +0100 | <dminuoso> | Profpatsch: Oh, so simple and effective. I had not thought of Bounded. |
| 2025-02-10 15:04:50 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Ping timeout: 244 seconds) |
| 2025-02-10 15:03:21 +0100 | <haskellbridge> | <Profpatsch> dminuoso: https://code.tvl.fyi/tree/users/Profpatsch/my-prelude/src/MyPrelude.hs#n695 |