Newest at the top
| 2024-10-06 21:15:11 +0200 | <tomsmeding> | "instances are _encouraged_ to follow these properties:" |
| 2024-10-06 21:15:08 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-10-06 21:14:54 +0200 | <tomsmeding> | oh hah, yes, the extensionality law |
| 2024-10-06 21:14:24 +0200 | <Lears> | No, `Arg` is just a lawless convenience. |
| 2024-10-06 21:14:05 +0200 | <tomsmeding> | if base can do this without a big warning, then surely it's valid? |
| 2024-10-06 21:13:50 +0200 | <tomsmeding> | Arg is a data type in base whose Eq instance ignores a significant amount of information |
| 2024-10-06 21:13:14 +0200 | <Lears> | aaron: `Eq` has extensionality. |
| 2024-10-06 21:12:42 +0200 | tomsmeding | . o O ( https://hackage.haskell.org/package/base-4.14.1.0/docs/src/Data.Semigroup.html#line-298 ) |
| 2024-10-06 21:12:37 +0200 | <haskellbridge> | <aaron> So really the function doesn't need to be monotonic, it just needs to respect "(==)" |
| 2024-10-06 21:11:44 +0200 | <tomsmeding> | so the fmapped function may distinguish between elements in the "in-between" state that Set cannot distinguish between, and thus eliminates |
| 2024-10-06 21:11:41 +0200 | AlexNoo | (~AlexNoo@178.34.162.53) (Ping timeout: 255 seconds) |
| 2024-10-06 21:11:28 +0200 | <haskellbridge> | <aaron> Lears: what tomsmeding said. "(==)" is only equivalence |
| 2024-10-06 21:11:04 +0200 | AlexZenon | (~alzenon@178.34.162.53) (Ping timeout: 265 seconds) |
| 2024-10-06 21:11:03 +0200 | <tomsmeding> | Lears: I guess (==) does not imply actual equality? |
| 2024-10-06 21:10:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-06 21:10:31 +0200 | <Lears> | aaron: Can you demonstrate composition breaking for `Functor' Set`? |
| 2024-10-06 21:09:51 +0200 | <tomsmeding> | at the very least it's not easy |
| 2024-10-06 21:09:43 +0200 | <tomsmeding> | probably :p |
| 2024-10-06 21:09:38 +0200 | <haskellbridge> | <aaron> I think you may be wrong, but idk |
| 2024-10-06 21:08:48 +0200 | <tomsmeding> | (but I may be wrong there) |
| 2024-10-06 21:08:38 +0200 | <tomsmeding> | I can imagine, iirc the language that QuantifiedConstraints creates cannot be fully inferred decidably |
| 2024-10-06 21:08:25 +0200 | AlexNoo_ | (~AlexNoo@178.34.151.120) |
| 2024-10-06 21:08:07 +0200 | <haskellbridge> | <aaron> In theory QuantifiedConstraints would solve that, but last I checked it had various limitations/bugs which made it not good enough for this |
| 2024-10-06 21:07:42 +0200 | <haskellbridge> | <aaron> yes |
| 2024-10-06 21:07:16 +0200 | <tomsmeding> | aaron: in the generalisation to arbitrary categories, you mean? |
| 2024-10-06 21:06:47 +0200 | <haskellbridge> | <aaron> Also functor requires a quantified constraint "forall a. Ob a => Ob (f a)", and you end up needing to manually help the constraint solver |
| 2024-10-06 21:06:27 +0200 | <tomsmeding> | acme-dont vibes |
| 2024-10-06 21:06:04 +0200 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) {-d0t-} |
| 2024-10-06 21:06:03 +0200 | <monochrom> | newtype MonotonicFunction a b = It'sMonotonicIPromise (a -> b) |
| 2024-10-06 21:04:23 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) LukeHoersten |
| 2024-10-06 21:04:00 +0200 | <tomsmeding> | er, s/data constructor/type constructor of a data type/ |
| 2024-10-06 21:04:00 +0200 | <haskellbridge> | <aaron> Right, you can't define "Identity :: k -> k" as a newtype. There are ways to work around this, but they're not pretty |
| 2024-10-06 21:03:41 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Read error: Connection reset by peer) |
| 2024-10-06 21:03:19 +0200 | <tomsmeding> | because the "result kind" of the kind of a data constructor must be Type (or more precisely TYPE r for some RuntimeRep r)? |
| 2024-10-06 21:02:23 +0200 | <haskellbridge> | <aaron> It's painful to try to define things like the identity functor "Identity :: k -> k" in haskell |
| 2024-10-06 21:01:45 +0200 | <haskellbridge> | <aaron> The problem with generalizing functor more has to do with polykinds |
| 2024-10-06 21:01:20 +0200 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) (Ping timeout: 272 seconds) |
| 2024-10-06 21:01:06 +0200 | <tomsmeding> | ew |
| 2024-10-06 21:01:00 +0200 | <haskellbridge> | <aaron> Best you can do is use a newtype and promise not to make any invalid values of it |
| 2024-10-06 21:00:48 +0200 | <tomsmeding> | (impracticality is one of the ways in which a suggestion for a generalisation of Functor can fail to catch on) |
| 2024-10-06 21:00:38 +0200 | caconym | (~caconym@user/caconym) caconym |
| 2024-10-06 21:00:17 +0200 | <tomsmeding> | right, but I imagine it will be quite cumbersome to express the idea of a "monotonic function" in haskell |
| 2024-10-06 21:00:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-06 21:00:00 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-10-06 20:59:32 +0200 | <haskellbridge> | <aaron> You can generalize functor to work with arbitrary categories, and then Set can be a functor from the category of ordered types (where the arrows are monotonic functions) |
| 2024-10-06 20:58:07 +0200 | <tomsmeding> | and I didn't even realise now that it loses the composition law |
| 2024-10-06 20:57:50 +0200 | <tomsmeding> | I agree |
| 2024-10-06 20:57:42 +0200 | <tomsmeding> | it was a vehicle in two arguments: 1. suggestions exist for generalising Functor in a way that Set can be an instance, but no spectacularly good ideas have been offered, and 2. IxFunctor cannot do this |
| 2024-10-06 20:57:13 +0200 | <haskellbridge> | <aaron> The functor composition law is pretty important :) |
| 2024-10-06 20:57:09 +0200 | <tomsmeding> | I'm not saying we should have this Functor' |