2024/11/07

Newest at the top

2024-11-07 23:33:06 +0100 <monochrom> I haven't tried. I only have GADTs and GHC2021 (I think it includes RankNTypes).
2024-11-07 23:32:37 +0100 <tomsmeding> monochrom: is "foo = undefined" accepted if you turn on -XImpredicativeTypes?
2024-11-07 23:31:47 +0100 <monochrom> Haha this is probably a consequence of quicklook impredicativity. I have "foo :: (forall x. ...) -> ()" for example (in general a rank-2+ type sig), then I can't have "foo = undefined" if I want a TODO stub, I have to write at least "foo _ = undefined".
2024-11-07 23:27:04 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-11-07 23:24:24 +0100ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2024-11-07 23:22:11 +0100michalz(~michalz@185.246.207.221) (Remote host closed the connection)
2024-11-07 23:22:03 +0100jero98772(~jero98772@2800:484:1d7c:cc00::1)
2024-11-07 23:21:50 +0100ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2024-11-07 23:20:03 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-11-07 23:13:49 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-11-07 23:13:43 +0100JuanDaugherty(~juan@user/JuanDaugherty) (Quit: JuanDaugherty)
2024-11-07 23:13:23 +0100 <tomsmeding> yes, clearly Ed was wrong.
2024-11-07 23:12:25 +0100 <tomsmeding> so actually "Ap f x" are good variable names, just for `flip Ap`, not for `Ap` :D
2024-11-07 23:10:49 +0100 <tomsmeding> but you still have to do the mental induction, I guess
2024-11-07 23:10:46 +0100alp(~alp@2001:861:e3d6:8f80:6393:3939:65f3:74c5) (Remote host closed the connection)
2024-11-07 23:10:36 +0100 <tomsmeding> yes, because then it looks like a symbolic function applied to an argument inside f
2024-11-07 23:09:37 +0100 <tomsmeding> hm, perhaps not
2024-11-07 23:09:34 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
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 +0100takuan(~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 +0100infinity0(~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 +0100merijn(~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 liftAn!
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 +0100tomsmeding. o O ( this module actually has an informative Portability metadata field )
2024-11-07 22:54:54 +0100Everything(~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 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)