Newest at the top
| 2025-10-14 13:10:25 +0200 | MelodyOwO | (~MelodyOwO@user/MelodyOwO) MelodyOwO |
| 2025-10-14 13:09:00 +0200 | Zemy | (~Zemy@syn-076-184-041-021.res.spectrum.com) |
| 2025-10-14 13:08:29 +0200 | Zemy_ | (~Zemy@2600:100c:b035:5997:18fe:25ff:fe03:e2c) |
| 2025-10-14 13:08:24 +0200 | Zemy | (~Zemy@syn-076-184-041-021.res.spectrum.com) (Read error: Connection reset by peer) |
| 2025-10-14 13:01:29 +0200 | caconym7478798 | (~caconym@user/caconym) caconym |
| 2025-10-14 13:00:05 +0200 | caconym7478798 | (~caconym@user/caconym) (Quit: bye) |
| 2025-10-14 12:54:55 +0200 | chele | (~chele@user/chele) (Ping timeout: 245 seconds) |
| 2025-10-14 12:53:13 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-10-14 12:52:48 +0200 | halloy7365 | (~halloy736@2404:4400:5446:4e00:c9d:2341:235f:e891) (Quit: halloy7365) |
| 2025-10-14 12:50:11 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-10-14 12:48:01 +0200 | yegor | (yegor@user/yegor) yegor |
| 2025-10-14 12:47:44 +0200 | yegor | (~yegor@user/yegor) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-10-14 12:44:10 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 246 seconds) |
| 2025-10-14 12:38:24 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-10-14 12:33:31 +0200 | halloy7365 | (~halloy736@2404:4400:5446:4e00:c9d:2341:235f:e891) |
| 2025-10-14 12:25:52 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 2025-10-14 12:20:44 +0200 | <merijn> | Which is far from hypothetical, since we've already had at least one GHC release where a type system rejiggle changed the order of inferred variables, leading to breakage |
| 2025-10-14 12:20:29 +0200 | <tomsmeding> | but then nobody would have used it because of the chicken-egg problem |
| 2025-10-14 12:20:20 +0200 | <tomsmeding> | type applications would be more robust if they're allowed only on functions with an explicit type variable ordering |
| 2025-10-14 12:20:08 +0200 | <merijn> | You're relying on the order of type variables as part of the public interface of a library (which basically no library author considers for PVP decisions) and unless the library author explicitly `forall`'s the type variables on every function that's dependent on the whims of GHC |
| 2025-10-14 12:16:02 +0200 | <merijn> | Ugly syntax and (worse) far too brittle in my opinion |
| 2025-10-14 12:15:34 +0200 | <merijn> | coerce is good, but type applications is bad imo |
| 2025-10-14 12:15:07 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 256 seconds) |
| 2025-10-14 12:14:46 +0200 | Adeon | (sid418992@id-418992.lymington.irccloud.com) Adeon |
| 2025-10-14 12:14:34 +0200 | Adeon | (sid418992@id-418992.lymington.irccloud.com) (Server closed connection) |
| 2025-10-14 12:12:45 +0200 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2025-10-14 12:12:21 +0200 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2025-10-14 12:11:01 +0200 | <haskellbridge> | <Morj> They at least are there |
| 2025-10-14 12:10:52 +0200 | <mreh> | are type applications? |
| 2025-10-14 12:10:26 +0200 | <mreh> | ¯\_(ツ)_/¯ |
| 2025-10-14 12:09:58 +0200 | <haskellbridge> | <Morj> Also is coerce in microhs? ;-) |
| 2025-10-14 12:09:55 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 245 seconds) |
| 2025-10-14 12:09:50 +0200 | <haskellbridge> | <Morj> I like being explicit |
| 2025-10-14 12:09:18 +0200 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-10-14 12:09:18 +0200 | <mreh> | shouldn't you use coerce and type applications in that case? |
| 2025-10-14 12:09:16 +0200 | <haskellbridge> | <Morj> Would be cool if there was a combinator like "foldMap coerce" so that I only had to write the newtype name once |
| 2025-10-14 12:08:27 +0200 | <haskellbridge> | <Morj> I find that where I use newtypes for their instances, it's usually not a bad ergonomic to write. Like "getProduct . foldMap Product" |
| 2025-10-14 12:06:57 +0200 | mochie | (~mochie@user/mochie) () |
| 2025-10-14 12:06:04 +0200 | <haskellbridge> | <Morj> At least with newtypes unlike in rust you don't have problems that "fn(&MyType) -> &MyNewtype" is impossible to write |
| 2025-10-14 12:00:29 +0200 | <merijn> | My main tooling problem is sbt. I'd kill for cabal's speed xD |
| 2025-10-14 11:58:24 +0200 | <dminuoso> | merijn: I think it may be a tooling problem in scala if its unclear what implicit is in scope right now. |
| 2025-10-14 11:58:06 +0200 | califax | (~califax@user/califx) califx |
| 2025-10-14 11:56:26 +0200 | <dminuoso> | Some libraries are more honest like `time` where you just dont get Eq on some newtypes because there's two equally good possibilities. |
| 2025-10-14 11:56:09 +0200 | dhil | (~dhil@5.151.29.137) dhil |
| 2025-10-14 11:56:00 +0200 | <dminuoso> | Having all these newtypes with clear bias about what the author thought should be "the authoritative behavior for typeclass XYZ" is just annoying. |
| 2025-10-14 11:54:44 +0200 | <merijn> | I've been doing Scala for the past 2 years and the fact that implicit's let you do that is a giant nightmare |
| 2025-10-14 11:54:20 +0200 | <merijn> | dminuoso: Hard disagree |
| 2025-10-14 11:54:15 +0200 | mochie | (~mochie@user/mochie) mochie |
| 2025-10-14 11:53:24 +0200 | <dminuoso> | And yes, we'd give up guarantees on coherence that apply to some very obscure usecases... |
| 2025-10-14 11:52:53 +0200 | <dminuoso> | merijn: Honestly I think much of Haskell typeclasses would be far more usable if we had an ergonomic way of just picking/swapping out instances other than newtype wrappers. |