Newest at the top
| 2024-11-07 23:08:55 +0100 | <tomsmeding> | I feel like I would have spotted the "this is liftAn" faster then too |
| 2024-11-07 23:08:32 +0100 | <tomsmeding> | I mean, I get the parallel with (>>=), but come on, you're working in Haskell, and in Haskell, (<*>) is flipped |
| 2024-11-07 23:08:06 +0100 | <tomsmeding> | it would also help if Ap was just flipped |
| 2024-11-07 23:06:32 +0100 | <monochrom> | Nah the documentation is like "we are high brow, this is obvious from working out the left adjoint of the forgetful functor" |
| 2024-11-07 23:06:07 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-11-07 23:06:01 +0100 | <tomsmeding> | (there's likely some alternative interpretation of this particular formulation of Ap that corresponds with some mathematical perspective on applicative functors) |
| 2024-11-07 23:05:15 +0100 | <tomsmeding> | it makes the whole thing obvious all at once |
| 2024-11-07 23:05:02 +0100 | <tomsmeding> | now you know what would be nice? If this listy interpretation was there in the documentation. |
| 2024-11-07 23:04:53 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2024-11-07 23:04:38 +0100 | <monochrom> | "but it requires you to learn GADTs" >:) |
| 2024-11-07 23:04:25 +0100 | <tomsmeding> | they'll sure be thankful |
| 2024-11-07 23:04:19 +0100 | <tomsmeding> | point them to Control.Applicative.Free next time >:) |
| 2024-11-07 23:04:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-07 23:03:51 +0100 | <monochrom> | Oh there is the variadic liftAn my students are looking for! |
| 2024-11-07 23:03:44 +0100 | <tomsmeding> | then it's also clear how this "just" normalises out the (<*>) association order |
| 2024-11-07 23:03:13 +0100 | <tomsmeding> | and that makes more sense: it's just liftA n! |
| 2024-11-07 23:02:53 +0100 | <tomsmeding> | (when carefully expanding the data type) |
| 2024-11-07 23:02:53 +0100 | <monochrom> | Oh oops, yeah. |
| 2024-11-07 23:02:32 +0100 | <tomsmeding> | monochrom: that list is not quite what's happening though. It's rather Ap f z ~= [f a, f b, f c, c -> b -> a -> z] |
| 2024-11-07 22:58:45 +0100 | <tomsmeding> | yes |
| 2024-11-07 22:58:43 +0100 | <tomsmeding> | :D |
| 2024-11-07 22:58:38 +0100 | <monochrom> | Like f x = x f ? >:) |
| 2024-11-07 22:58:12 +0100 | <tomsmeding> | can't "apply" be commutative -.- |
| 2024-11-07 22:57:56 +0100 | <tomsmeding> | s/which is already applied to/to which is already applied/ |
| 2024-11-07 22:57:23 +0100 | <tomsmeding> | where the top-level `f` computation computes a result, which is already applied to its continuation to produce the computation to run next |
| 2024-11-07 22:56:53 +0100 | <monochrom> | which is just waiting to be interpreted/collapsed by a custom-made join :: f (f a) -> f a |
| 2024-11-07 22:55:51 +0100 | <monochrom> | Yeah, free monad tries to have f (f (f ... (f (Pure x)...) |
| 2024-11-07 22:55:15 +0100 | tomsmeding | . o O ( this module actually has an informative Portability metadata field ) |
| 2024-11-07 22:54:54 +0100 | Everything | (~Everythin@178-133-1-121.mobile.vf-ua.net) Everything |
| 2024-11-07 22:54:25 +0100 | <tomsmeding> | and that makes sense: a free monad also normalises out the association order of binds, so analogously, a free applicative should also normalise out the association order of (<*>) |
| 2024-11-07 22:54:22 +0100 | <monochrom> | Your question inspired me to actually think about it. :) |
| 2024-11-07 22:53:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-11-07 22:53:24 +0100 | <tomsmeding> | monochrom: the remark about the "list" is quite apt |
| 2024-11-07 22:52:29 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-07 22:52:26 +0100 | <monochrom> | I thought up my own field names "Ap f_secret cont", where f_secret :: f s, cont :: Ap f (s -> a). |
| 2024-11-07 22:51:47 +0100 | <tomsmeding> | it's just that juxtaposing the two makes it kind of funny |
| 2024-11-07 22:51:37 +0100 | <tomsmeding> | I mean, I kind of get it -- we have a value in a functor (call it f), and we have a value of our data type (call it x) |
| 2024-11-07 22:51:20 +0100 | <tomsmeding> | :D |
| 2024-11-07 22:51:13 +0100 | rvalue- | rvalue |
| 2024-11-07 22:51:08 +0100 | <monochrom> | Haha. "Let e be a group, H be its identity element, phi be a subgroup of e, G be a group homomorphism from e to f" |
| 2024-11-07 22:50:15 +0100 | <monochrom> | Oh I think I see it. It is trying to have a list like [x0 :: f A0, x1 :: f (A0 -> A1), x2 :: f (A1 -> A2)]. |
| 2024-11-07 22:50:08 +0100 | <tomsmeding> | f :: f a ; x :: Ap f (a -> b) |
| 2024-11-07 22:49:33 +0100 | <tomsmeding> | monochrom: if you wanna laugh, look at the implementation of runAp -- and in particular the naming of the fields of Ap |
| 2024-11-07 22:48:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-07 22:48:00 +0100 | <monochrom> | and it can't be in Pure so it may as well be in the recursive case. |
| 2024-11-07 22:47:39 +0100 | <monochrom> | Supposedly f has to be actually relevant somewhere rather than being a phantom type. |
| 2024-11-07 22:47:00 +0100 | <monochrom> | I don't know! I'm just learning. :) |
| 2024-11-07 22:46:36 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 276 seconds) |
| 2024-11-07 22:46:21 +0100 | <tomsmeding> | monochrom: is there a good reason the first field of that Ap doesn't have an Ap around it? |
| 2024-11-07 22:45:21 +0100 | rvalue- | (~rvalue@user/rvalue) rvalue |