Newest at the top
| 2025-02-12 01:04:57 +0100 | <EvanR> | just like using imperative programming everywhere where it wouldn't help 99% of the time |
| 2025-02-12 01:04:38 +0100 | <dminuoso> | I mean writing newtypes with custom instances, and then selecting those instances is not a problem either. |
| 2025-02-12 01:04:34 +0100 | <EvanR> | other languages have mechanisms for using explicit instances and there comes with it the additional cognitive overhead |
| 2025-02-12 01:04:08 +0100 | <dminuoso> | If we had the freedom to just say "Dont resolve, Ill decide here locally", much of the incoherence problems disappear. |
| 2025-02-12 01:03:49 +0100 | <dminuoso> | EvanR: Note, Im not talking about forcing automatic instance resolution. |
| 2025-02-12 01:03:19 +0100 | <EvanR> | code A sees instance B while code C sees instance D of the same typeclass on the same type |
| 2025-02-12 01:03:18 +0100 | <dminuoso> | EvanR: I've been using orphan instances a plenty lot without having any occurence of that. |
| 2025-02-12 01:03:05 +0100 | <ski> | well, avoiding needing to parameterize over nonlocal tyvars, at least |
| 2025-02-12 01:02:41 +0100 | <EvanR> | dminuoso, it's really nice not having to worry about incoherent instances |
| 2025-02-12 01:02:38 +0100 | <ski> | ah |
| 2025-02-12 01:02:35 +0100 | <dminuoso> | A module level type |
| 2025-02-12 01:02:24 +0100 | <ski> | benefit over what ? |
| 2025-02-12 01:02:11 +0100 | <ski> | mm |
| 2025-02-12 01:02:09 +0100 | <dminuoso> | At that point I'm not too sure what benefit you would gain. |
| 2025-02-12 01:01:57 +0100 | <ski> | perhaps it would be nice to have two variants, one requiring uniqueness, and the other not .. i dunno |
| 2025-02-12 01:01:55 +0100 | <dminuoso> | At least for `data` GHC would have to drag the type in interface files in case of inlining. |
| 2025-02-12 01:01:39 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-12 01:01:14 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-12 01:00:57 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-12 01:00:37 +0100 | <ski> | as long as the instance is given in the same scope as the data type, i think there'd be no issue with coherence |
| 2025-02-12 01:00:06 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds) |
| 2025-02-12 00:59:56 +0100 | <dminuoso> | Oh, locally scoped instances yes. |
| 2025-02-12 00:59:36 +0100 | <ski> | occasionally, i'd like to be able to define types (possibly non-locally depending on tyvars in scope) in `where' and `let', as well as making instances for them there |
| 2025-02-12 00:59:03 +0100 | <dminuoso> | The discussions Ive seen over the years consistently bring up coherence issues, but they feel contrived. |
| 2025-02-12 00:58:25 +0100 | <ski> | mm |
| 2025-02-12 00:58:09 +0100 | <dminuoso> | ski: At times I do wish we had a mechanism to just swap out typeclass instances, or have some overlapping ones and then decide which ones I want. |
| 2025-02-12 00:56:31 +0100 | <dminuoso> | Oh well, I think I understand what the diagnostic is really trying to say |
| 2025-02-12 00:55:20 +0100 | <ski> | (assuming `data Showable = forall a. Show a => WrapShowable a', and `withShowable :: Showable -> (forall a. Show a => a -> o) -> o') |
| 2025-02-12 00:55:09 +0100 | <dminuoso> | But that has no associated forall either.. |
| 2025-02-12 00:54:51 +0100 | <yahb2> | <no output> |
| 2025-02-12 00:54:51 +0100 | <dminuoso> | % id :: a -> a; id @a x = (x :: a) |
| 2025-02-12 00:54:49 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 244 seconds) |
| 2025-02-12 00:54:37 +0100 | <dminuoso> | Invisible type pattern? |
| 2025-02-12 00:54:20 +0100 | <dminuoso> | Hold on. |
| 2025-02-12 00:54:13 +0100 | <ski> | withShowable (WrapShowable @a x) k = k @a x -- could one write something like this ? |
| 2025-02-12 00:54:13 +0100 | <yahb2> | <interactive>:263:4: error: [GHC-14964] ; • Invisible type pattern a has no associated forall ; • In an equation for ‘id’: id @a x = (x :: a) |
| 2025-02-12 00:54:13 +0100 | <dminuoso> | % id @a x = (x :: a) |
| 2025-02-12 00:54:02 +0100 | <yahb2> | <no output> |
| 2025-02-12 00:54:02 +0100 | <dminuoso> | % :set -XTypeAbstractions |
| 2025-02-12 00:53:02 +0100 | ski | doesn't think the selection of `@' is great |
| 2025-02-12 00:52:35 +0100 | <dminuoso> | I recall there was a proposal a while ago, but I cant quite remember the name of the extension |
| 2025-02-12 00:52:20 +0100 | <ski> | debatable |
| 2025-02-12 00:52:03 +0100 | <dminuoso> | Do we have a suitable syntax for type application, now? |
| 2025-02-12 00:51:33 +0100 | <ski> | perhaps there should be an explicit syntax for dictionary application ? |
| 2025-02-12 00:50:32 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-12 00:50:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-12 00:49:50 +0100 | <ski> | (s/eta reduction/function extensionality/) |
| 2025-02-12 00:49:39 +0100 | <yahb2> | () |
| 2025-02-12 00:49:38 +0100 | <geekosaur> | % let { withDict'' :: Dict a -> (a => r) -> r; withDict'' Dict = id } in () |
| 2025-02-12 00:49:17 +0100 | <yahb2> | <no output> |