Newest at the top
| 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 |
| 2024-11-20 19:13:59 +0100 | <tomsmeding> | where SiteA and SiteB are actual data types with fields |
| 2024-11-20 19:13:54 +0100 | <tomsmeding> | bwe: are you perhaps confused because you actually intended to write `data SiteVariant = SiteA SiteA | SiteB SiteB`? |
| 2024-11-20 19:12:45 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-11-20 19:12:33 +0100 | <tomsmeding> | (if you're posting playground snippets, you can check them with a click on a button -- do so ;) ) |
| 2024-11-20 19:12:16 +0100 | <bwe> | so that will be then SiteVariant |