Newest at the top
| 2026-02-25 02:05:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-25 01:55:03 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-02-25 01:50:21 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-25 01:46:17 +0100 | xff0x | (~xff0x@ai083101.d.east.v6connect.net) (Ping timeout: 265 seconds) |
| 2026-02-25 01:41:14 +0100 | lally | (sid388228@id-388228.uxbridge.irccloud.com) lally |
| 2026-02-25 01:40:59 +0100 | lally | (sid388228@id-388228.uxbridge.irccloud.com) (Server closed connection) |
| 2026-02-25 01:39:50 +0100 | tritlo | (sid58727@id-58727.hampstead.irccloud.com) |
| 2026-02-25 01:39:39 +0100 | tritlo | (sid58727@id-58727.hampstead.irccloud.com) (Server closed connection) |
| 2026-02-25 01:39:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-25 01:34:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-25 01:34:42 +0100 | <EvanR> | yes constructing an infinite value seems kind of vague operationally, so agree that makes it hard to predict the memory usage pattern |
| 2026-02-25 01:29:43 +0100 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) robobub |
| 2026-02-25 01:26:39 +0100 | <int-e> | EvanR: The main reason I think of it that way is that it becomes harder to ensure that you expand exactly the parts of the tree that you need and you also release them to the garbage collector once you're done with them. |
| 2026-02-25 01:23:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-25 01:22:11 +0100 | <int-e> | EvanR: But yes, I may be abusing terminology a bit here. |
| 2026-02-25 01:20:57 +0100 | <int-e> | EvanR: well, no; laziness will still be a factor. |
| 2026-02-25 01:20:33 +0100 | <EvanR> | materialize = have the normal form all in memory ? |
| 2026-02-25 01:19:36 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-25 01:19:04 +0100 | <Comstar> | int-e, heard, thanks! |
| 2026-02-25 01:16:27 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 246 seconds) |
| 2026-02-25 01:11:43 +0100 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
| 2026-02-25 01:11:08 +0100 | <EvanR> | lantti, going through String is probably not great, and then i/o on the Char is doing unicode stuff, and ... |
| 2026-02-25 01:08:45 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-02-25 01:07:54 +0100 | <int-e> | I mean constructing a (potentially infinite) value of type `Tree S` where `data Tree s = Node s [Tree s]` from a root :: S and a branching function as above. |
| 2026-02-25 01:05:55 +0100 | <Comstar> | what's materializing the tree mean? |
| 2026-02-25 01:05:12 +0100 | Tuplanolla | (~Tuplanoll@88-114-89-88.elisa-laajakaista.fi) Tuplanolla |
| 2026-02-25 01:04:16 +0100 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 268 seconds) |
| 2026-02-25 01:04:13 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-25 00:53:41 +0100 | <int-e> | I've implemented quite a few breadth first searches in Haskell and I've never materialized the tree; only levels (usually as lists because it's convenient, or as sets because I expected a significant number of transpositions.) |
| 2026-02-25 00:53:22 +0100 | <lantti> | mauke: oh, now i see. so the "otherwise" only worked because any identifier would have worked there |
| 2026-02-25 00:53:16 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-02-25 00:53:06 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-02-25 00:51:56 +0100 | earthy | (~arthurvl@2a02-a469-f5e2-1-83d2-ca43-57a2-dc81.fixed6.kpn.net) (Ping timeout: 268 seconds) |
| 2026-02-25 00:51:32 +0100 | <int-e> | Leary: I don't know whether we have one. My main point was that it's abuse. |
| 2026-02-25 00:50:57 +0100 | <Comstar> | that'll be fun to explore |
| 2026-02-25 00:50:56 +0100 | <Leary> | int-e: Do we not have a (foldable) binary tree to search? And yes, I agree, but specialising the code to a binary tree means we can kill the evil. |
| 2026-02-25 00:50:56 +0100 | <int-e> | it is |
| 2026-02-25 00:50:51 +0100 | <Comstar> | oh it's prob the LambdaCase language extension |
| 2026-02-25 00:50:40 +0100 | <Comstar> | Leary, oh wow line 25 in `Search.hs` is really interesting, I didn't know you could do `\case` like that, does that trick have a name? |
| 2026-02-25 00:50:18 +0100 | <int-e> | (and it's an abuse because that Semigroup instance isn't lawful) |
| 2026-02-25 00:49:31 +0100 | <int-e> | Leary: that task is related but abuses Foldable on an infinite tree that you already have as a value. |
| 2026-02-25 00:48:15 +0100 | <Leary> | Comstar: There was a haskell challenge for this a while back. This was my solution: https://gist.github.com/LSLeary/5083d1dfe403d1562e7778713d97b22a |
| 2026-02-25 00:47:54 +0100 | <int-e> | "history" being the path through the underlying tree |
| 2026-02-25 00:47:36 +0100 | <Comstar> | yeah that makes sense |
| 2026-02-25 00:47:13 +0100 | <int-e> | Comstar: If you have a state S and function branch :: S -> [S] then the list monad's bind (aka concatMap) can produce the next level of a tree from the previous one. (This gets a bit awkward if you also want to record history, but you can make that part of S) |
| 2026-02-25 00:46:25 +0100 | chenjf | (~chenjf@68.64.178.54) (Quit: WeeChat 4.8.1) |
| 2026-02-25 00:46:11 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-25 00:45:49 +0100 | <Comstar> | I feel like I could probably find some neat code examples searching around github &al |
| 2026-02-25 00:45:29 +0100 | <Comstar> | do y'all know of a more pure approach? I guess I could do like, some folding magic |
| 2026-02-25 00:44:58 +0100 | <Comstar> | I can't think of a way to implement breadth-first searches (for the sake of discussion assume for a binary tree) that doesn't use a `Control.Monad.State` implementation |