Newest at the top
| 2024-10-03 06:38:59 +0200 | <amano> | You are stuck with existential typeclass, a giant case statement, a giant record type, or a giant list of pattern match statements. |
| 2024-10-03 06:38:57 +0200 | <dmj`> | amano: why do you need to abstract over StateT |
| 2024-10-03 06:38:11 +0200 | <amano> | I can't eliminate StateT because I'm using someone else's library which is used by many people. |
| 2024-10-03 06:37:59 +0200 | michalz | (~michalz@185.246.207.203) |
| 2024-10-03 06:37:39 +0200 | <amano> | dmj`: There is no other type that allows polymorphism in StateT. |
| 2024-10-03 06:37:16 +0200 | <c_wraith> | When you're taking an operation-oriented viewpoint, I prefer to focus on the operations. Not some fake data type designed to hide them. |
| 2024-10-03 06:37:14 +0200 | <amano> | Simplicity results from pulling things apart. |
| 2024-10-03 06:37:12 +0200 | <dmj`> | sounds like you're using existentials to avoid more typing |
| 2024-10-03 06:37:08 +0200 | <jackdk> | Would you be able to help me take a step back from the Haskell features you're considering to solve your problem, and help me understand the problem you're trying to solve? |
| 2024-10-03 06:37:00 +0200 | <amano> | Polymorphism unentangles a giant sum type. |
| 2024-10-03 06:36:25 +0200 | <amano> | Polymorphism splits a giant case statement into multiple modules. |
| 2024-10-03 06:36:07 +0200 | <amano> | A big sum type requires a giant case statement or a long list of pattern match statements. |
| 2024-10-03 06:35:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 06:35:49 +0200 | <amano> | Right now, I have a big sum type.... |
| 2024-10-03 06:35:30 +0200 | <amano> | StateT is involved, so I have to hide polymorphism in an existential data type. |
| 2024-10-03 06:35:09 +0200 | <amano> | But, polymorphism can split a giant case statement into tiny ones. |
| 2024-10-03 06:34:46 +0200 | <c_wraith> | It's only ever added complexity when I've used it |
| 2024-10-03 06:34:32 +0200 | <amano> | Sometimes, existential typeclass seems to be the right way. |
| 2024-10-03 06:30:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 06:30:36 +0200 | <amano> | You can write functions without a typeclass, but a typeclass makes it formal. |
| 2024-10-03 06:30:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 06:30:17 +0200 | <amano> | I need to call a few functions on `a`. |
| 2024-10-03 06:29:58 +0200 | <amano> | I need `a` to be a typeclass instance. |
| 2024-10-03 06:29:31 +0200 | <Lears> | `DataType` |
| 2024-10-03 06:29:21 +0200 | <amano> | What is f? |
| 2024-10-03 06:29:20 +0200 | <dmj`> | * uses existential to solve problem, now has two problems * |
| 2024-10-03 06:28:48 +0200 | <Lears> | I don't know why there's a class involved here at all? All you need is `data Some f = forall a. Some (f a)`. |
| 2024-10-03 06:28:11 +0200 | <amano> | But, I prefer existential typeclass... |
| 2024-10-03 06:28:03 +0200 | <amano> | I know it can be represented as a record of functions.... |
| 2024-10-03 06:27:44 +0200 | <c_wraith> | it's no different from just passing around a function, or a record of them. |
| 2024-10-03 06:27:41 +0200 | <amano> | This is the only way I know to use multiple typeclass instances in StateT. |
| 2024-10-03 06:27:16 +0200 | <amano> | Why? |
| 2024-10-03 06:27:11 +0200 | <c_wraith> | and it's kinda useless. |
| 2024-10-03 06:26:33 +0200 | <amano> | This is existential typeclass |
| 2024-10-03 06:26:29 +0200 | <amano> | I mean data SomeType = forall a. TypeClass a => SomeType a |
| 2024-10-03 06:25:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 06:23:42 +0200 | <c_wraith> | Lens is all about bidirectional mapping, so it handles that case relatively easily. |
| 2024-10-03 06:23:23 +0200 | <c_wraith> | I just mean that in (s -> m (a, s)), s appears in both positive and negative position. This means it's not covariant or contravariant - you can't map it simply. |
| 2024-10-03 06:23:01 +0200 | <Lears> | If the type parameter to `DataType` is recoverable, then yes, it's simplest just to hide it with `Some DataType`. |
| 2024-10-03 06:22:32 +0200 | <Lears> | StateT uses the same type for the input state as the output state; so not unless you change both. If you lift this restriction with your own StateT', then you cannot make it a Monad, though you can make it an indexed monad. |
| 2024-10-03 06:22:19 +0200 | <c_wraith> | uh, not sure what you mean by that. |
| 2024-10-03 06:21:51 +0200 | <amano> | Then, I have to use existential typeclass in a data type? |
| 2024-10-03 06:21:20 +0200 | <c_wraith> | the trick, and why it appears in lens, is that the transformation needs to be bidirectional |
| 2024-10-03 06:20:41 +0200 | <c_wraith> | nothing in mtl/transformers provides that. mmorph doesn't seem to provide that. lens *does*, as part of the Zoom interface. |
| 2024-10-03 06:20:38 +0200 | <lambdabot> | (s -> m (a, s)) -> StateT s m a |
| 2024-10-03 06:20:37 +0200 | <Lears> | :t StateT |
| 2024-10-03 06:17:10 +0200 | <amano> | I mean StateT (DataType a) m () |
| 2024-10-03 06:16:36 +0200 | <amano> | Let's assume StateT (DataType a) m a. Can StateT replace DataType a with DataType b? |
| 2024-10-03 06:15:59 +0200 | amano | (amano@gateway/vpn/airvpn/amano) amano |
| 2024-10-03 06:14:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |