Newest at the top
| 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 |
| 2025-02-10 15:00:36 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 14:57:00 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) (Ping timeout: 252 seconds) |
| 2025-02-10 14:55:58 +0100 | causal | (~eric@50.35.84.231) (Quit: WeeChat 4.5.1) |
| 2025-02-10 14:48:06 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-02-10 14:46:14 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 244 seconds) |
| 2025-02-10 14:46:13 +0100 | CryptLab | (NSA@gateway/vpn/protonvpn/commanderbond007) CommanderBond007 |
| 2025-02-10 14:44:08 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
| 2025-02-10 14:43:19 +0100 | CryptLab | (NSA@gateway/vpn/protonvpn/commanderbond007) (Read error: Connection reset by peer) |