Newest at the top
| 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) |
| 2024-11-20 19:22:31 +0100 | <tomsmeding> | right, so you're getting untyped data from the database, and you want to "create" more typing info? |
| 2024-11-20 19:22:09 +0100 | <bwe> | oh, storing multiple pages of different websites to a DB, differentiated by Variant |
| 2024-11-20 19:22:03 +0100 | <tomsmeding> | there are various ways something _like_ this can typecheck, but they all result in different designs of the program |
| 2024-11-20 19:21:29 +0100 | <tomsmeding> | what is the context? |
| 2024-11-20 19:21:23 +0100 | <tomsmeding> | where does DBEntry come from? |
| 2024-11-20 19:21:16 +0100 | <tomsmeding> | what is the X problem here (as in X-Y problem) :p |
| 2024-11-20 19:21:04 +0100 | <tomsmeding> | well, not really |
| 2024-11-20 19:20:52 +0100 | <tomsmeding> | no |
| 2024-11-20 19:20:39 +0100 | <bwe> | that would be type level programming, correct? |
| 2024-11-20 19:20:09 +0100 | <tomsmeding> | then the return type of fromDBEntry is linked to the _value_ inside the DBEntry |
| 2024-11-20 19:19:54 +0100 | <tomsmeding> | you could give Variant and DBEntry a type argument indicating what the variant is for (SiteA or SiteB) |
| 2024-11-20 19:19:34 +0100 | <tomsmeding> | the caller is allowed to choose a1 |
| 2024-11-20 19:19:29 +0100 | <tomsmeding> | same problem |
| 2024-11-20 19:19:17 +0100 | <bwe> | https://play-haskell.tomsmeding.com/saved/TXQ84gHu |
| 2024-11-20 19:19:01 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2024-11-20 19:18:49 +0100 | <tomsmeding> | so this ain't going to work: _you_ want to choose, based on a value inside the DBEntry, what 'a' is, but the type signature of fromDBEntry allows the caller of fromDBEntry to choose 'a' |
| 2024-11-20 19:18:20 +0100 | <tomsmeding> | bwe: this is getting closer, but something else is still off: in fromDBEntry, you're deciding which variant to return based on siteVariant from the DBEntry, but the _type_ you hvae to return, 'a', is from that Dict (IntoGeneral a) argument |
| 2024-11-20 19:16:57 +0100 | <bwe> | (it's not compiling, ofc) |
| 2024-11-20 19:16:02 +0100 | <bwe> | so reversing DataKinds for a moment: https://play-haskell.tomsmeding.com/saved/eaWYsjTO |
| 2024-11-20 19:15:44 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |