Logs: liberachat/#haskell
| 2025-12-02 15:17:27 | <tomsmeding> | isn't what you are trying to do, outputting lists of things at various points in the computation, and then at the end you want the concatenated list of all of those? |
| 2025-12-02 15:17:31 | <tomsmeding> | that's what a writer monad does |
| 2025-12-02 15:17:34 | <tomsmeding> | that's not what ListT does |
| 2025-12-02 15:18:20 | <kuribas> | I mean, this is concatMap, with effects, no? |
| 2025-12-02 15:18:28 | <tomsmeding> | oh but the `col <- input` does do the mapping |
| 2025-12-02 15:18:35 | <tomsmeding> | _right_ |
| 2025-12-02 15:18:37 | <tomsmeding> | okay I get it now |
| 2025-12-02 15:18:45 | <tomsmeding> | please don't use ListT for this |
| 2025-12-02 15:18:59 | <tomsmeding> | it creates entirely the wrong intuition for what you're trying to do |
| 2025-12-02 15:19:12 | <tomsmeding> | :t concatMapM |
| 2025-12-02 15:19:14 | <lambdabot> | error: [GHC-88464] |
| 2025-12-02 15:19:14 | <lambdabot> | Variable not in scope: concatMapM |
| 2025-12-02 15:19:14 | <lambdabot> | Suggested fix: |
| 2025-12-02 15:19:32 | <tomsmeding> | meh it's not in base |
| 2025-12-02 15:19:32 | <kuribas> | I suppose the mapAccumL is easier to understand. |
| 2025-12-02 15:20:06 | <tomsmeding> | or execWriterT (mapM_ _ input) [] |
| 2025-12-02 15:20:44 | <tomsmeding> | the problem with writer is that it just <>'s your lists, and probably in the wrong order, so you're going to get O(n^2) behaviour |
| 2025-12-02 15:20:57 | <tomsmeding> | but DList or an Endo wrapper or something else can fix that |
| 2025-12-02 15:21:04 | <kuribas> | yeah |
| 2025-12-02 15:21:05 | <merijn> | There was an optimised writer somewhere too |
| 2025-12-02 15:21:17 | <tomsmeding> | merijn: that's just for strictness, if you mean Control.Monad.Trans.Writer.CPS |
| 2025-12-02 15:21:29 | <tomsmeding> | it still can't do better than just using <> on your things |
| 2025-12-02 15:21:39 | <tomsmeding> | if your <> is expensive, you're out of luck |
| 2025-12-02 15:22:02 | <tomsmeding> | (C.M.T.Writer.CPS is just a state monad) |
| 2025-12-02 15:22:04 | <merijn> | I was thinking something like Chronicle or seomthing? |
| 2025-12-02 15:22:12 | <kuribas> | Hmm right, ListT cannot be used for coroutines. |
| 2025-12-02 15:22:24 | <merijn> | something existed that was a better Writter beyond just strict :p |
| 2025-12-02 15:22:31 | <tomsmeding> | this thing? https://hackage.haskell.org/package/monad-chronicle-1.1/docs/Control-Monad-Chronicle.html#t:ChronicleT |
| 2025-12-02 15:22:44 | <tomsmeding> | looks like <> |
| 2025-12-02 15:23:29 | <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 15:23:42 | <tomsmeding> | I don't think you can fix this problem in general, it depends on the particular complexity of your <> |
| 2025-12-02 15:25:34 | <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 15:25:40 | <tomsmeding> | (if you really want) |
| 2025-12-02 15:26:14 | → | machinedgod joins (~machinedg@d75-159-126-101.abhsia.telus.net) |
| 2025-12-02 15:26:48 | <kuribas> | tomsmeding: actually I _can_ use ListT for this, why don't you like it? |
| 2025-12-02 15:27:15 | <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 15:27:31 | <tomsmeding> | yes, it does work (probably) |
| 2025-12-02 15:28:05 | <tomsmeding> | I guess if you add a comment it's fine :p |
| 2025-12-02 15:28:16 | <kuribas> | tomsmeding: I can do readIORef, then uncons, that will not be nondeterministic. |
| 2025-12-02 15:28:24 | <tomsmeding> | but I would seriously consider `fmap concat . forM` |
| 2025-12-02 15:28:55 | <tomsmeding> | if all you're doing is looping over a list and concatenating the results |
| 2025-12-02 15:29:02 | → | Square joins (~Square@user/square) |
| 2025-12-02 15:29:31 | RMSBach | is now known as RSBach |
| 2025-12-02 15:29:36 | <kuribas> | tomsmeding: but you just showed WriterT is inefficient? |
| 2025-12-02 15:29:45 | <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 15:29:49 | <tomsmeding> | "pure nondeterminism" |
| 2025-12-02 15:29:56 | <tomsmeding> | that's what I think when I see ListT |
| 2025-12-02 15:30:04 | <kuribas> | tomsmeding: yes, but that's actually what I wanted here. |
| 2025-12-02 15:30:22 | <tomsmeding> | kuribas: my fmap concat . forM does not use WriterT |
| 2025-12-02 15:30:27 | <kuribas> | Except you want the concat to be explicit? |
| 2025-12-02 15:30:40 | <tomsmeding> | I mean, my dislike of ListT here is subjective :p |
| 2025-12-02 15:30:53 | <tomsmeding> | it's okay if you disagree |
| 2025-12-02 15:31:02 | <kuribas> | Sure, this is overcomplication for this usecase, I fully agree :) |
| 2025-12-02 15:31:17 | <kuribas> | I just wanted to explore ListT and ST monad. |
| 2025-12-02 15:31:49 | <kuribas> | But this would be bad production code. |
| 2025-12-02 15:32:34 | × | Square2 quits (~Square4@user/square) (Ping timeout: 246 seconds) |
| 2025-12-02 15:32:35 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Ping timeout: 240 seconds) |
| 2025-12-02 15:32:48 | <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 15:32:55 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 2025-12-02 15:33:02 | <tomsmeding> | please go forth and add more monads |
| 2025-12-02 15:33:45 | <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 15:33:51 | <kuribas> | But it's fun :) |
| 2025-12-02 15:34:06 | <tomsmeding> | yes |
| 2025-12-02 15:35:01 | <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 15:35:06 | <kuribas> | Which we actually have here. |
| 2025-12-02 15:35:41 | <kuribas> | So easy to write a SAX parser in haskell without callback hell. |
| 2025-12-02 15:35:55 | <tomsmeding> | because of laziness? |
| 2025-12-02 15:36:25 | <kuribas> | because of monadic abstractions. |
| 2025-12-02 15:36:54 | → | Sgeo joins (~Sgeo@user/sgeo) |
| 2025-12-02 15:41:43 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2025-12-02 15:42:02 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 2025-12-02 15:49:23 | trickard_ | is now known as trickard |
| 2025-12-02 15:50:33 | <kuribas> | I've been wanting to port my SAX parser to rust, which has a monad macro. |
| 2025-12-02 15:50:55 | × | vanishingideal quits (~vanishing@user/vanishingideal) (Ping timeout: 240 seconds) |
| 2025-12-02 15:52:55 | × | Pozyomka quits (~pyon@user/pyon) (Quit: bbl) |
| 2025-12-02 15:53:15 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 2025-12-02 15:54:46 | → | Pozyomka joins (~pyon@user/pyon) |
| 2025-12-02 16:05:09 | × | polykernel quits (~polykerne@user/polykernel) (Ping timeout: 260 seconds) |
| 2025-12-02 16:09:29 | × | Square quits (~Square@user/square) (Ping timeout: 250 seconds) |
| 2025-12-02 16:11:52 | × | trickard quits (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-02 16:14:06 | × | Enrico63 quits (~Enrico63@host-212-171-79-170.pool212171.interbusiness.it) (Quit: Client closed) |
| 2025-12-02 16:14:38 | → | trickard_ joins (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-02 16:15:24 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Ping timeout: 244 seconds) |
| 2025-12-02 16:15:51 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 2025-12-02 16:20:01 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Ping timeout: 255 seconds) |
| 2025-12-02 16:20:24 | → | pr1sm joins (~pr1sm@2600:1000:b115:c9f2:64b7:10e9:a90c:5331) |
| 2025-12-02 16:25:04 | × | trickard_ quits (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-02 16:25:45 | × | pr1sm quits (~pr1sm@2600:1000:b115:c9f2:64b7:10e9:a90c:5331) (Ping timeout: 245 seconds) |
| 2025-12-02 16:26:11 | <haskellbridge> | <Zemyla> Is there a module for semi-ordered hashmaps, ones that require (Ord k, Hashable k), and as such have O(log n) worst-case performance? |
| 2025-12-02 16:26:38 | → | pr1sm joins (~pr1sm@24.91.163.31) |
| 2025-12-02 16:27:45 | → | trickard_ joins (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-02 16:28:13 | trickard_ | is now known as trickard |
| 2025-12-02 16:30:24 | <merijn> | Is that a thing? |
| 2025-12-02 16:30:45 | <merijn> | What's k there? (i.e. is the Hashable even worth it?) |
| 2025-12-02 16:32:13 | <lucabtz> | k is the key i suppose |
| 2025-12-02 16:33:04 | <merijn> | lucabtz: Yes, but what type do you expect that makes it worth to include Hashable over just `Ord k`? |
| 2025-12-02 16:33:48 | <merijn> | Regular Map already has O(log N) worst case, so the only reason not to use that if you expect K to have some expensive comparison |
| 2025-12-02 16:33:53 | <lucabtz> | i suppose it makes it constant time with no collisions and log n with collisions |
| 2025-12-02 16:33:56 | × | pr1sm quits (~pr1sm@24.91.163.31) (Remote host closed the connection) |
| 2025-12-02 16:34:32 | <c_wraith> | yeah, its a way of handling collisions that guarantees you'll never have an O(n) breakdown |
All times are in UTC.