| 2025-12-28 00:01:15 +0100 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2025-12-28 00:05:03 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-12-28 00:06:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 00:11:06 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 00:14:36 +0100 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-12-28 00:18:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 00:18:19 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds) |
| 2025-12-28 00:23:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-12-28 00:26:43 +0100 | vetkat | (~vetkat@user/vetkat) (Read error: Connection reset by peer) |
| 2025-12-28 00:27:07 +0100 | vetkat | (~vetkat@user/vetkat) vetkat |
| 2025-12-28 00:35:11 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 00:36:32 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2025-12-28 00:39:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-28 00:50:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 00:55:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-28 01:01:15 +0100 | hsw | (~hsw@112-104-86-252.adsl.dynamic.seed.net.tw) (Ping timeout: 240 seconds) |
| 2025-12-28 01:06:26 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 01:11:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-28 01:11:34 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 246 seconds) |
| 2025-12-28 01:19:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 01:24:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-28 01:33:04 +0100 | <haskellbridge> | <Liamzee> apparently apple silicon (and psosibly modern ARM in general) is designed to be very resistant to segfaults; double free would throw an error, but not a segfault |
| 2025-12-28 01:33:29 +0100 | <haskellbridge> | <Liamzee> we ended up having to point a pointer at kernel memory just to trigger a segfault |
| 2025-12-28 01:34:28 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 01:37:06 +0100 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) (Quit: ZNC 1.10.1+deb1 - https://znc.in) |
| 2025-12-28 01:39:21 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 01:50:16 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 01:54:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-28 01:58:18 +0100 | collide2954 | (~collide29@user/collide2954) (Quit: The Lounge - https://thelounge.chat) |
| 2025-12-28 02:02:08 +0100 | <geekosaur> | there are malloc libraries which do that (it's not up to the hardware) |
| 2025-12-28 02:03:06 +0100 | <geekosaur> | which doesn't mean you can't segfault on them, just that common errors like double free, use after free, and overreading/writing a block are detected and reported instead of corrupting memory or crashing |
| 2025-12-28 02:04:57 +0100 | <geekosaur> | they're really nice in conjunction with debuggers because you can break on the error entry point and catch things like that immediately instead of after something reveals memory corruption |
| 2025-12-28 02:06:04 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 02:07:05 +0100 | <geekosaur> | (that said, I think memcheck has superseded all of them…) |
| 2025-12-28 02:10:21 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 02:11:58 +0100 | <int-e> | presumably this is about ARM's "pointer authentication" feature |
| 2025-12-28 02:12:50 +0100 | Hafydd | (~Hafydd@user/hafydd) (Quit: WeeChat 4.8.1) |
| 2025-12-28 02:14:10 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-12-28 02:15:46 +0100 | omidmash2 | (~omidmash@user/omidmash) omidmash |
| 2025-12-28 02:16:19 +0100 | collide2954 | (~collide29@user/collide2954) collide2954 |
| 2025-12-28 02:17:35 +0100 | omidmash | (~omidmash@user/omidmash) (Ping timeout: 244 seconds) |
| 2025-12-28 02:17:35 +0100 | omidmash2 | omidmash |
| 2025-12-28 02:18:55 +0100 | hsw | (~hsw@112-104-86-252.adsl.dynamic.seed.net.tw) hsw |
| 2025-12-28 02:19:21 +0100 | hsw_ | (~hsw@112-104-86-252.adsl.dynamic.seed.net.tw) hsw |
| 2025-12-28 02:19:36 +0100 | hsw_ | (~hsw@112-104-86-252.adsl.dynamic.seed.net.tw) (Remote host closed the connection) |
| 2025-12-28 02:21:29 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 02:24:44 +0100 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2025-12-28 02:24:56 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2025-12-28 02:28:13 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-28 02:31:49 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 264 seconds) |
| 2025-12-28 02:33:34 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-12-28 02:38:57 +0100 | Hafydd | (~Hafydd@user/hafydd) Hafydd |
| 2025-12-28 02:39:32 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 02:40:22 +0100 | Hafydd | (~Hafydd@user/hafydd) (Read error: Connection reset by peer) |
| 2025-12-28 02:40:28 +0100 | Hafydd_ | (~Hafydd@user/hafydd) Hafydd |
| 2025-12-28 02:43:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-28 02:45:14 +0100 | Tuplanolla | (~Tuplanoll@88-114-88-95.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-12-28 02:49:35 +0100 | annamalai | (~annamalai@157.32.142.174) (Ping timeout: 240 seconds) |
| 2025-12-28 02:55:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 03:00:03 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 03:10:48 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 03:14:10 +0100 | Hafydd_ | (~Hafydd@user/hafydd) (Quit: WeeChat 4.8.1) |
| 2025-12-28 03:15:35 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-28 03:22:05 +0100 | Hafydd | (~Hafydd@user/hafydd) Hafydd |
| 2025-12-28 03:26:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 03:27:49 +0100 | annamalai | (~annamalai@157.33.228.123) annamalai |
| 2025-12-28 03:31:28 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 03:42:36 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 03:47:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-28 03:53:47 +0100 | acidjnk | (~acidjnk@p200300d6e7171962095fe0be59254d80.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2025-12-28 03:58:23 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 04:03:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-12-28 04:05:02 +0100 | op_4 | (~tslil@user/op-4/x-9116473) (Remote host closed the connection) |
| 2025-12-28 04:05:39 +0100 | op_4 | (~tslil@user/op-4/x-9116473) op_4 |
| 2025-12-28 04:14:10 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 04:18:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-28 04:22:03 +0100 | ttybitnik | (~ttybitnik@user/wolper) (Quit: Fading out...) |
| 2025-12-28 04:29:57 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 04:35:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 04:40:15 +0100 | <Leary> | "variance introduced by outliers: -9223372036854775808% (severely inflated)" |
| 2025-12-28 04:40:19 +0100 | <Leary> | Thanks, criterion. |
| 2025-12-28 04:45:46 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 04:50:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-28 04:50:46 +0100 | Hafydd | (~Hafydd@user/hafydd) (Quit: WeeChat 4.8.1) |
| 2025-12-28 05:01:32 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 05:04:27 +0100 | <monochrom> | That number looks awfully familar. |
| 2025-12-28 05:06:11 +0100 | <monochrom> | > 2^63 |
| 2025-12-28 05:06:12 +0100 | <lambdabot> | 9223372036854775808 |
| 2025-12-28 05:06:16 +0100 | <monochrom> | That. :) |
| 2025-12-28 05:06:29 +0100 | <Leary> | > minBound :: Int |
| 2025-12-28 05:06:30 +0100 | <lambdabot> | -9223372036854775808 |
| 2025-12-28 05:06:37 +0100 | <Leary> | Or that. |
| 2025-12-28 05:07:52 +0100 | <monochrom> | But if variance is negative, that's severely deflated or imploded, not inflated. >:) |
| 2025-12-28 05:08:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-28 05:14:21 +0100 | <Leary> | (turns out I'd forgotten to wait on forked threads, so criterion was measuring a load of nonsense) |
| 2025-12-28 05:15:25 +0100 | <monochrom> | oh heh |
| 2025-12-28 05:19:35 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 05:24:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-28 05:28:25 +0100 | Hafydd | (~Hafydd@user/hafydd) Hafydd |
| 2025-12-28 05:35:22 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 05:40:07 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-28 05:49:31 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: bbl) |
| 2025-12-28 05:51:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 05:55:39 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-12-28 06:01:16 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 06:01:20 +0100 | iqubic | (~sophia@2601:602:9203:1660:c40f:f996:91cc:d34) iqubic |
| 2025-12-28 06:03:27 +0100 | <iqubic> | I have a Haskell design question. How do I decide if I should make a typeclass to describe a particular constraint or just use and pass around a record of functions. |
| 2025-12-28 06:05:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-28 06:29:23 +0100 | <haskellbridge> | <slack1256> Iqubic: the standard answer some years ago was that if you could give "algebraic laws" relating the operations between themselves or super classes you were in the right path |
| 2025-12-28 06:29:31 +0100 | spew | (~spew@user/spew) (Quit: nyaa~) |
| 2025-12-28 06:30:52 +0100 | <haskellbridge> | <slack1256> The second case was that the class admitted obvious instances. For example show and read. Foldable was obvious even if kind of adhoc because `toList` was the only real method and everything else was a more efficient way to avoid the conversion to lists. |
| 2025-12-28 06:31:18 +0100 | <ski> | does the type determine a canonical instance ? or would it make sense to want to pass different records, at different times, for the same type ? |
| 2025-12-28 06:31:31 +0100 | <haskellbridge> | <slack1256> In summary, you had abstraction power via laws or you had a simple model ln the instances |
| 2025-12-28 06:32:22 +0100 | <ski> | yea, you also most likely should not be making a type class, unless you already have at least two different instances in mind |
| 2025-12-28 06:32:32 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 06:36:37 +0100 | <iqubic> | In the thing that I'm modelling, the same type could very easily have different implementations. And I don't want to jump through newtype wrappers like Sum and Product for the two different Monoids over integers. |
| 2025-12-28 06:36:56 +0100 | <iqubic> | The more I actually think about this, the more it makes sense to use a record of functions. |
| 2025-12-28 06:37:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-28 06:37:35 +0100 | <haskellbridge> | <slack1256> Record of functions can be used everywhere else. Most importantly where the provenance is a deciding factor on what the functions should do, not just the type. This is a fine concept, these records of functions are modules as ocaml sense |
| 2025-12-28 06:39:17 +0100 | <iqubic> | Essentially, I'm trying to model simple combinatorial games like "nim" where I can write a function like "nextMoves :: a -> [a]", but then I realized that different games might have the type for the state variable. |
| 2025-12-28 06:39:28 +0100 | <ski> | yea, sounds like record of operations is more sensible, then |
| 2025-12-28 06:40:43 +0100 | rekahsoft | (~rekahsoft@70.51.99.245) (Remote host closed the connection) |
| 2025-12-28 06:40:46 +0100 | <ski> | btw, sometimes it makes sense to make a function from a record-of-operations, to another (possibly existential) record-of-operations. this being one way to do something similar to the parameterized modules in the module system of the MLs (SML,OCaml) (cf. Backpack) |
| 2025-12-28 06:41:11 +0100 | <iqubic> | Yeah, I get what you mean. |
| 2025-12-28 06:41:16 +0100 | rekahsoft | (~rekahsoft@70.51.99.245) rekahsoft |
| 2025-12-28 06:41:29 +0100 | <haskellbridge> | <slack1256> I liked backpack... |
| 2025-12-28 06:42:16 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 06:42:45 +0100 | <ski> | you'd open the returned record in a scope, bringing the skolem into scope, and then use the operations directly. this is a way to do Abstract Data Types |
| 2025-12-28 06:43:03 +0100 | <iqubic> | In the basic game of "nim" you have a bunch of distinct piles, and each pile has a bunch of objects. Players take turns removing any amount of objects from a single pile. The winner is the player to make the last valid move. In other words, if you can't make a move, you lose. |
| 2025-12-28 06:43:34 +0100 | <ski> | (unlike doing OO via existentials, where you'd open the record, apply an operation to the current state, and then rewrap new state with the operations again, every time) |
| 2025-12-28 06:44:52 +0100 | <iqubic> | I can model this as with a state of [Int]. But if I want a similar game, but with the constraint of "after each move, the piles must all have a coprime number of objects", that's also a state of type "[Int]" but a different "nextMoves :: a -> [a]" function. |
| 2025-12-28 06:45:16 +0100 | <iqubic> | BTW, Conway et al. call that version "prim", I think. |
| 2025-12-28 06:45:41 +0100 | <haskellbridge> | <slack1256> These combinatorial games are not related in anyway right? They just happen to implement a nextMoves function, the lack of laws pushes you to record of functions |
| 2025-12-28 06:46:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-28 06:46:56 +0100 | <iqubic> | Yeah, correct. |
| 2025-12-28 06:47:12 +0100 | <iqubic> | It's mainly just the "nextMoves" function that relates them. |
| 2025-12-28 06:47:24 +0100 | <iqubic> | And I have no laws, because I have just the one function. |
| 2025-12-28 06:47:42 +0100 | <haskellbridge> | <slack1256> Right, which is also a non obvious function |
| 2025-12-28 06:48:54 +0100 | <ski> | presumably iterating `nextMoves' is meant to lead to a tree where no path is infinite ? |
| 2025-12-28 06:49:23 +0100 | <iqubic> | Correct. I'm only interested in finite games here. |
| 2025-12-28 06:49:33 +0100 | <ski> | some kind of well-founded order thing |
| 2025-12-28 06:51:06 +0100 | <haskellbridge> | <slack1256> Multiple implementations for that in no way related to the days structure to give an instance |
| 2025-12-28 06:51:12 +0100 | <ski> | all the outputs of `nextMoves' are presumably strictly less than the input |
| 2025-12-28 06:51:17 +0100 | <iqubic> | Basically, I've been reading the book "Winning Ways For Your Mathematical Plays" by Berlekamp, Guy, and Conway, and I want to implement some of these things in Haskell. |
| 2025-12-28 06:51:17 +0100 | <haskellbridge> | <slack1256> Data* |
| 2025-12-28 06:51:33 +0100 | <iqubic> | ski: For some definition of "strictly less", yeah. |
| 2025-12-28 06:52:02 +0100 | <ski> | yea, some arbitrary partial order |
| 2025-12-28 06:52:30 +0100 | <ski> | (that is well-founded) |
| 2025-12-28 06:52:47 +0100 | <iqubic> | But my main question was "Do I model this as a typeclass with one function or a record of one function"? |
| 2025-12-28 06:53:12 +0100 | <ski> | yep. the latter seems more reasonable |
| 2025-12-28 06:53:45 +0100 | <ski> | (you could put the order relation as a second operation in the record .. but perhaps you have no use for it, at all, at run-time) |
| 2025-12-28 06:54:08 +0100 | <iqubic> | I agree. Because different games with completely different rules might want to use similar state representations. |
| 2025-12-28 06:54:30 +0100 | <iqubic> | ski: Currently my planned API doesn't need a way to tell which states are smaller. |
| 2025-12-28 06:55:01 +0100 | <ski> | in any case, even without an explicit order relation (computationally irrelevant or not), you should still be able to express a well-foundedness law for `nextMoves' |
| 2025-12-28 06:55:20 +0100 | <ski> | (iow, you don't need more than one operation, to be able to have a law) |
| 2025-12-28 06:55:43 +0100 | <iqubic> | What do you mean by well-foundedness? |
| 2025-12-28 06:58:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 06:58:38 +0100 | <ski> | for a strict order relation `<', a property like `forall P. (forall x. (forall y. y < x -> P y) -> P x) -> forall x. P x'. if we were talking about natural numbers, this would be called "strong induction" : you can prove a property `P' holds for all `x', if you can prove it holds for all `x', under the assumption it holds for all `y' that are strictly less than `x' |
| 2025-12-28 06:59:14 +0100 | <iqubic> | Right I see. |
| 2025-12-28 07:00:53 +0100 | <ski> | in terms of `nextMoves', instead of `forall y. y < x -> P y', we'd say `forall y. elem y (nextMoves x) = True -> P y'. iow, assuming that it holds for all the possible next states, it should be able to show it holds for the current state |
| 2025-12-28 07:02:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-12-28 07:02:39 +0100 | <iqubic> | forall a. let a' = nextMoves a in all [ length (nextMoves opt) < length a' | opt <- nextMoves a] |
| 2025-12-28 07:02:51 +0100 | <iqubic> | Or something like that. |
| 2025-12-28 07:03:27 +0100 | <iqubic> | Basically, if you keep iterating nextMoves function, you should keep getting less and less options. |
| 2025-12-28 07:03:55 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 244 seconds) |
| 2025-12-28 07:07:06 +0100 | <ski> | not necessarily |
| 2025-12-28 07:08:21 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2025-12-28 07:08:22 +0100 | <ski> | a tree that at each node at depth `n' has either zero or `n' branches of that node could still be well-founded |
| 2025-12-28 07:09:17 +0100 | <ski> | the important part is that each state is getting closer to a minimal element (a leaf, one which has zero successors), on each step |
| 2025-12-28 07:09:53 +0100 | <ski> | you could have the branching explode, and still have finite depth for every path |
| 2025-12-28 07:10:16 +0100 | <iqubic> | Yeah. But in my case, I want you to always have strictly less moves as you go along. That's the main case I'm interested in exploring. |
| 2025-12-28 07:10:47 +0100 | <ski> | (there's not even a need for the branching to be finite, it could still be well-founded. although, possibly, in your case, you're only interested in finite branching) |
| 2025-12-28 07:11:02 +0100 | <ski> | ah, okay |
| 2025-12-28 07:13:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 07:18:24 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-28 07:29:12 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 07:34:07 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-28 07:35:20 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:7842:6802:4767:2e5b) (Read error: Connection reset by peer) |
| 2025-12-28 07:36:46 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:7842:6802:4767:2e5b) synchromesh |
| 2025-12-28 07:40:06 +0100 | <iqubic> | Essentially, if a level of my tree has N members, then all children there should have strictly less than N descendants, except for the root. |
| 2025-12-28 07:40:54 +0100 | <iqubic> | Except, it's more like a DAG, because there might be multiple possible ways to get from the current state to some future state. |
| 2025-12-28 07:42:24 +0100 | <iqubic> | But this mathematical theory has little to do with Haskell at this point and I have gotten my orginal design question answered already. |
| 2025-12-28 07:45:19 +0100 | <hololeap> | are there any language extensions now days that can let you write a Functor instance for Set? some way to inject a constraint requirement into an existing function, or something? |
| 2025-12-28 08:02:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 08:06:57 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 08:13:20 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-12-28 08:18:05 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 08:23:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-12-28 08:29:18 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-12-28 08:31:12 +0100 | sroso | (~sroso@user/SrOso) (Quit: Leaving :)) |
| 2025-12-28 08:33:52 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 08:38:22 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 08:45:32 +0100 | <[exa]> | hololeap: you can wrap the set in a newtype that imposes the constraint, with similar tradeoffs like with other newtype wraps (inconvenient but coerces well) and typeclass constraints on data types (generally hated) |
| 2025-12-28 08:49:00 +0100 | <[exa]> | iqubic: people usually have these "operation records" for various backend implementations for whatever, e.g. here: https://hackage-content.haskell.org/package/tls-2.1.13/docs/Network-TLS.html#t:Backend or here: https://hackage.haskell.org/package/selda-0.5.2.0/docs/Database-Selda-Backend.html#t:SeldaBackend . TBH quite easy to go that way, and very easy to slap on a typeclass later, in case you |
| 2025-12-28 08:49:02 +0100 | <[exa]> | decide you want to infer which backend to use where. |
| 2025-12-28 08:49:15 +0100 | <hololeap> | hm, ok. I was looking into a different instance of Apply for Map (different than the one defined in semigroupoids) and ultimately it requires (Ord k, Semigroup a) => Map k a |
| 2025-12-28 08:49:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 08:50:04 +0100 | <hololeap> | but Apply is a class for Type -> Type |
| 2025-12-28 08:50:19 +0100 | <[exa]> | hololeap: why though (kinda curious, and also usually this has been a common instance of xyz issues) |
| 2025-12-28 08:51:15 +0100 | <hololeap> | mostly just out of curiosity. the current Apply instance feels very niche since it uses Map.intersectionWith under the hood |
| 2025-12-28 08:53:26 +0100 | <hololeap> | I was looking into an instance that would use something like Map.unionWith (<>) |
| 2025-12-28 08:53:39 +0100 | <hololeap> | though not exactly that |
| 2025-12-28 08:53:47 +0100 | <Leary> | That sounds like `Semigroup` instance instead. |
| 2025-12-28 08:53:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 08:54:39 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 260 seconds) |
| 2025-12-28 08:55:04 +0100 | <[exa]> | hololeap: that can't do applicative though, right? (you'd need a default function and default parameter) |
| 2025-12-28 08:55:26 +0100 | <hololeap> | right, Apply is Applicative sans `pure`, |
| 2025-12-28 08:55:30 +0100 | <[exa]> | so yeah that would be a (specialized) semigroup |
| 2025-12-28 08:55:47 +0100 | <hololeap> | just the <*> part of Applicative |
| 2025-12-28 08:55:50 +0100 | <[exa]> | no in this case even `ap` would require the defaults |
| 2025-12-28 08:56:47 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2025-12-28 08:57:06 +0100 | <hololeap> | anyway, this wasn't really a problem I needed to solve, just an exploration of ideas |
| 2025-12-28 08:58:58 +0100 | <hololeap> | @hackage quickcheck-classes -- makes it easy to verify the Apply laws |
| 2025-12-28 08:58:58 +0100 | <lambdabot> | https://hackage.haskell.org/package/quickcheck-classes -- makes it easy to verify the Apply laws |
| 2025-12-28 09:00:01 +0100 | tt1231607 | (~tt1231@75.185.104.199) (Quit: The Lounge - https://thelounge.chat) |
| 2025-12-28 09:03:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 09:05:33 +0100 | tt1231607 | (~tt1231@75.185.104.199) tt1231 |
| 2025-12-28 09:08:07 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-28 09:19:04 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 09:25:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-28 09:37:04 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |