Newest at the top
| 2026-02-25 02:43:57 +0100 | Tuplanolla | (~Tuplanoll@88-114-89-88.elisa-laajakaista.fi) (Ping timeout: 246 seconds) |
| 2026-02-25 02:43:30 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-25 02:40:15 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2026-02-25 02:39:06 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-25 02:27:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-25 02:24:27 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2026-02-25 02:21:05 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-25 02:10:10 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 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 |