Newest at the top
| 2025-02-10 15:39:54 +0100 | <dminuoso> | If its not, I would refrain. |
| 2025-02-10 15:39:39 +0100 | <dminuoso> | euouae: In general lens/optics is best when your data is deeply nested. |
| 2025-02-10 15:39:36 +0100 | <euouae> | It might not be of serious use to me but the book does teach me some haskell too in between |
| 2025-02-10 15:39:19 +0100 | <euouae> | Hmm... neat. |
| 2025-02-10 15:39:01 +0100 | <dminuoso> | And `optics` gives us a tool to concisely manipulate that large structure in passes. |
| 2025-02-10 15:38:58 +0100 | <euouae> | There's ways around the wackyness of the operators, one on top of my head is to color-code them |
| 2025-02-10 15:38:45 +0100 | <dminuoso> | We have one big use case, which is a networking compiler. In our intermediate representation we have deeply nested data types (around 10 layers deep), with lists/maps, most have plenty of fields.. |
| 2025-02-10 15:37:45 +0100 | <euouae> | they do remind me also of lisp's SETF, which I also always liked but it is limited |
| 2025-02-10 15:37:44 +0100 | <dminuoso> | But the DSL (especially all the operators) can look confusing, there's only so much %~~.! and ?!~..! that my eyes can tolerate. |
| 2025-02-10 15:37:32 +0100 | <euouae> | maybe it's a style thing, but I like them personally |
| 2025-02-10 15:36:53 +0100 | <dminuoso> | Execution performance is in general really good. |
| 2025-02-10 15:36:40 +0100 | <dminuoso> | The latter. |
| 2025-02-10 15:36:29 +0100 | <euouae> | by outperform are you talking about code performance or generally that they're the better tool? |
| 2025-02-10 15:35:52 +0100 | <dminuoso> | Although I find the usecases where they outperform manual accessors are limited. |
| 2025-02-10 15:35:04 +0100 | <dminuoso> | euouae: Yeah optics/lenses are some of the most novel libraries in Haskell. |
| 2025-02-10 15:33:18 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-10 15:31:16 +0100 | CiaoSen | (~Jura@ip-037-201-241-067.um10.pools.vodafone-ip.de) CiaoSen |
| 2025-02-10 15:30:42 +0100 | <euouae> | Though lenses do make Haskell look like APL a bit, they are really cool. Like view/span of C++ but more powerful and expressive |
| 2025-02-10 15:29:40 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f99c4dbaee3a15423f1.dip0.t-ipconnect.de) acidjnk |
| 2025-02-10 15:29:09 +0100 | <euouae> | I've already written this app in the past in Python so it'll be exciting to see how much I can improve with Haskell |
| 2025-02-10 15:28:51 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 15:28:51 +0100 | <euouae> | Doing some leetcode I realized I wanted something that looked a lot like lenses so I got a book on them (penner's optics by example) and after that I'll try writing a web app |
| 2025-02-10 15:27:58 +0100 | <euouae> | I read half of the STG paper before I felt that I've been going to deep for my own good |
| 2025-02-10 15:24:52 +0100 | jespada | (~jespada@2800:a4:2243:2100:5cc9:2329:b53c:b25f) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-02-10 15:24:48 +0100 | <dminuoso> | Its just that in my parser, each step produces a bytestring buffer, and I refocus (not with the primitive I linked above, that one is a bit more special) into that slice. |
| 2025-02-10 15:24:04 +0100 | <dminuoso> | (Which is just a path description of the decoding tree) |
| 2025-02-10 15:23:53 +0100 | <dminuoso> | Plus some labels and context as to what that Int, Bool or String is. |
| 2025-02-10 15:23:40 +0100 | <dminuoso> | until you reach a primitive, and then that primitive gets turned into Int, Bool, String |
| 2025-02-10 15:23:19 +0100 | koz | (~koz@121.99.240.58) |
| 2025-02-10 15:23:18 +0100 | <dminuoso> | essentially it's slowly zooming into a bytestring buffer (though that zooming action sometimes includes fusing some chunks together over the parsing) |
| 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. |