Newest at the top
| 2025-12-03 06:30:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-03 06:30:01 +0100 | <haskellbridge> | <zoil> im not trying to be rude |
| 2025-12-03 06:29:48 +0100 | <haskellbridge> | <zoil> ill guess you can just keep using a time machine to write a compiler without any focus grouping from the future |
| 2025-12-03 06:29:39 +0100 | <EvanR> | without being rudely interrupted |
| 2025-12-03 06:29:32 +0100 | <haskellbridge> | <zoil> THANKS! |
| 2025-12-03 06:29:22 +0100 | <EvanR> | I guess you can keep spamming the channel with nonsense |
| 2025-12-03 06:29:21 +0100 | <haskellbridge> | <zoil> i think "what im trying to do" is very much inferable from the discussion so far. |
| 2025-12-03 06:28:50 +0100 | <haskellbridge> | <zoil> EvanR: im sorry mate, im not enjoying you just talking past everything iv written |
| 2025-12-03 06:28:33 +0100 | <haskellbridge> | <zoil> like, show could resolve the type, but read would require something like an instance version of allowambiguous types |
| 2025-12-03 06:28:16 +0100 | <EvanR> | what are you trying to do |
| 2025-12-03 06:28:12 +0100 | <haskellbridge> | <zoil> there was apparently something different about show and read |
| 2025-12-03 06:28:01 +0100 | <haskellbridge> | <zoil> i dont know why this type witness idea was even suggested |
| 2025-12-03 06:27:19 +0100 | <haskellbridge> | <zoil> ... >:-( |
| 2025-12-03 06:27:11 +0100 | <haskellbridge> | <zoil> > :-| |
| 2025-12-03 06:26:38 +0100 | <haskellbridge> | <zoil> > :-( |
| 2025-12-03 06:25:57 +0100 | <EvanR> | there's nothing there |
| 2025-12-03 06:25:43 +0100 | EvanR | looks at line 11 |
| 2025-12-03 06:25:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 06:23:15 +0100 | <haskellbridge> | <zoil> then it is like "i see the instance exists, i will not require the constraint is explicitly specified, i cannot forsee an instance where the instance does not exist where then i would require it as a constraint" |
| 2025-12-03 06:22:33 +0100 | <haskellbridge> | <zoil> except in the case where no pattern matching takes place |
| 2025-12-03 06:22:13 +0100 | <haskellbridge> | <zoil> which it _currently always says_ |
| 2025-12-03 06:21:35 +0100 | <haskellbridge> | <zoil> "nonexhaustive instance encountered in this code you were trying to write on line 11" |
| 2025-12-03 06:20:59 +0100 | <haskellbridge> | <zoil> but then, i could just give the basecase instance. and then it would be like "wtf, this doesnt match" |
| 2025-12-03 06:20:39 +0100 | <haskellbridge> | <zoil> "compiler is nolonger blind to instances defined over several cases" |
| 2025-12-03 06:19:42 +0100 | <haskellbridge> | <zoil> or it indicates a compiler fix is required |
| 2025-12-03 06:19:33 +0100 | <haskellbridge> | <zoil> which should be pretty clearly indicated! since otherwise this insane behaviour from the compiler is commonly encountered |
| 2025-12-03 06:19:12 +0100 | <haskellbridge> | <zoil> then at least there is a workaround |
| 2025-12-03 06:19:06 +0100 | <haskellbridge> | <zoil> now, if theres a "special way" of doing this, like, ensuring everything is written in just one instance |
| 2025-12-03 06:18:52 +0100 | <haskellbridge> | <zoil> as long as its "i insist that the KnownNE constraint is explicity specified", then its failing to appreciate the instance has been written at top level |
| 2025-12-03 06:17:41 +0100 | <haskellbridge> | <zoil> just because it cant tell if its exhaustive in these cases |
| 2025-12-03 06:17:29 +0100 | <haskellbridge> | <zoil> it would be like if i wrote a function matching the [] and (x:xs) cases in different function cases, and it was like "the function is not defined" |
| 2025-12-03 06:16:38 +0100 | <haskellbridge> | <zoil> simply because it exists in a distributed way |
| 2025-12-03 06:16:28 +0100 | <haskellbridge> | <zoil> the compiler will forever ask for a constraint to an instance that exists at top level |
| 2025-12-03 06:16:08 +0100 | <EvanR> | absolutely not |
| 2025-12-03 06:16:07 +0100 | <haskellbridge> | <zoil> its picking up these constraints! |
| 2025-12-03 06:16:02 +0100 | <haskellbridge> | <zoil> you dont understand the issue!? |
| 2025-12-03 06:15:46 +0100 | <EvanR> | anyway your code compiles so |
| 2025-12-03 06:15:30 +0100 | <haskellbridge> | <zoil> https://paste.tomsmeding.com/UEfrQUiN |
| 2025-12-03 06:15:26 +0100 | <haskellbridge> | <zoil> here was glguys paste about how to use the type family to condense the two instances into one |
| 2025-12-03 06:14:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-03 06:14:19 +0100 | <haskellbridge> | <zoil> if thats not what a singleston is, idk, what this is |
| 2025-12-03 06:14:09 +0100 | <haskellbridge> | <zoil> its the singletons idea of having this type witness that is matchable upon values to bring the corresponding type into scope |
| 2025-12-03 06:13:44 +0100 | <haskellbridge> | ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/QHgkurBjvEckITCLYEHUHCfc/FL5KnP9OiZg (3 lines) |
| 2025-12-03 06:13:44 +0100 | <haskellbridge> | <zoil> data WhichNE xs where |
| 2025-12-03 06:13:33 +0100 | <haskellbridge> | <zoil> sorry, WhichNE |
| 2025-12-03 06:13:06 +0100 | <EvanR> | and you're making two instances of it, so what's "single" about that |
| 2025-12-03 06:12:29 +0100 | <EvanR> | because KnownNE isn't even a type |
| 2025-12-03 06:12:04 +0100 | <haskellbridge> | <zoil> its like, a recursively defined case that covers many situations, as opposed to (an infinite number) of explicit assertions |
| 2025-12-03 06:11:40 +0100 | <haskellbridge> | <zoil> im not sure it matters |
| 2025-12-03 06:11:34 +0100 | <haskellbridge> | <zoil> also, glguy suggested that the name singleton should not apply to the recursive KnownNE situation, but im not sure why |