Newest at the top
| 2025-12-02 16:50:33 +0100 | <kuribas> | I've been wanting to port my SAX parser to rust, which has a monad macro. |
| 2025-12-02 16:49:23 +0100 | trickard_ | trickard |
| 2025-12-02 16:42:02 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-12-02 16:41:43 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2025-12-02 16:36:54 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-12-02 16:36:25 +0100 | <kuribas> | because of monadic abstractions. |
| 2025-12-02 16:35:55 +0100 | <tomsmeding> | because of laziness? |
| 2025-12-02 16:35:41 +0100 | <kuribas> | So easy to write a SAX parser in haskell without callback hell. |
| 2025-12-02 16:35:06 +0100 | <kuribas> | Which we actually have here. |
| 2025-12-02 16:35:01 +0100 | <kuribas> | But when you actually need streaming, constant space algorithms without manual plumbing, suddenly the haskell becomes way more elegant than equivalent java. |
| 2025-12-02 16:34:06 +0100 | <tomsmeding> | yes |
| 2025-12-02 16:33:51 +0100 | <kuribas> | But it's fun :) |
| 2025-12-02 16:33:45 +0100 | <kuribas> | This just proves my point that something simple becomes complex in haskell, and suddenly opens a hole world of abstractions to get lost in. |
| 2025-12-02 16:33:02 +0100 | <tomsmeding> | please go forth and add more monads |
| 2025-12-02 16:32:55 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-12-02 16:32:48 +0100 | <tomsmeding> | under the moniker of "I want to see how this stuff works" suddenly a whole lot of things become fair game :) |
| 2025-12-02 16:32:35 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 240 seconds) |
| 2025-12-02 16:32:34 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 246 seconds) |
| 2025-12-02 16:31:49 +0100 | <kuribas> | But this would be bad production code. |
| 2025-12-02 16:31:17 +0100 | <kuribas> | I just wanted to explore ListT and ST monad. |
| 2025-12-02 16:31:02 +0100 | <kuribas> | Sure, this is overcomplication for this usecase, I fully agree :) |
| 2025-12-02 16:30:53 +0100 | <tomsmeding> | it's okay if you disagree |
| 2025-12-02 16:30:40 +0100 | <tomsmeding> | I mean, my dislike of ListT here is subjective :p |
| 2025-12-02 16:30:27 +0100 | <kuribas> | Except you want the concat to be explicit? |
| 2025-12-02 16:30:22 +0100 | <tomsmeding> | kuribas: my fmap concat . forM does not use WriterT |
| 2025-12-02 16:30:04 +0100 | <kuribas> | tomsmeding: yes, but that's actually what I wanted here. |
| 2025-12-02 16:29:56 +0100 | <tomsmeding> | that's what I think when I see ListT |
| 2025-12-02 16:29:49 +0100 | <tomsmeding> | "pure nondeterminism" |
| 2025-12-02 16:29:45 +0100 | <tomsmeding> | kuribas: I'm not talking about actual randomness, I'm talking about "let's throw a die, let's throw another one, add the two results, and see what answers we get" |
| 2025-12-02 16:29:36 +0100 | <kuribas> | tomsmeding: but you just showed WriterT is inefficient? |
| 2025-12-02 16:29:31 +0100 | RMSBach | RSBach |
| 2025-12-02 16:29:02 +0100 | Square | (~Square@user/square) Square |
| 2025-12-02 16:28:55 +0100 | <tomsmeding> | if all you're doing is looping over a list and concatenating the results |
| 2025-12-02 16:28:24 +0100 | <tomsmeding> | but I would seriously consider `fmap concat . forM` |
| 2025-12-02 16:28:16 +0100 | <kuribas> | tomsmeding: I can do readIORef, then uncons, that will not be nondeterministic. |
| 2025-12-02 16:28:05 +0100 | <tomsmeding> | I guess if you add a comment it's fine :p |
| 2025-12-02 16:27:31 +0100 | <tomsmeding> | yes, it does work (probably) |
| 2025-12-02 16:27:15 +0100 | <tomsmeding> | because ListT "means" that you're doing nondeterminism and you want all possible results, and that's very much not what you're doing |
| 2025-12-02 16:26:48 +0100 | <kuribas> | tomsmeding: actually I _can_ use ListT for this, why don't you like it? |
| 2025-12-02 16:26:14 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-12-02 16:25:40 +0100 | <tomsmeding> | (if you really want) |
| 2025-12-02 16:25:34 +0100 | <tomsmeding> | if you know that the monoid will be some kind of list, you can optimise with a mutable vector, for example |
| 2025-12-02 16:23:42 +0100 | <tomsmeding> | I don't think you can fix this problem in general, it depends on the particular complexity of your <> |
| 2025-12-02 16:23:29 +0100 | <tomsmeding> | I guess you can bake the Endo trick in the monad to re-associate the <> calls if you want, but then that would work only for monoids that want to associate to the right |
| 2025-12-02 16:22:44 +0100 | <tomsmeding> | looks like <> |
| 2025-12-02 16:22:31 +0100 | <tomsmeding> | this thing? https://hackage.haskell.org/package/monad-chronicle-1.1/docs/Control-Monad-Chronicle.html#t:Chroni… |
| 2025-12-02 16:22:24 +0100 | <merijn> | something existed that was a better Writter beyond just strict :p |
| 2025-12-02 16:22:12 +0100 | <kuribas> | Hmm right, ListT cannot be used for coroutines. |
| 2025-12-02 16:22:04 +0100 | <merijn> | I was thinking something like Chronicle or seomthing? |
| 2025-12-02 16:22:02 +0100 | <tomsmeding> | (C.M.T.Writer.CPS is just a state monad) |