Newest at the top
| 2024-11-20 19:37:59 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-20 19:37:55 +0100 | <bwe> | tomsmeding, dminuoso, probie: thanks for your support! |
| 2024-11-20 19:37:52 +0100 | <tomsmeding> | persistent |
| 2024-11-20 19:37:41 +0100 | euleritian | (~euleritia@dynamic-176-006-139-078.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-11-20 19:37:41 +0100 | <tomsmeding> | I'd say, avoid explicit 'forall' for now, as you're learning |
| 2024-11-20 19:37:36 +0100 | <bwe> | btw how persistent is your paste? |
| 2024-11-20 19:37:24 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2024-11-20 19:37:19 +0100 | <tomsmeding> | the caller has to know what they get back from fromDBEntry |
| 2024-11-20 19:37:17 +0100 | <bwe> | tomsmeding: so avoid or not avoid foralls is the question |
| 2024-11-20 19:37:08 +0100 | <tomsmeding> | exactly |
| 2024-11-20 19:37:02 +0100 | <bwe> | tomsmeding: and the SiteVariant with SVA and SVBs got introduced by you to return a single type with fromDBEntry (instead of SiteA, SiteB different types |
| 2024-11-20 19:36:56 +0100 | <tomsmeding> | it's the foralls inside argument types that bring you in RankNTypes land |
| 2024-11-20 19:36:26 +0100 | <yahb2> | map :: forall a b. (a -> b) -> [a] -> [b] |
| 2024-11-20 19:36:26 +0100 | <tomsmeding> | % :t map |
| 2024-11-20 19:36:24 +0100 | <yahb2> | <no output> |
| 2024-11-20 19:36:24 +0100 | <tomsmeding> | % :set -fprint-explicit-foralls |
| 2024-11-20 19:36:20 +0100 | <yahb2> | map :: (a -> b) -> [a] -> [b] |
| 2024-11-20 19:36:20 +0100 | <tomsmeding> | % :t map |
| 2024-11-20 19:36:18 +0100 | <tomsmeding> | well there's implicit foralls on many haskell functions ;) |
| 2024-11-20 19:36:06 +0100 | <bwe> | tomsmeding: so, avoid whenever possible forall? |
| 2024-11-20 19:36:02 +0100 | <tomsmeding> | but they exist for the times when you do |
| 2024-11-20 19:35:55 +0100 | <tomsmeding> | existentials are awkward in haskell, and they're usually not what you need |
| 2024-11-20 19:35:42 +0100 | <bwe> | let that sink in |
| 2024-11-20 19:35:36 +0100 | <tomsmeding> | and with my untyped version, you also don't know what kind of site you're getting, but at least you can easily figure out by checking whether it's an SVA or an SVB |
| 2024-11-20 19:35:15 +0100 | <tomsmeding> | but given the functions you're writing here, I don't think the additional typing gives you much, because when you get that (a, General), you still don't know what 'a' is, so you'll have to do something to figure that out |
| 2024-11-20 19:34:25 +0100 | <tomsmeding> | this is one way of encoding an existential in haskell; the other is using a data type that wraps the existential inside |
| 2024-11-20 19:33:50 +0100 | <tomsmeding> | (and then fromDBEntry just returns whatever that function returns, of type 'r') |
| 2024-11-20 19:33:44 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-11-20 19:33:18 +0100 | Square | (~Square@user/square) Square |
| 2024-11-20 19:33:05 +0100 | <tomsmeding> | hence fromDBEntry can choose what that 'a' is going to be |
| 2024-11-20 19:32:56 +0100 | <tomsmeding> | that forall in probie's version means that the caller has to pass fromDBEntry a function that works for _any_ a |
| 2024-11-20 19:32:35 +0100 | <bwe> | so what's the buzz about the forall? |
| 2024-11-20 19:32:32 +0100 | <tomsmeding> | sometimes simple is better :) |
| 2024-11-20 19:32:04 +0100 | <tomsmeding> | probie: but given the methods of the IntoGeneral class, I don't feel like an implementation of that continuation could do much more than with the untyped version |
| 2024-11-20 19:31:42 +0100 | euleritian | (~euleritia@dynamic-176-006-139-078.176.6.pool.telefonica.de) |
| 2024-11-20 19:31:22 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2024-11-20 19:30:47 +0100 | <tomsmeding> | right, that's one way of encoding that existential lol |
| 2024-11-20 19:30:31 +0100 | <bwe> | thumbs up :) |
| 2024-11-20 19:30:29 +0100 | <probie> | bwe: I haven't quite been following what you're trying to do, but could https://play-haskell.tomsmeding.com/saved/gnOyTnbR work? |
| 2024-11-20 19:29:43 +0100 | <tomsmeding> | but I suspect this is good enough for you |
| 2024-11-20 19:29:33 +0100 | ljdarj1 | ljdarj |
| 2024-11-20 19:29:33 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2024-11-20 19:29:33 +0100 | <tomsmeding> | if you want to invent type information that did not exist beforehand, you'll need an existential wrapper around the result to allow the function to choose the type, not the caller |
| 2024-11-20 19:28:05 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-20 19:26:13 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-20 19:26:10 +0100 | <tomsmeding> | just make a new sum type with the possible pages inside |
| 2024-11-20 19:25:32 +0100 | <tomsmeding> | bwe: what about a low-tech option? https://play-haskell.tomsmeding.com/saved/au6S9SPc |
| 2024-11-20 19:23:44 +0100 | <bwe> | are we getting closer to X of XY :) ? |
| 2024-11-20 19:23:25 +0100 | <bwe> | then loading that from DB, channelling it into different parsing machinery depending on `Variant`, which eventually culminates into `General` which is abstract, again |
| 2024-11-20 19:22:50 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Ping timeout: 244 seconds) |