Newest at the top
| 2024-10-03 08:25:52 +0200 | <amano> | I'm not going to rewrite my application with existential typeclass, but my next application will attempt existential typeclass. |
| 2024-10-03 08:22:33 +0200 | <amano> | Why do people want to avoid existential typeclass when it seems easy and simple? |
| 2024-10-03 08:19:03 +0200 | benjaminl | (~benjaminl@user/benjaminl) benjaminl |
| 2024-10-03 08:18:47 +0200 | benjaminl | (~benjaminl@user/benjaminl) (Read error: Connection reset by peer) |
| 2024-10-03 08:15:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 08:15:37 +0200 | <amano> | Its drawback is type information loss. |
| 2024-10-03 08:15:17 +0200 | <amano> | At least, existential typeclass is easy to reason about. |
| 2024-10-03 08:14:42 +0200 | <haskellbridge> | <sm> amano: I think your giant case statement might be helping - it's simple and clear! |
| 2024-10-03 08:14:35 +0200 | <amano> | probie: Your example is more convoluted than existential typeclass... |
| 2024-10-03 08:13:58 +0200 | neuroevolutus | (~neuroevol@146.70.211.46) neuroevolutus |
| 2024-10-03 08:13:53 +0200 | <amano> | sm: Not yet. |
| 2024-10-03 08:13:49 +0200 | <probie> | sm: I don't think it scales either, but I posit it is _no worse_ for that than `data SomeType = forall a. TypeClass a => SomeType a` |
| 2024-10-03 08:13:39 +0200 | <haskellbridge> | <sm> haven't you had a bug in yours yet ? |
| 2024-10-03 08:13:00 +0200 | <amano> | sm: I don't even know how to debug a haskell application. |
| 2024-10-03 08:11:33 +0200 | m5zs7k | (aquares@web10.mydevil.net) m5zs7k |
| 2024-10-03 08:11:11 +0200 | <haskellbridge> | <sm> It's a nice example but I have doubts about this when it grows into a real world app. I used to use records-of-functions in mine, and it made debugging very difficult. |
| 2024-10-03 08:11:07 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 08:09:25 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-03 08:08:53 +0200 | <amano> | That's not how I am going to organize brick code. |
| 2024-10-03 08:06:42 +0200 | araujo | (~araujo@216.73.163.154) araujo |
| 2024-10-03 08:03:58 +0200 | <probie> | amano: https://play.haskell.org/saved/Lcwk9WaE for a boring record solution that may still allow you to do what you want |
| 2024-10-03 08:03:51 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 08:02:11 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 260 seconds) |
| 2024-10-03 08:01:52 +0200 | adanwan_ | (~adanwan@gateway/tor-sasl/adanwan) adanwan |
| 2024-10-03 08:00:09 +0200 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 246 seconds) |
| 2024-10-03 07:52:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-03 07:48:23 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 07:45:52 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2024-10-03 07:44:06 +0200 | hueso | (~root@user/hueso) hueso |
| 2024-10-03 07:43:56 +0200 | hueso | (~root@user/hueso) (Ping timeout: 255 seconds) |
| 2024-10-03 07:43:42 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Ping timeout: 246 seconds) |
| 2024-10-03 07:41:55 +0200 | <haskellbridge> | <thirdofmay18081814goya> for any total hylomorphism is time complexity decidable? |
| 2024-10-03 07:40:41 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Ping timeout: 252 seconds) |
| 2024-10-03 07:40:23 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-10-03 07:39:42 +0200 | tzh_ | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-10-03 07:37:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-03 07:37:37 +0200 | <JuanDaugherty> | "timeline of ghc major versions" is an irritating rabbit hole but "when was ghc 6.4 released" does the right thing |
| 2024-10-03 07:35:47 +0200 | neuroevolutus | (~neuroevol@146.70.211.46) (Ping timeout: 256 seconds) |
| 2024-10-03 07:33:20 +0200 | <probie> | That's not a toy example though :p Hang on, let me write something |
| 2024-10-03 07:32:51 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-03 07:30:09 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-10-03 07:29:17 +0200 | <amano> | probie: https://codeberg.org/amano.kenji/brick-trading-journal/src/branch/master/app/Main.hs#L108 |
| 2024-10-03 07:29:06 +0200 | <amano> | probie: No giant case statement. No giant list of pattern matching function statements. |
| 2024-10-03 07:28:43 +0200 | <amano> | I just prefer existential typeclasses in my application. |
| 2024-10-03 07:28:28 +0200 | <amano> | I don't need anything technically. |
| 2024-10-03 07:28:05 +0200 | <probie> | amano: Can you give me a toy example of what "needs" existential typeclasses, and I'll attempt to give an example that doesn't use them _and_ meets your requirement of not being a giant case statement? |
| 2024-10-03 07:27:57 +0200 | sand-witch | (~m-mzmz6l@vmi833741.contaboserver.net) |
| 2024-10-03 07:26:59 +0200 | aforemny | (~aforemny@i59F4C77A.versanet.de) aforemny |
| 2024-10-03 07:26:11 +0200 | <amano> | I haven't seen any roadblock for using existential typeclass in my application. |
| 2024-10-03 07:25:55 +0200 | <monochrom> | BTW do you like my pun with "on a case-by-case basis"? >:) |