2026/02/25

Newest at the top

2026-02-25 01:19:36 +0100merijn(~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 +0100peterbecich(~Thunderbi@71.84.33.135) (Ping timeout: 246 seconds)
2026-02-25 01:11:43 +0100GdeVolpiano(~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 +0100merijn(~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 +0100Tuplanolla(~Tuplanoll@88-114-89-88.elisa-laajakaista.fi) Tuplanolla
2026-02-25 01:04:16 +0100GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Ping timeout: 268 seconds)
2026-02-25 01:04:13 +0100merijn(~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 +0100peterbecich(~Thunderbi@71.84.33.135) peterbecich
2026-02-25 00:53:06 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2026-02-25 00:51:56 +0100earthy(~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 +0100chenjf(~chenjf@68.64.178.54) (Quit: WeeChat 4.8.1)
2026-02-25 00:46:11 +0100merijn(~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
2026-02-25 00:41:15 +0100bjs(sid190364@user/bjs) bjs
2026-02-25 00:40:59 +0100bjs(sid190364@user/bjs) (Server closed connection)
2026-02-25 00:40:00 +0100tamer(~tamer@5.2.74.82)
2026-02-25 00:39:39 +0100tamer(~tamer@user/tamer) (Server closed connection)
2026-02-25 00:38:57 +0100chenjf(~chenjf@68.64.178.54)
2026-02-25 00:37:02 +0100 <int-e> (but then you'd have to accumulate a full result before printing anything)
2026-02-25 00:36:15 +0100emmanuelux(~em@user/emmanuelux) emmanuelux
2026-02-25 00:36:05 +0100 <int-e> mauke: Yeah that looks like the best solution. Kind of sad; the simple greedy algorithm for the knapsack problem would work here.
2026-02-25 00:35:05 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2026-02-25 00:34:09 +0100emmanuelux(~em@user/emmanuelux) (Quit: bye)
2026-02-25 00:33:54 +0100acidsys(~crameleon@openSUSE/member/crameleon) crameleon
2026-02-25 00:33:39 +0100acidsys(~crameleon@openSUSE/member/crameleon) (Server closed connection)
2026-02-25 00:33:05 +0100Comstar(~Comstar@user/Comstar) Comstar
2026-02-25 00:32:16 +0100 <lantti> should I use _ -> as the catch all case then? I'm not working with haskell all that much as one may notice
2026-02-25 00:30:47 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-02-25 00:29:25 +0100 <lantti> (which I can recommend to anyone with children in the 1-3 primary school or earlier)
2026-02-25 00:26:53 +0100 <lantti> (and the term "step squad" comes from the BBC childrens series called Numberblocks)