Newest at the top
| 2025-12-28 09:00:01 +0100 | tt1231607 | (~tt1231@75.185.104.199) (Quit: The Lounge - https://thelounge.chat) |
| 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 08:58:58 +0100 | <hololeap> | @hackage quickcheck-classes -- makes it easy to verify the Apply laws |
| 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:56:47 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2025-12-28 08:55:50 +0100 | <[exa]> | no in this case even `ap` would require the defaults |
| 2025-12-28 08:55:47 +0100 | <hololeap> | just the <*> part of Applicative |
| 2025-12-28 08:55:30 +0100 | <[exa]> | so yeah that would be a (specialized) semigroup |
| 2025-12-28 08:55:26 +0100 | <hololeap> | right, Apply is Applicative sans `pure`, |
| 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:54:39 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 260 seconds) |
| 2025-12-28 08:53:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 08:53:47 +0100 | <Leary> | That sounds like `Semigroup` instance instead. |
| 2025-12-28 08:53:39 +0100 | <hololeap> | though not exactly that |
| 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: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: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:50:04 +0100 | <hololeap> | but Apply is a class for Type -> Type |
| 2025-12-28 08:49:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 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:02 +0100 | <[exa]> | decide you want to infer which backend to use where. |
| 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: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:38:22 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 08:33:52 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 08:31:12 +0100 | sroso | (~sroso@user/SrOso) (Quit: Leaving :)) |
| 2025-12-28 08:29:18 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-12-28 08:23:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-12-28 08:18:05 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 08:13:20 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-12-28 08:06:57 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-28 08:02:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 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 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: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: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:36:46 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:7842:6802:4767:2e5b) synchromesh |
| 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:34:07 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-28 07:29:12 +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:13:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-28 07:11:02 +0100 | <ski> | ah, okay |
| 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: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:09:53 +0100 | <ski> | you could have the branching explode, and still have finite depth for every path |
| 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: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:08:21 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2025-12-28 07:07:06 +0100 | <ski> | not necessarily |