Newest at the top
| 2024-11-07 23:35:53 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-11-07 23:35:53 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Read error: Connection reset by peer) |
| 2024-11-07 23:35:53 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-11-07 23:35:42 +0100 | <monochrom> | Right yeah. |
| 2024-11-07 23:35:10 +0100 | <tomsmeding> | https://play.haskell.org/saved/Qtf5WYqV |
| 2024-11-07 23:35:02 +0100 | <tomsmeding> | and -XDeepSubsumption does not! |
| 2024-11-07 23:34:42 +0100 | <tomsmeding> | -XImpredicativeTypes also works :> |
| 2024-11-07 23:34:06 +0100 | <geekosaur> | -XDeepSubsumption if your ghc is new enough |
| 2024-11-07 23:33:46 +0100 | <monochrom> | Oh wait, it's shallow vs deep subsumption. |
| 2024-11-07 23:33:45 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-07 23:33:35 +0100 | <tomsmeding> | it certainly was disallowed before :) |
| 2024-11-07 23:33:29 +0100 | <tomsmeding> | (I would rather expect it the other round: instantiating 'undefined' with a type containing foralls could be _permissible due to_ quicklook) |
| 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 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-11-07 23:24:24 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2024-11-07 23:22:11 +0100 | michalz | (~michalz@185.246.207.221) (Remote host closed the connection) |
| 2024-11-07 23:22:03 +0100 | jero98772 | (~jero98772@2800:484:1d7c:cc00::1) |
| 2024-11-07 23:21:50 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2024-11-07 23:20:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-07 23:13:49 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-07 23:13:43 +0100 | JuanDaugherty | (~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 +0100 | alp | (~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 +0100 | merijn | (~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 +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 |