2025/02/19

2025-02-19 00:00:39 +0100mange(~user@user/mange) mange
2025-02-19 00:03:48 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2025-02-19 00:04:11 +0100weary-traveler(~user@user/user363627) user363627
2025-02-19 00:05:38 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 00:09:42 +0100Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla
2025-02-19 00:12:04 +0100ljdarj1(~Thunderbi@user/ljdarj) ljdarj
2025-02-19 00:12:26 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-02-19 00:16:11 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds)
2025-02-19 00:16:12 +0100ljdarj1ljdarj
2025-02-19 00:17:26 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 00:22:02 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 272 seconds)
2025-02-19 00:23:41 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 00:27:00 +0100remexre(~remexre@user/remexre) remexre
2025-02-19 00:30:23 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds)
2025-02-19 00:31:19 +0100remexre(~remexre@user/remexre) (Ping timeout: 260 seconds)
2025-02-19 00:40:19 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2025-02-19 00:40:41 +0100stiell(~stiell@gateway/tor-sasl/stiell) stiell
2025-02-19 00:40:45 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 00:45:44 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-02-19 00:49:22 +0100remexre(~remexre@user/remexre) remexre
2025-02-19 00:52:02 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 00:54:03 +0100Googulator(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Quit: Client closed)
2025-02-19 00:54:26 +0100Googulator(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu)
2025-02-19 00:56:49 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-02-19 01:03:29 +0100ec(~ec@gateway/tor-sasl/ec) ec
2025-02-19 01:05:11 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 01:07:24 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 01:09:32 +0100ec_(~ec@gateway/tor-sasl/ec) ec
2025-02-19 01:10:10 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 272 seconds)
2025-02-19 01:12:04 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2025-02-19 01:12:12 +0100ec(~ec@gateway/tor-sasl/ec) (Ping timeout: 264 seconds)
2025-02-19 01:18:24 +0100L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 260 seconds)
2025-02-19 01:19:24 +0100ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 264 seconds)
2025-02-19 01:22:12 +0100ec(~ec@gateway/tor-sasl/ec) ec
2025-02-19 01:22:47 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 01:27:01 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-02-19 01:27:53 +0100forell(~forell@user/forell) (Ping timeout: 245 seconds)
2025-02-19 01:29:00 +0100ec(~ec@gateway/tor-sasl/ec) (Ping timeout: 264 seconds)
2025-02-19 01:29:41 +0100L29Ah(~L29Ah@wikipedia/L29Ah) L29Ah
2025-02-19 01:30:31 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-02-19 01:30:58 +0100ec(~ec@gateway/tor-sasl/ec) ec
2025-02-19 01:34:11 +0100yegorc(~yegorc@user/yegorc) yegorc
2025-02-19 01:38:09 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 01:38:47 +0100tremon(~tremon@83.80.159.219) (Quit: getting boxed in)
2025-02-19 01:38:56 +0100sprotte24(~sprotte24@p200300d16f0680009d71da3872d3d25e.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2025-02-19 01:41:21 +0100acidjnk(~acidjnk@p200300d6e7283f20718e6a656831e8a3.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2025-02-19 01:42:53 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2025-02-19 01:47:27 +0100ec_(~ec@gateway/tor-sasl/ec) ec
2025-02-19 01:47:36 +0100ec(~ec@gateway/tor-sasl/ec) (Ping timeout: 264 seconds)
2025-02-19 01:52:36 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 01:53:42 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 01:54:03 +0100ec(~ec@gateway/tor-sasl/ec) ec
2025-02-19 01:54:48 +0100ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 264 seconds)
2025-02-19 01:56:56 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 252 seconds)
2025-02-19 01:58:56 +0100Eoco(~ian@128.101.131.218) (Ping timeout: 272 seconds)
2025-02-19 02:00:36 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-02-19 02:02:35 +0100j1n37-(~j1n37@user/j1n37) j1n37
2025-02-19 02:02:54 +0100Googulator13(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu)
2025-02-19 02:03:19 +0100xff0x(~xff0x@2405:6580:b080:900:4548:6ab4:269:a170) (Ping timeout: 260 seconds)
2025-02-19 02:04:04 +0100j1n37(~j1n37@user/j1n37) (Ping timeout: 260 seconds)
2025-02-19 02:06:40 +0100Googulator(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Ping timeout: 240 seconds)
2025-02-19 02:07:50 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2025-02-19 02:07:50 +0100Eoco(~ian@128.101.131.218) Eoco
2025-02-19 02:08:34 +0100stiell(~stiell@gateway/tor-sasl/stiell) stiell
2025-02-19 02:11:45 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 02:13:22 +0100Eoco(~ian@128.101.131.218) (Ping timeout: 268 seconds)
2025-02-19 02:16:40 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2025-02-19 02:19:41 +0100hattckory(~hattckory@67.71.152.102) (Read error: Connection reset by peer)
2025-02-19 02:19:56 +0100hattckory(~hattckory@149.102.242.103)
2025-02-19 02:23:51 +0100ezzieyguywuf(~Unknown@user/ezzieyguywuf) ezzieyguywuf
2025-02-19 02:27:08 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 02:27:36 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 02:31:30 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-02-19 02:32:13 +0100califax(~califax@user/califx) (Remote host closed the connection)
2025-02-19 02:33:27 +0100califax(~califax@user/califx) califx
2025-02-19 02:34:08 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 245 seconds)
2025-02-19 02:35:10 +0100zungi(~tory@user/andrewchawk) andrewchawk
2025-02-19 02:35:25 +0100bilegeek(~bilegeek@2600:1008:b0a4:c6d5:66f:6873:2abc:50c5) (Quit: Leaving)
2025-02-19 02:38:46 +0100bilegeek(~bilegeek@2600:1008:b0a4:c6d5:66f:6873:2abc:50c5) bilegeek
2025-02-19 02:41:36 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds)
2025-02-19 02:42:28 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 02:45:00 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 02:46:48 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-02-19 02:49:22 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 252 seconds)
2025-02-19 02:52:53 +0100weary-traveler(~user@user/user363627) (Remote host closed the connection)
2025-02-19 02:54:08 +0100Googulator13(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Quit: Client closed)
2025-02-19 02:54:25 +0100Googulator13(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu)
2025-02-19 02:55:34 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2025-02-19 02:57:52 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 02:59:58 +0100machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 245 seconds)
2025-02-19 03:00:45 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds)
2025-02-19 03:02:49 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-02-19 03:03:01 +0100Square(~Square@user/square) (Ping timeout: 248 seconds)
2025-02-19 03:10:52 +0100Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2025-02-19 03:13:15 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 03:19:04 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-02-19 03:30:02 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 03:33:04 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 03:34:34 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-02-19 03:36:41 +0100weary-traveler(~user@user/user363627) user363627
2025-02-19 03:37:14 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds)
2025-02-19 03:37:51 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 268 seconds)
2025-02-19 03:48:04 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 03:52:56 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2025-02-19 03:57:39 +0100vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 260 seconds)
2025-02-19 03:59:03 +0100vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2025-02-19 04:03:28 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 04:03:47 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds)
2025-02-19 04:07:50 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-02-19 04:10:02 +0100byorgey(~byorgey@user/byorgey) (Ping timeout: 252 seconds)
2025-02-19 04:10:20 +0100byorgey(~byorgey@user/byorgey) byorgey
2025-02-19 04:18:49 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 04:20:49 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 04:23:58 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2025-02-19 04:25:20 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 268 seconds)
2025-02-19 04:28:46 +0100 <simon1> I want to make a function that yields a deterministically shuffled list. So I'm trying to use this signature `RandomGen gen => [a] -> gen -> IO [a]`, but when try to use the function `next` I get the warning `Deprecated: "No longer used"`. What replaces `next` and `RandomGen` then?
2025-02-19 04:28:51 +0100simon1sim590
2025-02-19 04:32:34 +0100 <geekosaur> RandomGen is still used, but next has been deprecated since random-1.1. https://hackage.haskell.org/package/random-1.3.0/docs/System-Random.html#v:next explains and provides references and alternatives
2025-02-19 04:32:35 +0100 <sim590> Ah. I guess I wanna use `random` instead.
2025-02-19 04:32:43 +0100 <sim590> Right?
2025-02-19 04:33:53 +0100 <geekosaur> you should use an operation specialized for your target type (next always converted to/from Integer)
2025-02-19 04:34:12 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 04:34:19 +0100 <sim590> I mean the function `random` as in `random :: RandomGen gen => gen -> (a, gen)` ?
2025-02-19 04:34:38 +0100 <sim590> Instead of using `next`.
2025-02-19 04:34:45 +0100 <monochrom> For shuffling, use randomR for Int.
2025-02-19 04:35:21 +0100 <monochrom> or even randomRs if your gen won't be used elsewhere.
2025-02-19 04:35:47 +0100 <monochrom> On a different note, given gen, I don't see why you still need IO.
2025-02-19 04:36:35 +0100 <sim590> monochrom: actually, I'm writing a network application. All nodes have the same seed and they have to generate a random state from that seed. So I need to initialize a generator with the same seed on all nodes.
2025-02-19 04:37:18 +0100 <monochrom> Huh that comes across as https://xkcd.com/221/
2025-02-19 04:39:08 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2025-02-19 04:42:42 +0100 <sim590> ? All my nodes are gonna have a list of elements and they need to generate the same shuffled list. This is because my application is a game where every node has been given the player list, but now we have to know which player starts first, so then I shuffle the list according to a hexdigit code. Yes, this is not "random", but that is not what I need. I need a deterministicly shuffled list.
2025-02-19 04:44:13 +0100 <monochrom> Is there anything wrong with generating the list just once and passing it to all nodes?
2025-02-19 04:44:51 +0100 <monochrom> But either version still doesn't need IO.
2025-02-19 04:46:30 +0100 <sim590> No, I don't need IO, it's true. I actually just generalized my code to something that doesn't need IO, but my first iteration did need IO because the function I evolved from did actual randomness for shuffling. But, now I don't. It's becasue I'm evolving the code of the game from single player to multiplayer now.
2025-02-19 04:48:45 +0100 <monochrom> Even for actual PRNG I would still go for either gen -> ([a], gen) or gen -> [a] or the new-fangled StatefulGen monads, and avoid committing to IO.
2025-02-19 04:49:35 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 04:52:37 +0100 <monochrom> Actually I ended up using s/StatefulGen/RandomGenM/ because it has nicer functions eg randomRM.
2025-02-19 04:52:49 +0100 <sim590> as for shuffling the list before sending it over, yes, it's true I could do that. But, since every node already have the seed from the start (the game code given by the user), I prefer just sorting the list first, then shuffling it according to the code because then other nodes don't rely on the host so much. They can generate this themselves. There is no server. It's all taking place ontop of a
2025-02-19 04:52:51 +0100 <sim590> distributed hash table.
2025-02-19 04:53:56 +0100yegorc(~yegorc@user/yegorc) (Leaving)
2025-02-19 04:54:02 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-02-19 04:57:11 +0100 <jackdk> What are your plans for when a new node comes online and needs to acquire the same random state, or if there is a bug in your code and nodes call a randomisation function a different number of times or use the results in a different order?
2025-02-19 04:58:11 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 04:59:15 +0100 <monochrom> I don't normally worry about a bug that affects one node but not others. All nodes run the same code because programmers are too lazy to write two versions. Therefore all nodes run the same bug anyway.
2025-02-19 05:00:49 +0100 <monochrom> BTW it's also why our university discourages anyone except the top authority from talking about exam timetables and venues. Because if there is to be a mistake, it is better for everyone to make the same mistake (sourced from one single source) than inconsistency hell.
2025-02-19 05:01:18 +0100 <jackdk> How do you update things to a new version without downtime?
2025-02-19 05:01:45 +0100 <monochrom> Perhaps don't make new versions? >:)
2025-02-19 05:01:56 +0100tavare(~tavare@user/tavare) tavare
2025-02-19 05:02:00 +0100 <jackdk> Perfect.
2025-02-19 05:02:28 +0100 <monochrom> The serious and honest answer is I don't know.
2025-02-19 05:02:29 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 248 seconds)
2025-02-19 05:04:18 +0100 <monochrom> The aternative is to accept that you now have the Byzantine Generals problem and you still taking distributed algorithms seriously, i.e., there is a voting system, there is cryptographical hashes, there is a Lamport partially-ordered clock system, ...
2025-02-19 05:04:35 +0100 <monochrom> s/still/start/
2025-02-19 05:04:57 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 05:06:09 +0100 <monochrom> or in other words, if there is going to be a non-shared bug, then both "send a seed" and "send a list" are vulnerable to their respective non-shared bugs, e.g., "what if one node has a bug that uses the list wrongly?"
2025-02-19 05:06:12 +0100 <sim590> jackdk: there's a connection stage where we wait for everyone before the game starts. The list is not gonna be shuffled before we end that stage and everybody is connected (i.e. the "host" knows about them).
2025-02-19 05:07:00 +0100 <sim590> Yeah, and for now I assume that every nodes run the same code of course.
2025-02-19 05:07:03 +0100 <jackdk> And then you're doing synchronous lockstep simulation across nodes?
2025-02-19 05:07:41 +0100 <jackdk> s/across nodes/across all nodes at once/
2025-02-19 05:07:54 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 05:09:47 +0100 <sim590> The game code is going to be the initial seed for everything. Everyone is gonna have that seed. The game is a turn base game so every player will just be able to repeat the exact same operations by listening to packets containing the player's turn info. It will be some data that modifies the state. They use that packet to update they're state. Every player turn is going to also change the current
2025-02-19 05:09:49 +0100 <sim590> "seed" identifying where players are in the chain of turns.
2025-02-19 05:10:06 +0100 <monochrom> I'm OK with "the list is 5GB so sending a 32-bit seed over the network is better".
2025-02-19 05:10:45 +0100 <monochrom> But if it is "this is a legacy system, that's why" then it's just sad.
2025-02-19 05:12:02 +0100 <monochrom> Well, I still find joy in it with https://www.vex.net/~trebla/humour/pessimisms.html #2. Gotta make the best of what you have.
2025-02-19 05:12:12 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds)
2025-02-19 05:12:22 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 252 seconds)
2025-02-19 05:13:22 +0100 <sim590> Regarding the byzantine general problem, I don't think that this applies for me because this game is turn based, so there's no concurrency issues.
2025-02-19 05:13:40 +0100 <sim590> Everybody is going to evolve at the same rate waiting for the player to make his turn.
2025-02-19 05:13:51 +0100 <sim590> current* player
2025-02-19 05:18:23 +0100 <jackdk> I am curious as to why you need a DHT - this sounds like a small enough network where DHTs would mostly be useful as an exercise.
2025-02-19 05:18:56 +0100 <monochrom> Speaking of which, the distributed algorithm course I took was taught by two profs together, one from Greece, another of Egyptian ethnicity (like, he is a French citizen but his parent came from Egypt).
2025-02-19 05:18:57 +0100 <sim590> I don't "need" a DHT. I just wanna make a multiplayer code without making server code.
2025-02-19 05:19:14 +0100 <sim590> multiplayer game*
2025-02-19 05:19:22 +0100 <monochrom> It took 5 years to dawn on me "wait, Byzantine generals you say? and two of them?"
2025-02-19 05:20:04 +0100 <sim590> hmmmm :)
2025-02-19 05:20:09 +0100 <jackdk> sim590: Yeah that's fair. I'd just look at making the gamestate a left fold of events, some of which are generated by other players. And then you can hold the same state at each node
2025-02-19 05:22:10 +0100sim590(~simon@209-15-185-101.resi.cgocable.ca) (WeeChat 4.5.1)
2025-02-19 05:22:22 +0100sim590(~simon@209-15-185-101.resi.cgocable.ca) sim590
2025-02-19 05:23:00 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 05:24:34 +0100 <sim590> jackdk: also I did help develop the DHT over here: https://github.com/savoirfairelinux/opendht/ during 2015-2017. So I've become quite familiar with Kademlia and quite found of it also. When I decided to make a game and also think about making it multiplayer, that is the first thing I thought about doing. But I like Haskell and OpenDHT is in C++, so I had to write the bindings!
2025-02-19 05:24:36 +0100 <sim590> https://github.com/sim590/opendht-hs/. All of that was a fun experience, so that's pretty much because of all these reasons.
2025-02-19 05:24:54 +0100 <jackdk> Having fun is a pretty good reason
2025-02-19 05:24:58 +0100 <sim590> Yup
2025-02-19 05:25:08 +0100 <jackdk> sim590: https://github.com/ESWAT/john-carmack-plan-archive/blob/master/by_day/johnc_plan_19981014.txt Carmack doesn't use these words, but it really sounds like he made the state a strict left fold over an event stream.
2025-02-19 05:26:08 +0100 <sim590> I've made this nice project also in the past: https://github.com/sim590/dpaste/. A pastebin running on the DHT (IRC folks should like that). I still have to work on it because I need to expand the file limit size by spreading the values in multiple packets. I'll do that after I finish my game I guess or when I feel like id... :-)
2025-02-19 05:27:30 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-02-19 05:29:08 +0100 <sim590> jackdk: Hmmmmm.... Who's Carmack ??
2025-02-19 05:30:27 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 05:30:46 +0100aforemny_(~aforemny@2001:9e8:6ce5:a900:aaac:d53d:16e5:71d8) aforemny
2025-02-19 05:31:13 +0100 <jackdk> wrote Commander Keen, Wolf3D, Doom, Quake, etc.
2025-02-19 05:31:41 +0100 <sim590> Oh. I see. A big name in gaming.
2025-02-19 05:32:18 +0100 <sim590> Oh I think I just got what you hinted at with the folding thing. Was that a joke about the lines not being folded in his file? lol
2025-02-19 05:32:22 +0100aforemny(~aforemny@i59F4C483.versanet.de) (Ping timeout: 272 seconds)
2025-02-19 05:33:22 +0100 <monochrom> Oh haha the irony.
2025-02-19 05:34:33 +0100 <jackdk> No, as in it sounds like he got a lot of portability and other architectural benefits from building Q3 around (morally) a function `State -> Event -> State` and having all the event sources produce onto a queue that is consumed by the game engine, a lot like the `Data.List.foldl'` function.
2025-02-19 05:34:54 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 272 seconds)
2025-02-19 05:36:14 +0100forell(~forell@user/forell) forell
2025-02-19 05:38:21 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 05:42:48 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-02-19 05:43:49 +0100michalz(~michalz@185.246.207.203)
2025-02-19 05:44:22 +0100 <haskellbridge> <Liamzee> are there any suggestions on improving this code? It feels hacky, and there's probably too much IO coupling
2025-02-19 05:44:26 +0100 <haskellbridge> <Liamzee> https://paste.tomsmeding.com/gTV1Ck0j
2025-02-19 05:44:30 +0100 <sim590> jackdk:sounds like a logical approach.
2025-02-19 05:45:56 +0100Inst(~Inst@user/Inst) Inst
2025-02-19 05:46:05 +0100 <haskellbridge> <Liamzee> hmmm
2025-02-19 05:46:49 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-02-19 05:50:59 +0100 <sim590> Liamzee: that is actually funny that you send that piece of code because I'm trying to teach Haskell to someone. And that someone asked me if it would be easy to make the snake game in Haskell... :)
2025-02-19 05:52:32 +0100Inst(~Inst@user/Inst) (Remote host closed the connection)
2025-02-19 05:53:43 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 05:54:19 +0100 <sim590> Liamzee: by the way, if you're looking to experiment around with this, you might be interested in Brick https://github.com/jtdaugherty/brick. It is a library that helps making TUIs and it seems like your game is text based. It actually takes care of alot of stuff for you like key press and stuff.
2025-02-19 05:56:18 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 05:57:28 +0100 <sim590> Liamzee, I don't see how you could not use IO wherever you do use it. It seems like everywhere you use it is where you need to handle the screen or user input. That seems fine to me. But, I'm far from being a Haskell guru :)
2025-02-19 05:58:12 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-02-19 06:00:33 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 244 seconds)
2025-02-19 06:04:17 +0100rvalue(~rvalue@user/rvalue) (Read error: Connection reset by peer)
2025-02-19 06:04:48 +0100rvalue(~rvalue@user/rvalue) rvalue
2025-02-19 06:08:52 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 06:09:07 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 06:13:32 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 272 seconds)
2025-02-19 06:13:44 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-02-19 06:14:05 +0100ephilalethes(~noumenon@2001:d08:1a00:bc0:aa7e:eaff:fede:ff94) noumenon
2025-02-19 06:17:59 +0100alp(~alp@2001:861:8ca0:4940:e4d1:8a6d:1936:4535) (Ping timeout: 252 seconds)
2025-02-19 06:24:31 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 06:28:50 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-02-19 06:39:19 +0100ZLima12(~zlima12@user/meow/ZLima12) (Remote host closed the connection)
2025-02-19 06:40:28 +0100ZLima12(~zlima12@user/meow/ZLima12) ZLima12
2025-02-19 06:40:37 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 06:41:50 +0100 <haskellbridge> <Liamzee> sim590: Claude, DeepSeek R1 can all produce fairly decent Haskell code that mainly needs stylistic correction for these types of micro-programs. Also, if you're focusing on IO, you need to prioritize concurrency, which is why I'm wondering if the usage of MVar is correct here (IORef would actually provide better functionality for what I'm trying to do).
2025-02-19 06:43:10 +0100 <haskellbridge> <Liamzee> I was originally planning to upgrade to Brick, but I spent two days pushing this out (mainly hamstrung by lack of confidence in concurrency features), so I'm more likely to move to my primary project, which would be a Rust-based API caller for claim verification in social media.
2025-02-19 06:44:02 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 06:45:56 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds)
2025-02-19 06:48:34 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 260 seconds)
2025-02-19 06:49:28 +0100lisbeths(uid135845@id-135845.lymington.irccloud.com) lisbeths
2025-02-19 06:51:25 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-02-19 06:54:09 +0100chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2025-02-19 06:54:24 +0100chexum(~quassel@gateway/tor-sasl/chexum) chexum
2025-02-19 06:56:11 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 07:00:47 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-02-19 07:01:43 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2025-02-19 07:01:55 +0100Guest52(~Guest52@host-64-178-152-151.public.eastlink.ca)
2025-02-19 07:02:06 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-02-19 07:08:12 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 07:12:34 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-02-19 07:17:50 +0100takuan(~takuan@d8D86B601.access.telenet.be)
2025-02-19 07:19:28 +0100CiaoSen(~Jura@ip-037-201-240-075.um10.pools.vodafone-ip.de) CiaoSen
2025-02-19 07:21:12 +0100monochrom(trebla@216.138.220.146) (Quit: ZNC 1.9.1+deb1 - https://znc.in)
2025-02-19 07:21:53 +0100akegalj(~akegalj@89-172-194-52.adsl.net.t-com.hr) akegalj
2025-02-19 07:23:36 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 07:24:58 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 245 seconds)
2025-02-19 07:27:03 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 07:29:16 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2025-02-19 07:31:07 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 07:35:33 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 265 seconds)
2025-02-19 07:38:25 +0100monochrom(trebla@216.138.220.146)
2025-02-19 07:39:39 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 07:40:52 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 265 seconds)
2025-02-19 07:44:09 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-02-19 07:49:37 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2025-02-19 07:55:02 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 07:59:02 +0100ft(~ft@p4fc2a610.dip0.t-ipconnect.de) (Quit: leaving)
2025-02-19 08:01:45 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-02-19 08:09:15 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 08:13:52 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-02-19 08:17:13 +0100tccq(~user@user/tccq) tccq
2025-02-19 08:18:31 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 08:23:01 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 248 seconds)
2025-02-19 08:24:37 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 08:29:17 +0100internatetional(~nate@2001:448a:20a3:c2e5:9ba2:a48e:b934:7d97) internatetional
2025-02-19 08:32:52 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2025-02-19 08:41:59 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 08:43:36 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-19 08:45:36 +0100JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty
2025-02-19 08:46:17 +0100JuanDaugherty(~juan@user/JuanDaugherty) (Client Quit)
2025-02-19 08:46:52 +0100JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty
2025-02-19 08:47:57 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-02-19 08:50:25 +0100alp(~alp@2001:861:8ca0:4940:d9b9:1143:525c:6490)
2025-02-19 08:55:19 +0100alp(~alp@2001:861:8ca0:4940:d9b9:1143:525c:6490) (Ping timeout: 260 seconds)
2025-02-19 08:57:01 +0100ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2025-02-19 08:57:26 +0100ec(~ec@gateway/tor-sasl/ec) ec
2025-02-19 08:57:27 +0100alp(~alp@2001:861:8ca0:4940:8f29:5e1f:1daa:6400)
2025-02-19 08:58:10 +0100internatetional(~nate@2001:448a:20a3:c2e5:9ba2:a48e:b934:7d97) (Quit: WeeChat 4.5.1)
2025-02-19 08:58:57 +0100Guest52(~Guest52@host-64-178-152-151.public.eastlink.ca) (Quit: Client closed)
2025-02-19 09:00:00 +0100caconym(~caconym@user/caconym) (Quit: bye)
2025-02-19 09:00:12 +0100tromp(~textual@2a02:a210:cba:8500:593d:9801:ba8:3982)
2025-02-19 09:01:00 +0100caconym(~caconym@user/caconym) caconym
2025-02-19 09:06:35 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 09:11:30 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 272 seconds)
2025-02-19 09:12:02 +0100ephilalethes(~noumenon@2001:d08:1a00:bc0:aa7e:eaff:fede:ff94) (Quit: Leaving)
2025-02-19 09:16:05 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 265 seconds)
2025-02-19 09:27:07 +0100acidjnk(~acidjnk@p200300d6e7283f64718e6a656831e8a3.dip0.t-ipconnect.de) acidjnk
2025-02-19 09:33:59 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2025-02-19 09:36:03 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 09:36:13 +0100forell(~forell@user/forell) (Ping timeout: 245 seconds)
2025-02-19 09:36:33 +0100forell(~forell@user/forell) forell
2025-02-19 09:36:53 +0100sord937(~sord937@gateway/tor-sasl/sord937) sord937
2025-02-19 09:37:26 +0100 <Athas> Is 'ad' the best AD package for Haskell these days?
2025-02-19 09:37:47 +0100 <Athas> (For relatively simple uses.)
2025-02-19 09:41:13 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 245 seconds)
2025-02-19 09:41:20 +0100misterfish(~misterfis@84.53.85.146) misterfish
2025-02-19 09:46:25 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 09:50:30 +0100merijn(~merijn@77.242.116.146) merijn
2025-02-19 09:51:49 +0100tnt1(~Thunderbi@user/tnt1) tnt1
2025-02-19 09:53:17 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 265 seconds)
2025-02-19 09:54:19 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 09:55:40 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-02-19 09:55:56 +0100remedan(~remedan@ip-62-245-108-153.bb.vodafone.cz) (Ping timeout: 244 seconds)
2025-02-19 09:56:04 +0100machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod
2025-02-19 09:57:22 +0100rubin55(uid666177@id-666177.lymington.irccloud.com) rubin55
2025-02-19 09:58:37 +0100rubin55(uid666177@id-666177.lymington.irccloud.com) (Client Quit)
2025-02-19 09:58:44 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 252 seconds)
2025-02-19 10:05:21 +0100alp(~alp@2001:861:8ca0:4940:8f29:5e1f:1daa:6400) (Ping timeout: 248 seconds)
2025-02-19 10:06:58 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 268 seconds)
2025-02-19 10:07:54 +0100remedan(~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan
2025-02-19 10:10:00 +0100AlexNoo_(~AlexNoo@178.34.161.111)
2025-02-19 10:10:21 +0100 <tomsmeding> Athas: if you find any better ones, please enlighten me :p
2025-02-19 10:10:36 +0100 <tomsmeding> monochrom: thanks!
2025-02-19 10:11:12 +0100 <tomsmeding> oh you have already sent me this once
2025-02-19 10:12:09 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 10:12:18 +0100AlexZenon(~alzenon@178.34.150.53) (Ping timeout: 252 seconds)
2025-02-19 10:13:21 +0100AlexNoo(~AlexNoo@178.34.150.53) (Ping timeout: 248 seconds)
2025-02-19 10:13:46 +0100Digitteknohippie(~user@user/digit) Digit
2025-02-19 10:14:52 +0100Digit(~user@user/digit) (Ping timeout: 252 seconds)
2025-02-19 10:16:37 +0100AlexZenon(~alzenon@178.34.161.111)
2025-02-19 10:16:42 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 252 seconds)
2025-02-19 10:22:44 +0100j1n37-(~j1n37@user/j1n37) (Read error: Connection reset by peer)
2025-02-19 10:23:27 +0100 <tomsmeding> Athas: if you're okay with writing your code in a TH quote, and various related crappiness-of-API issues, ad-dualrev-th is approximately 2x as fast
2025-02-19 10:23:42 +0100 <tomsmeding> but really, just use Futhark? ;)
2025-02-19 10:25:21 +0100 <Athas> I don't need the objective performance. I just want to contribute a Haskell implementation to gradbench.
2025-02-19 10:25:30 +0100pikajude(~jude@149.28.207.64) (Ping timeout: 252 seconds)
2025-02-19 10:25:43 +0100 <Athas> 'ad' looks pretty simple.
2025-02-19 10:25:50 +0100pikajude(~jude@149.28.207.64) pikajude
2025-02-19 10:26:04 +0100 <tomsmeding> it's certainly simple to use and well-established
2025-02-19 10:26:20 +0100 <Athas> What do people use it for in practice?
2025-02-19 10:26:26 +0100 <tomsmeding> not performance
2025-02-19 10:26:35 +0100tremon(~tremon@83.80.159.219) tremon
2025-02-19 10:26:42 +0100 <Athas> But what kinds of Haskell applications need AD?
2025-02-19 10:27:20 +0100igemnace(~igemnace@user/igemnace) (Ping timeout: 252 seconds)
2025-02-19 10:27:23 +0100igemnace_(~igemnace@user/igemnace) igemnace
2025-02-19 10:27:41 +0100 <tomsmeding> I honestly don't know. I think there's a chicken-egg problem here: there are no good & fast AD tools in Haskell, so if you want to write something that needs such things, you use a different language
2025-02-19 10:28:34 +0100j1n37(~j1n37@user/j1n37) j1n37
2025-02-19 10:28:58 +0100igemnace_igemnace
2025-02-19 10:29:22 +0100alp(~alp@2001:861:8ca0:4940:bb72:dec1:2682:160e)
2025-02-19 10:31:08 +0100j1n37(~j1n37@user/j1n37) (Read error: Connection reset by peer)
2025-02-19 10:32:06 +0100 <Athas> 'ad' seems pretty comprehensive, so it must be useful to someone.
2025-02-19 10:33:04 +0100 <tomsmeding> I heard from someone recently that they used it as a placeholder implementation of AD for a probabilistic programming language they were working on, where they cared more about the clever PPL things than actual performance just yet
2025-02-19 10:33:21 +0100eL_Bart0(eL_Bart0@dietunichtguten.org) (Ping timeout: 244 seconds)
2025-02-19 10:35:11 +0100j1n37(~j1n37@user/j1n37) j1n37
2025-02-19 10:35:41 +0100lxsameer(~lxsameer@Serene/lxsameer) lxsameer
2025-02-19 10:35:54 +0100__monty__(~toonn@user/toonn) toonn
2025-02-19 10:36:02 +0100 <tomsmeding> Athas: why do the eval Dockerfiles install torch?
2025-02-19 10:36:02 +0100j1n37(~j1n37@user/j1n37) (Read error: Connection reset by peer)
2025-02-19 10:36:57 +0100 <Athas> Ugh. Because pytorch was until a few hours ago the reference implementation used for validation.
2025-02-19 10:37:03 +0100 <Athas> And I forgot to cleanse the Dockerfiles.
2025-02-19 10:37:10 +0100 <tomsmeding> I suspected so :)
2025-02-19 10:37:14 +0100 <tomsmeding> or something like it
2025-02-19 10:39:35 +0100 <tomsmeding> Athas: this looks cute. If you do add 'ad', a suggestion: get a diff of precisely what was necessary to implement, say, two of the evals with this new tool. (2 instead of 1 to capture what's necessary for a new tool, as well as what's necessary for just a new tool-eval combination.) That will be nice for someone else who wants to contribute a new tool :)
2025-02-19 10:40:14 +0100j1n37(~j1n37@user/j1n37) j1n37
2025-02-19 10:40:18 +0100 <Athas> A 'diff' in what sense? Each eval will be a single Haskell module.
2025-02-19 10:40:35 +0100 <tomsmeding> there's currently no haskell tools in there yet, right?
2025-02-19 10:40:37 +0100 <Athas> It's actually not so difficult; I'm working on it now. I spend more time figuring out how to get Haskell in a Dockerfile than I do actually writing Haskell code.
2025-02-19 10:40:53 +0100 <tomsmeding> it's precisely the Dockerfile stuff that I'm most interested in ;)
2025-02-19 10:40:56 +0100 <tomsmeding> I know how to write haskell too.
2025-02-19 10:41:34 +0100 <tomsmeding> "I want to contribute a Tool to gradbench written in my spiffy language CoolLang; what do I do?"
2025-02-19 10:41:43 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 10:42:36 +0100 <Athas> I'm afraid the difficult part is the ad-hoc trouble of setting up Docker for CoolLang.
2025-02-19 10:42:54 +0100 <tomsmeding> assume I can handle that part :)
2025-02-19 10:43:00 +0100 <tomsmeding> I see that I should probably just read CONTRIBUTING.md
2025-02-19 10:43:25 +0100 <tomsmeding> still, having a single commit that adds a tool is nice as a reference, perhaps
2025-02-19 10:43:34 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 265 seconds)
2025-02-19 10:43:34 +0100 <Athas> You also have to implement the (JSON-based) protocol for every language. It's really surprisingly easy.
2025-02-19 10:43:38 +0100 <Athas> A lot easier than ADBench.
2025-02-19 10:43:43 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 10:43:57 +0100 <tomsmeding> yeah I think I like the JSON protocol
2025-02-19 10:44:18 +0100 <tomsmeding> from the benchmark names it looks rather like this is intended to be a successor to ADBench, too :)
2025-02-19 10:45:13 +0100 <Athas> Yes. I'm not the one who came up with GradBench, but I have contributed some things. It was a loss when ADBench died.
2025-02-19 10:45:13 +0100j1n37(~j1n37@user/j1n37) (Read error: Connection reset by peer)
2025-02-19 10:46:02 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 252 seconds)
2025-02-19 10:46:59 +0100 <Athas> Oh lovely, there are official Haskell Docker images.
2025-02-19 10:47:13 +0100 <Athas> The cabal-install in the Debian and Ubuntu images was too old.
2025-02-19 10:48:30 +0100 <tomsmeding> to say nothing of the GHC in those images, probably
2025-02-19 10:49:12 +0100kuribas(~user@ip-188-118-57-242.reverse.destiny.be) kuribas
2025-02-19 10:50:50 +0100 <Athas> I must admit that I find Haskell very enjoyable when you're just putting around reading and writing JSON formats, and doing other simple computer things.
2025-02-19 10:51:00 +0100 <Athas> I spend too much time solving complicated problems with Haskell.
2025-02-19 10:53:41 +0100merijn(~merijn@77.242.116.146) merijn
2025-02-19 10:53:48 +0100chele(~chele@user/chele) chele
2025-02-19 10:54:26 +0100 <kuribas> I find haskell very enjoyable when I am doing simple things in clojure.
2025-02-19 10:54:27 +0100CiaoSen(~Jura@ip-037-201-240-075.um10.pools.vodafone-ip.de) (Ping timeout: 268 seconds)
2025-02-19 10:54:32 +0100tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2025-02-19 10:56:40 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 252 seconds)
2025-02-19 11:04:50 +0100Inst(~Inst@user/Inst) Inst
2025-02-19 11:06:09 +0100tcard(~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Remote host closed the connection)
2025-02-19 11:06:26 +0100tcard(~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) tcard
2025-02-19 11:06:55 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds)
2025-02-19 11:07:05 +0100 <Athas> tomsmeding: since you expressed interest: https://github.com/gradbench/gradbench/pull/272
2025-02-19 11:07:12 +0100bilegeek(~bilegeek@2600:1008:b0a4:c6d5:66f:6873:2abc:50c5) (Quit: Leaving)
2025-02-19 11:07:41 +0100 <Athas> I'm wondering if I can adapt your Accelerate implementations into pure Haskell.
2025-02-19 11:08:34 +0100j1n37(~j1n37@user/j1n37) j1n37
2025-02-19 11:09:14 +0100j1n37(~j1n37@user/j1n37) (Read error: Connection reset by peer)
2025-02-19 11:10:17 +0100 <Inst> TINO warp/wai, right?
2025-02-19 11:11:24 +0100 <Inst> erm, there's no alternative to wai, specifically?
2025-02-19 11:12:32 +0100j1n37(~j1n37@user/j1n37) j1n37
2025-02-19 11:13:34 +0100j1n37(~j1n37@user/j1n37) (Read error: Connection reset by peer)
2025-02-19 11:14:14 +0100 <Inst> snap runs on neither warp nor wai
2025-02-19 11:17:08 +0100j1n37(~j1n37@user/j1n37) j1n37
2025-02-19 11:17:58 +0100j1n37(~j1n37@user/j1n37) (Read error: Connection reset by peer)
2025-02-19 11:19:54 +0100 <tomsmeding> Athas: that shouldn't be too difficult, actually
2025-02-19 11:20:05 +0100 <tomsmeding> also, thanks!
2025-02-19 11:20:25 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-02-19 11:21:06 +0100j1n37(~j1n37@user/j1n37) j1n37
2025-02-19 11:21:09 +0100 <tomsmeding> Athas: you forgot to update the [futhark] link in the readme
2025-02-19 11:21:48 +0100 <Athas> So I did. Thanks for noticing.
2025-02-19 11:23:47 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 252 seconds)
2025-02-19 11:23:47 +0100tnt2tnt1
2025-02-19 11:26:27 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 11:29:27 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 11:31:27 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 268 seconds)
2025-02-19 11:32:16 +0100drdo(~drdo@bl9-110-63.dsl.telepac.pt) (Quit: Ping timeout (120 seconds))
2025-02-19 11:32:53 +0100drdo(~drdo@bl9-110-63.dsl.telepac.pt) drdo
2025-02-19 11:33:53 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 248 seconds)
2025-02-19 11:34:17 +0100Inst(~Inst@user/Inst) (Remote host closed the connection)
2025-02-19 11:35:28 +0100Googulator13(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Quit: Client closed)
2025-02-19 11:35:52 +0100Googulator13(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu)
2025-02-19 11:38:06 +0100Inst(~Inst@user/Inst) Inst
2025-02-19 11:38:45 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 248 seconds)
2025-02-19 11:42:32 +0100j1n37(~j1n37@user/j1n37) (Ping timeout: 265 seconds)
2025-02-19 11:42:55 +0100j1n37(~j1n37@user/j1n37) j1n37
2025-02-19 11:43:16 +0100Googulator13(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Quit: Client closed)
2025-02-19 11:43:30 +0100Googulator13(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu)
2025-02-19 11:49:57 +0100merijn(~merijn@77.242.116.146) merijn
2025-02-19 11:52:09 +0100tessier(~tessier@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 246 seconds)
2025-02-19 11:52:30 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 11:52:36 +0100Inst(~Inst@user/Inst) (Remote host closed the connection)
2025-02-19 11:56:38 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 245 seconds)
2025-02-19 11:56:58 +0100Square2(~Square4@user/square) Square
2025-02-19 12:02:38 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 12:04:06 +0100tessier(~tessier@ec2-184-72-149-67.compute-1.amazonaws.com) tessier
2025-02-19 12:06:44 +0100xff0x(~xff0x@2405:6580:b080:900:4e6:728d:8693:dc86)
2025-02-19 12:07:34 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 272 seconds)
2025-02-19 12:08:39 +0100lol_(~lol@2603:3016:1e01:b9c0:f149:9d53:5672:9d16)
2025-02-19 12:08:40 +0100j1n37(~j1n37@user/j1n37) (Read error: Connection reset by peer)
2025-02-19 12:09:29 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-02-19 12:09:58 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 245 seconds)
2025-02-19 12:09:59 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 252 seconds)
2025-02-19 12:09:59 +0100tnt2tnt1
2025-02-19 12:11:52 +0100j1n37(~j1n37@user/j1n37) j1n37
2025-02-19 12:13:30 +0100jcarpenter2(~lol@2603:3016:1e01:b9c0:dd5c:182b:d497:5a90) (Ping timeout: 276 seconds)
2025-02-19 12:17:31 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 12:20:09 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-02-19 12:22:08 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 272 seconds)
2025-02-19 12:22:08 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 272 seconds)
2025-02-19 12:22:48 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-02-19 12:23:47 +0100merijn(~merijn@77.242.116.146) merijn
2025-02-19 12:24:55 +0100tnt1(~Thunderbi@user/tnt1) tnt1
2025-02-19 12:25:18 +0100tnt2(~Thunderbi@user/tnt1) (Ping timeout: 272 seconds)
2025-02-19 12:30:34 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 260 seconds)
2025-02-19 12:33:03 +0100merijn(~merijn@77.242.116.146) merijn
2025-02-19 12:37:20 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-02-19 12:37:20 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 272 seconds)
2025-02-19 12:37:20 +0100xff0x(~xff0x@2405:6580:b080:900:4e6:728d:8693:dc86) (Ping timeout: 272 seconds)
2025-02-19 12:37:21 +0100tnt2tnt1
2025-02-19 12:38:18 +0100Inst(~Inst@user/Inst) Inst
2025-02-19 12:40:15 +0100Googulator13(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Quit: Client closed)
2025-02-19 12:40:46 +0100Googulator13(~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu)
2025-02-19 12:41:18 +0100j1n37(~j1n37@user/j1n37) (Read error: Connection reset by peer)
2025-02-19 12:42:50 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-02-19 12:44:06 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 252 seconds)
2025-02-19 12:44:11 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 12:44:52 +0100Inst(~Inst@user/Inst) (Remote host closed the connection)
2025-02-19 12:46:11 +0100j1n37(~j1n37@user/j1n37) j1n37
2025-02-19 12:46:37 +0100tnt1(~Thunderbi@user/tnt1) tnt1
2025-02-19 12:47:28 +0100tnt2(~Thunderbi@user/tnt1) (Ping timeout: 272 seconds)
2025-02-19 12:50:33 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-02-19 12:51:12 +0100JuanDaugherty(~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org))
2025-02-19 12:51:24 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 260 seconds)
2025-02-19 12:51:36 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 244 seconds)
2025-02-19 12:52:39 +0100ash3en(~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en
2025-02-19 12:53:29 +0100ash3en(~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Client Quit)
2025-02-19 12:53:30 +0100tnt1(~Thunderbi@user/tnt1) tnt1
2025-02-19 12:54:33 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 12:55:24 +0100Inst(~Inst@user/Inst) Inst
2025-02-19 12:55:29 +0100tnt2(~Thunderbi@user/tnt1) (Ping timeout: 260 seconds)
2025-02-19 12:57:23 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-02-19 12:58:24 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 260 seconds)
2025-02-19 12:58:24 +0100tnt2tnt1
2025-02-19 12:59:05 +0100CiaoSen(~Jura@ip-037-201-240-075.um10.pools.vodafone-ip.de) CiaoSen
2025-02-19 12:59:17 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 248 seconds)
2025-02-19 13:00:27 +0100cheater_(~Username@user/cheater) cheater
2025-02-19 13:01:53 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 13:02:50 +0100DigitteknohippieDigit
2025-02-19 13:02:54 +0100cheater(~Username@user/cheater) (Ping timeout: 276 seconds)
2025-02-19 13:03:03 +0100cheater_cheater
2025-02-19 13:05:16 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 13:05:40 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 265 seconds)
2025-02-19 13:05:44 +0100comerijn(~merijn@77.242.116.146) merijn
2025-02-19 13:06:08 +0100ubert(~Thunderbi@2a02:8109:ab8a:5a00:fee4:2960:1510:cb37) ubert
2025-02-19 13:06:52 +0100tnt1(~Thunderbi@user/tnt1) tnt1
2025-02-19 13:07:28 +0100Inst(~Inst@user/Inst) (Remote host closed the connection)
2025-02-19 13:08:17 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 248 seconds)
2025-02-19 13:09:02 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2025-02-19 13:09:33 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 245 seconds)
2025-02-19 13:12:20 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 252 seconds)
2025-02-19 13:12:40 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-02-19 13:13:06 +0100 <ski> tomsmeding,dminuoso : "it's rather that let evaluates them concurrently" -- not concurrently, but collaterally (it's the same in Scheme, Common Lisp). e.g. `(let ((a b) (b (+ a b))) ..a..b..)' amounts basically to `do (a,b) <- pure (b,a + b); ..a..b..', or `(\(a,b) -> ..a..b..) (b,a + b)' if you prefer
2025-02-19 13:13:22 +0100 <ski> while `(let* ((a b) (b (+ a b))) ..a..b..)' would amount to `do a <- pure b; b <- pure (a + b); ..a..b..' or `(\a -> (\b -> ..a..b..) (a + b)) b', sequential binding
2025-02-19 13:13:26 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 252 seconds)
2025-02-19 13:13:26 +0100tnt2tnt1
2025-02-19 13:13:38 +0100 <ski> iirc, Scheme has unspecified evaluation order of the operator and operands in a combination ("function call"), even allowing concurrent evaluation, as long as it is serializable
2025-02-19 13:13:49 +0100 <ski> (see e.g. "Concurrent and serializable computations - and the evaluation order for function's arguments and the body" by Oleg at <https://okmij.org/ftp/Computation/serialization.html>,"4.1.3 Procedure Calls" in the R⁵RS at <https://conservatory.scheme.org/schemers/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html#%_sec_4.1.3>)
2025-02-19 13:13:55 +0100 <ski> so .. the collateral (vs. sequential) here refers to scoping, not to concurrency
2025-02-19 13:14:08 +0100 <ski> "lisp is way more symbolic in the sense that `x` is not a reference to a particular thing","It's more like in lambda calculus where `x` is just `x`." -- no, not really. quoting, for staged programming, meta-programming, macros, is a different thing. obviously you can implement "symbolic evaluators" (partial evaluators, program specializers), just like you can, in Haskell
2025-02-19 13:14:15 +0100 <ski> oh, and dynamic scoping vs. static/lexical scoping is yet another thing entirely
2025-02-19 13:14:20 +0100 <ski> "What Im saying is, is there a big meaningful difference between (+ 5 x) and '(+ 5 x) ?" -- the latter is just a data structure, involving a symbol (not any variable at all)
2025-02-19 13:14:40 +0100jespada(~jespada@2800:a4:22b9:6800:90a2:b8c6:2c24:d97d) jespada
2025-02-19 13:15:10 +0100 <tomsmeding> ski: that makes sense!
2025-02-19 13:15:43 +0100 <tomsmeding> so let vs let* is about scoping, not about evaluation? And any differences in evaluation are just corollary effects from evaluation order of unsequenced things being unspecified in general anyway?
2025-02-19 13:16:25 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-02-19 13:17:02 +0100 <ski> well, `let*' also specifies sequential evaluation
2025-02-19 13:17:18 +0100 <ski> (because of expanding into nested lambda applications)
2025-02-19 13:17:38 +0100 <tomsmeding> as in, it would not be allowed to postpone evaluation until the variable `a' is used in the right-hand side of `b', for example?
2025-02-19 13:17:47 +0100 <ski> but otherwise, yes
2025-02-19 13:17:53 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 245 seconds)
2025-02-19 13:17:55 +0100 <tomsmeding> because of the scoping, I don't see what other way you could _not_ have sequential evaluation there
2025-02-19 13:18:10 +0100 <ski> not in Scheme, Common Lisp, no
2025-02-19 13:18:20 +0100 <tomsmeding> they are all strict languages, right?
2025-02-19 13:18:34 +0100 <ski> for a non-standard non-strict Scheme variant, yes
2025-02-19 13:18:41 +0100 <ski> yes
2025-02-19 13:18:46 +0100 <tomsmeding> right
2025-02-19 13:19:10 +0100 <tomsmeding> yeah you can always interpret existing syntax differently if you want, but then you get a different programming languaeg
2025-02-19 13:19:28 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 13:19:40 +0100 <ski> (some texts that play around with implementing Scheme or Lisp interpreters, meta-circularly, does have a non-strict version as a variant)
2025-02-19 13:20:42 +0100 <ski> Lazy ML was a lazy version of the usual strict ML. iirc, HBC (first Haskell compiler) was implemented in it
2025-02-19 13:20:48 +0100 <tomsmeding> but even in a non-strict variant, you can still separate that from the scoping difference of let vs let*, and the evaluation strategy + the scoping is together sufficient to determine what happens, I think
2025-02-19 13:20:58 +0100 <ski> (where is augustss/lennart when you need him !?)
2025-02-19 13:21:19 +0100tnt2(~Thunderbi@user/tnt1) (Ping timeout: 260 seconds)
2025-02-19 13:22:02 +0100 <tomsmeding> i.e. "well, `let*' also specifies sequential evaluation" is redundant if you have the scoping property together with the overall strict evaluation strategy
2025-02-19 13:22:47 +0100 <ski> yes. i meant that that "specified sequential evaluation" is a derived consequence of the latter
2025-02-19 13:22:54 +0100 <tomsmeding> right
2025-02-19 13:23:10 +0100 <tomsmeding> cool, the magic level decreased even further
2025-02-19 13:25:35 +0100 <ski> `let' and `let*' (and a bunch of other special forms) are specified as "derived forms" (macros), in the R⁵RS, <https://conservatory.scheme.org/schemers/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html#%_sec_4.2>,<https://conservatory.scheme.org/schemers/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html#%_sec_7.3>
2025-02-19 13:28:19 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 260 seconds)
2025-02-19 13:31:30 +0100 <ski> HBC : <https://wiki.haskell.org/Implementations#HBI_and_HBC.2C_Chalmers.27_Haskell_Interpreter_and_Compiler>,<http://web.archive.org/web/20090815181116/http://www.cs.chalmers.se/~augustss/hbc/hbc.html>,<https://web.archive.org/web/20100526120524/http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haske…>,<https://archive.org/details/haskell-b-compiler>
2025-02-19 13:32:00 +0100 <ski> `hbc-library' <https://www.altocumulus.org/~hallgren/untested/Source_code/old/>,`hbcmake' <https://cth.altocumulus.org/~hallgren/software.html>
2025-02-19 13:33:44 +0100__monty__(~toonn@user/toonn) toonn
2025-02-19 13:34:33 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 13:34:38 +0100JeremyB99(~JeremyB99@2607:ac80:407:7:87ef:122c:2b31:8cb8)
2025-02-19 13:34:39 +0100JeremyB99(~JeremyB99@2607:ac80:407:7:87ef:122c:2b31:8cb8) (Read error: Connection reset by peer)
2025-02-19 13:34:58 +0100Inst(~Inst@user/Inst) Inst
2025-02-19 13:36:10 +0100 <Inst> also, the reason we use monads instead of monadoids is because pure / return is still a useful end to a monad block, no? left identity might have niche uses, but right identity remains eminently useful
2025-02-19 13:37:10 +0100__monty__(~toonn@user/toonn) (Client Quit)
2025-02-19 13:39:00 +0100__monty__(~toonn@user/toonn) toonn
2025-02-19 13:39:08 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 244 seconds)
2025-02-19 13:39:12 +0100 <Inst> there probably is a case wherein left identity is highly useful, though; ugh
2025-02-19 13:41:32 +0100xff0x(~xff0x@2405:6580:b080:900:a030:6365:43f5:43dc)
2025-02-19 13:42:34 +0100random-jellyfish(~developer@user/random-jellyfish) random-jellyfish
2025-02-19 13:42:54 +0100 <ski> left identity is used when refactoring
2025-02-19 13:45:41 +0100 <Inst> are there cases where foo <- pure bar is better than let foo = bar?
2025-02-19 13:45:44 +0100 <ski> you have `foo x y z = do ...; return (...)', and you want to inline that into `do ...; t <- foo a b c; ...'. to do that, in the obvious way, you need the associative law, and the left identify law, getting `do ...; let {x = a,; y = b; z = c}; ...; let {t = ...}; ...; ' (assuming any variable clashes have been dealt with, by renaming beforehand)
2025-02-19 13:46:30 +0100 <ski> when `foo' is a refutable pattern, and you want to implicitly invoke `fail' in `MonadFail'
2025-02-19 13:46:40 +0100 <Inst> yeah, that was brought up last time
2025-02-19 13:46:43 +0100 <ski> or when `foo' shadows some variables in `bar'
2025-02-19 13:47:03 +0100comerijn(~merijn@77.242.116.146) (Ping timeout: 245 seconds)
2025-02-19 13:47:10 +0100 <ski> the former also forces `foo' to be monomorphic
2025-02-19 13:47:11 +0100 <haskellbridge> <Morj> Re foo <- pure bar: this way you can actually shadow variables instead of creating recursive bindings. Similar to ocaml/rust style of doing "let a = expr b in let a = other a in ..."
2025-02-19 13:47:25 +0100 <Inst> you can do that with let as well
2025-02-19 13:47:30 +0100 <ski> no
2025-02-19 13:47:36 +0100 <ski> `let' creates recursive bindings
2025-02-19 13:47:49 +0100 <Inst> ah, yes, you'd need an intermediary
2025-02-19 13:47:50 +0100 <ski> > let x = 1 in let x = x + 1 in x
2025-02-19 13:47:52 +0100 <lambdabot> *Exception: <<loop>>
2025-02-19 13:48:11 +0100 <ski> > do x <- pure 1; x <- pure (x + 1); [x]
2025-02-19 13:48:12 +0100 <lambdabot> [2]
2025-02-19 13:48:23 +0100merijn(~merijn@77.242.116.146) merijn
2025-02-19 13:48:54 +0100 <ski> > [x | x <- [1],x <- [x + 1]]
2025-02-19 13:48:55 +0100 <Inst> > let foo = 1 in let bar = foo in let foo = bar + 1 in foo
2025-02-19 13:48:55 +0100 <lambdabot> [2]
2025-02-19 13:48:56 +0100 <lambdabot> 2
2025-02-19 13:49:04 +0100 <ski> yes
2025-02-19 13:49:10 +0100 <Inst> that works, but is way, way uglier
2025-02-19 13:49:17 +0100 <haskellbridge> <Morj> Holy hell, I didn't know you can do it in list comprehensions
2025-02-19 13:49:38 +0100 <Inst> but iirc shadowing is idiomatic in rust, not in haskell
2025-02-19 13:49:43 +0100 <ski> it's rather obvious, from the list comprehension expansion transformations
2025-02-19 13:49:46 +0100 <Inst> Morj: also implies -XMonadComprehensions ;)
2025-02-19 13:50:17 +0100JeremyB99(~JeremyB99@2607:ac80:407:7:87ef:122c:2b31:8cb8)
2025-02-19 13:50:21 +0100 <haskellbridge> <Morj> Sometimes I wish it were idiomatic here. I have a lot of code like "let a = ...; a' = ... a; a'' = ... a' etc"
2025-02-19 13:52:12 +0100JeremyB99(~JeremyB99@2607:ac80:407:7:87ef:122c:2b31:8cb8) (Read error: Connection reset by peer)
2025-02-19 13:53:41 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-19 13:54:45 +0100 <Inst> thanks re ski
2025-02-19 13:54:52 +0100 <Inst> and Morj
2025-02-19 13:55:42 +0100 <ski> in SML, `let val a = b and b = a + b in ..a..b.. end' is collateral binding (cf. `let' vs. `let*' above), while `let val a = b; val b = a + b in ..a..b.. end' is sequential binding. recursive binding (corresponding to `letrec' in Lisps) is `let val rec f = ... and g = ... in ..f..g.. end'
2025-02-19 13:56:45 +0100 <ski> (the bodies of `f' and `g' here must be syntactically values, lambda abstractions basically)
2025-02-19 13:57:02 +0100 <tomsmeding> for the `let rec' case?
2025-02-19 13:57:08 +0100 <ski> yes
2025-02-19 13:57:54 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 248 seconds)
2025-02-19 13:58:35 +0100 <ski> some Scheme systems also have a `letrec*' that guarantees sequential order of evaluation (but recursive scoping) of the definientia
2025-02-19 13:59:27 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 14:01:18 +0100akegalj(~akegalj@89-172-194-52.adsl.net.t-com.hr) (Ping timeout: 268 seconds)
2025-02-19 14:01:47 +0100 <ski> Mercury has a "State variable" notation, where you can type `foo(...,!X),bar(!X,...),baz(...,!X...)', meaning `foo(...,!.X,!:X),bar(!.X,!:X,...),baz(...,!.X,!:X,...)', which basically amounts to `foo(...,X0,X1),bar(X1,X2,...),baz(...,X2,X3,...)', where `X0' is the initial value of `!X', and `X3' is the final value of `!X'. see
2025-02-19 14:01:52 +0100 <ski> <https://www.mercurylang.org/information/doc-latest/mercury_ref/Clauses.html#State-variables>
2025-02-19 14:02:24 +0100 <ski> (so it generates a sequence of variables for you, basically)
2025-02-19 14:03:06 +0100 <haskellbridge> <Morj> That's a cool feature
2025-02-19 14:04:19 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 260 seconds)
2025-02-19 14:05:06 +0100Inst(~Inst@user/Inst) (Remote host closed the connection)
2025-02-19 14:05:32 +0100AlexNoo_AlexNoo
2025-02-19 14:06:17 +0100atwm(~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm
2025-02-19 14:09:18 +0100skiidly wonders what could be a reasonable concrete syntax for sequential vs. collateral binding, in Haskell
2025-02-19 14:11:12 +0100 <ski> there already is `do rec {x <- ..y..; y <- ..x..}; ..x..y..'
2025-02-19 14:14:14 +0100Inst(~Inst@user/Inst) Inst
2025-02-19 14:15:01 +0100skinotes that `rec' doesn't work in list comprehensions, even with `MonadComprehensions' enabled
2025-02-19 14:16:32 +0100 <ski> .. i guess one could imagine `seq {...}' and `par {...}', although that'd snarf the names of those standard functions
2025-02-19 14:16:45 +0100 <Inst> is this explanation of why monads instead of monadoids in the moggi papers?
2025-02-19 14:17:09 +0100 <ski> `let par {a = b; b = a + b} in ..a..b..' vs. `let seq {a = b; b = a + b} in ..a..b..'
2025-02-19 14:17:11 +0100 <haskellbridge> <Morj> Does using var` lead to any ambiguities? To get "let a` = foo; a` = bar a`; a` = qux a` in ..." - mercury-style state variables
2025-02-19 14:17:30 +0100 <ski> which, Inst ?
2025-02-19 14:17:38 +0100 <haskellbridge> <Morj> I like that it's similar to using a front-tick which is already idiomatic
2025-02-19 14:18:12 +0100 <Inst> the one for left identity, at least, and implicitly the right identity to permit a return through a neutral element
2025-02-19 14:18:43 +0100sawilagar(~sawilagar@user/sawilagar) sawilagar
2025-02-19 14:18:45 +0100ski's forgotten what "monadoids" refer to
2025-02-19 14:18:55 +0100cstslrdg^(~cstslrdg@108.192.66.114)
2025-02-19 14:19:15 +0100 <Inst> i've forgotten if i used the term correctly
2025-02-19 14:19:24 +0100 <ski> right identity is for getting "monadic tail invokation"
2025-02-19 14:20:52 +0100 <Inst> i mean associative law of functor join without identity laws of pure/eta
2025-02-19 14:22:27 +0100mange(~user@user/mange) (Quit: Zzz...)
2025-02-19 14:22:32 +0100 <Inst> although tbh you CAN avoid right identity to some extent, simply by using the last monadic element, then <$ the returned element into it
2025-02-19 14:22:45 +0100 <Inst> *returned value
2025-02-19 14:24:56 +0100Inst(~Inst@user/Inst) (Remote host closed the connection)
2025-02-19 14:25:34 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2025-02-19 14:27:48 +0100akegalj(~akegalj@141-136-246-173.dsl.iskon.hr)