Home liberachat/#haskell: Logs Calendar

Logs: liberachat/#haskell

←Prev  Next→ 1,801,932 events total
2025-12-03 05:11:06 <EvanR> cool
2025-12-03 05:11:34 <haskellbridge> <zoil> also, glguy suggested that the name singleton should not apply to the recursive KnownNE situation, but im not sure why
2025-12-03 05:11:40 <haskellbridge> <zoil> im not sure it matters
2025-12-03 05:12:04 <haskellbridge> <zoil> its like, a recursively defined case that covers many situations, as opposed to (an infinite number) of explicit assertions
2025-12-03 05:12:29 <EvanR> because KnownNE isn't even a type
2025-12-03 05:13:06 <EvanR> and you're making two instances of it, so what's "single" about that
2025-12-03 05:13:33 <haskellbridge> <zoil> sorry, WhichNE
2025-12-03 05:13:44 <haskellbridge> <zoil> data WhichNE xs where
2025-12-03 05:13:44 <haskellbridge> ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/QHgkurBjvEckITCLYEHUHCfc/FL5KnP9OiZg (3 lines)
2025-12-03 05:14:09 <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 05:14:19 <haskellbridge> <zoil> if thats not what a singleston is, idk, what this is
2025-12-03 05:14:43 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2025-12-03 05:15:26 <haskellbridge> <zoil> here was glguys paste about how to use the type family to condense the two instances into one
2025-12-03 05:15:30 <haskellbridge> <zoil> https://paste.tomsmeding.com/UEfrQUiN
2025-12-03 05:15:46 <EvanR> anyway your code compiles so
2025-12-03 05:16:02 <haskellbridge> <zoil> you dont understand the issue!?
2025-12-03 05:16:07 <haskellbridge> <zoil> its picking up these constraints!
2025-12-03 05:16:08 <EvanR> absolutely not
2025-12-03 05:16:28 <haskellbridge> <zoil> the compiler will forever ask for a constraint to an instance that exists at top level
2025-12-03 05:16:38 <haskellbridge> <zoil> simply because it exists in a distributed way
2025-12-03 05:17:29 <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 05:17:41 <haskellbridge> <zoil> just because it cant tell if its exhaustive in these cases
2025-12-03 05:18:52 <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 05:19:06 <haskellbridge> <zoil> now, if theres a "special way" of doing this, like, ensuring everything is written in just one instance
2025-12-03 05:19:12 <haskellbridge> <zoil> then at least there is a workaround
2025-12-03 05:19:33 <haskellbridge> <zoil> which should be pretty clearly indicated! since otherwise this insane behaviour from the compiler is commonly encountered
2025-12-03 05:19:42 <haskellbridge> <zoil> or it indicates a compiler fix is required
2025-12-03 05:20:39 <haskellbridge> <zoil> "compiler is nolonger blind to instances defined over several cases"
2025-12-03 05:20:59 <haskellbridge> <zoil> but then, i could just give the basecase instance. and then it would be like "wtf, this doesnt match"
2025-12-03 05:21:35 <haskellbridge> <zoil> "nonexhaustive instance encountered in this code you were trying to write on line 11"
2025-12-03 05:22:13 <haskellbridge> <zoil> which it _currently always says_
2025-12-03 05:22:33 <haskellbridge> <zoil> except in the case where no pattern matching takes place
2025-12-03 05:23:15 <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 05:25:40 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-12-03 05:25:43 EvanR looks at line 11
2025-12-03 05:25:57 <EvanR> there's nothing there
2025-12-03 05:26:38 <haskellbridge> <zoil> > :-(
2025-12-03 05:27:11 <haskellbridge> <zoil> > :-|
2025-12-03 05:27:19 <haskellbridge> <zoil> ... >:-(
2025-12-03 05:28:01 <haskellbridge> <zoil> i dont know why this type witness idea was even suggested
2025-12-03 05:28:12 <haskellbridge> <zoil> there was apparently something different about show and read
2025-12-03 05:28:16 <EvanR> what are you trying to do
2025-12-03 05:28:33 <haskellbridge> <zoil> like, show could resolve the type, but read would require something like an instance version of allowambiguous types
2025-12-03 05:28:50 <haskellbridge> <zoil> EvanR: im sorry mate, im not enjoying you just talking past everything iv written
2025-12-03 05:29:21 <haskellbridge> <zoil> i think "what im trying to do" is very much inferable from the discussion so far.
2025-12-03 05:29:22 <EvanR> I guess you can keep spamming the channel with nonsense
2025-12-03 05:29:32 <haskellbridge> <zoil> THANKS!
2025-12-03 05:29:39 <EvanR> without being rudely interrupted
2025-12-03 05:29:48 <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 05:30:01 <haskellbridge> <zoil> im not trying to be rude
2025-12-03 05:30:15 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-12-03 05:30:28 <haskellbridge> <zoil> if you could maybe not just, stonewall me, and then, as soon as this is noticed, start accusing me of not talking to you in the prescribed manner
2025-12-03 05:30:41 <haskellbridge> <zoil> what specifically is it that you dont understand
2025-12-03 05:31:05 <haskellbridge> <zoil> instead of just this most vague assertion that you cannot seem to convey any degree of understanding at all of the situation described
2025-12-03 05:31:07 <haskellbridge> <zoil> its vexating
2025-12-03 05:31:59 <haskellbridge> <zoil> "its a burden of proof, i insist i dont understand the users query and by virtue of this its nonesense"
2025-12-03 05:32:18 <haskellbridge> <zoil> its an awful precedent and it makes our community inpenetrable and unfrinedly
2025-12-03 05:36:23 michalz joins (~michalz@185.246.207.205)
2025-12-03 05:41:29 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-12-03 05:45:54 × Googulator45 quits (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu) (Quit: Client closed)
2025-12-03 05:45:56 Googulator88 joins (~Googulato@2a01-036d-0106-479c-d9ec-010d-f188-ffcb.pool6.digikabel.hu)
2025-12-03 05:46:29 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-12-03 05:48:27 takuan joins (~takuan@d8D86B9E9.access.telenet.be)
2025-12-03 05:48:55 × trickard quits (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-12-03 05:49:08 trickard_ joins (~trickard@cpe-85-98-47-163.wireline.com.au)
2025-12-03 05:54:08 <probie> +1 for could not infer what you're trying to do. There's no need to be mean about it. You're obviously frustrated by something, type families are involved, you did something with singletons but it was the wrong path(?)
2025-12-03 05:55:00 <probie> Since your problem seems to be at the type level, can you give an expression you want to type check, or not type check as appropriate?
2025-12-03 05:55:35 × Fijxu quits (~Fijxu@user/fijxu) (Quit: XD!!)
2025-12-03 05:56:10 Square2 joins (~Square4@user/square)
2025-12-03 05:57:02 Fijxu joins (~Fijxu@user/fijxu)
2025-12-03 05:57:16 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-12-03 05:57:41 × Fijxu quits (~Fijxu@user/fijxu) (Remote host closed the connection)
2025-12-03 05:59:01 Fijxu joins (~Fijxu@user/fijxu)
2025-12-03 05:59:15 × Square quits (~Square@user/square) (Ping timeout: 240 seconds)
2025-12-03 06:02:08 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-12-03 06:02:55 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-12-03 06:05:30 poscat joins (~poscat@user/poscat)
2025-12-03 06:06:26 trickard_ is now known as trickard
2025-12-03 06:07:08 × poscat0x04 quits (~poscat@user/poscat) (Ping timeout: 244 seconds)
2025-12-03 06:07:20 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-12-03 06:14:27 <haskellbridge> <zoil> thanks, im sorry i rage quit
2025-12-03 06:16:19 <haskellbridge> <zoil> so far i have this;
2025-12-03 06:16:19 <haskellbridge> https://play.haskell.org/saved/GwyPOlmo
2025-12-03 06:16:40 <haskellbridge> <zoil> er, sorry, that was the previous version, now i have this
2025-12-03 06:16:41 <haskellbridge> <zoil> https://play.haskell.org/saved/GJqAvv67
2025-12-03 06:17:30 <haskellbridge> <zoil> its saying the injectivity condition here is not accepted
2025-12-03 06:17:30 <haskellbridge> <zoil> type family StatefulTransfers (xs :: Nonempty Type) i o = (c :: Constraint) | c -> xs i o where
2025-12-03 06:18:04 <haskellbridge> <zoil> like, i cant get the fundeps to go through the injective type family properly
2025-12-03 06:18:32 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-12-03 06:21:39 <haskellbridge> <zoil> so, whatever this apparent workaround was supposed to acheive, it cant
2025-12-03 06:21:57 <haskellbridge> <zoil> because the injective type family fails to impart the same data as the fundep
2025-12-03 06:22:24 <haskellbridge> <zoil> i have concluded that the compiler hates me, and i was wrong not to have rage quit.
2025-12-03 06:23:15 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-12-03 06:23:27 <Leary> Let's kill all the cruft so others can follow along; the core issue is this: https://play.haskell.org/saved/BeYSIaVz
2025-12-03 06:24:15 <Leary> There are two instances, and GHC won't let you pretend they're the same as `Read (Two b)`, because that implies you have a way to choose which instance you want to use **at runtime** from type information alone.
2025-12-03 06:26:16 peterbecich joins (~Thunderbi@172.222.148.214)
2025-12-03 06:26:49 <EvanR> thanks
2025-12-03 06:34:02 × Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine)
2025-12-03 06:34:18 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-12-03 06:36:12 lambda_gibbon joins (~lambda_gi@2603:7080:ee00:37d8:11e:138e:d914:c117)

All times are in UTC.