2025/09/28

Newest at the top

2025-09-28 22:08:38 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess
2025-09-28 22:01:35 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2025-09-28 22:01:26 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2025-09-28 22:00:44 +0200Googulator59(~Googulato@193-226-241-153.pool.digikabel.hu) (Quit: Client closed)
2025-09-28 22:00:40 +0200Googulator84(~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu)
2025-09-28 21:56:59 +0200 <tomsmeding> at least you have family this way
2025-09-28 21:56:42 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-28 21:54:02 +0200 <tomsmeding> unless you're "typing the technical interview"
2025-09-28 21:53:46 +0200 <tomsmeding> rather
2025-09-28 21:53:39 +0200 <EvanR> an awkward position to be in
2025-09-28 21:53:27 +0200 <EvanR> you have class but no value
2025-09-28 21:51:49 +0200 <tomsmeding> but in this case you have no values in the first place, so there is no sensible place to put a constraint, so TypeError it is
2025-09-28 21:51:25 +0200 <tomsmeding> because constraints behave more nicely in the type system, in general
2025-09-28 21:51:12 +0200 <tomsmeding> usually, if there's a sensible place to put a constraint and thereby save an explicit If in a type family, using the constraint is the better choice
2025-09-28 21:50:09 +0200 <tomsmeding> if your type class had a value in it too, then you would not have been able to eliminate the type class
2025-09-28 21:49:29 +0200 <tomsmeding> well, the kind of type-level programming that you're doing here is not quite what the type system was designed for :)
2025-09-28 21:48:45 +0200emmanuelux(~emmanuelu@user/emmanuelux) emmanuelux
2025-09-28 21:47:54 +0200lxsameer(~lxsameer@Serene/lxsameer) (Ping timeout: 244 seconds)
2025-09-28 21:46:13 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2025-09-28 21:45:19 +0200arandombit(~arandombi@user/arandombit) (Ping timeout: 244 seconds)
2025-09-28 21:40:54 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-28 21:40:07 +0200arandombit(~arandombi@user/arandombit) arandombit
2025-09-28 21:40:07 +0200arandombit(~arandombi@2603:7000:4600:ffbe:b1d5:1527:b9ee:ee90) (Changing host)
2025-09-28 21:40:07 +0200arandombit(~arandombi@2603:7000:4600:ffbe:b1d5:1527:b9ee:ee90)
2025-09-28 21:39:50 +0200arandombit(~arandombi@user/arandombit) (Remote host closed the connection)
2025-09-28 21:37:56 +0200L29Ah(~L29Ah@wikipedia/L29Ah) L29Ah
2025-09-28 21:34:08 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-09-28 21:32:05 +0200 <dcpagan> It's like I'm programming the IDE to gently hand-hold anyone who inherits this code.
2025-09-28 21:31:32 +0200 <dcpagan> I really like how custom type errors are immediately communicated to the IDE.
2025-09-28 21:30:48 +0200 <dcpagan> Latest update: https://github.com/DCPagan/Exercism-Haskell/blob/master/house/src/House.hs
2025-09-28 21:30:43 +0200Googulator59(~Googulato@193-226-241-153.pool.digikabel.hu)
2025-09-28 21:30:42 +0200Googulator64(~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu) (Quit: Client closed)
2025-09-28 21:30:30 +0200 <dcpagan> Do custom type errors always make such constraints redundant?
2025-09-28 21:29:32 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-28 21:27:04 +0200ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2025-09-28 21:25:38 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Ping timeout: 272 seconds)
2025-09-28 21:22:31 +0200 <tomsmeding> right
2025-09-28 21:21:19 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2025-09-28 21:21:16 +0200 <dcpagan> I was planning on constraining the type family with the constraint.
2025-09-28 21:20:56 +0200Googulator64(~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu)
2025-09-28 21:20:45 +0200Googulator64(~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu) (Quit: Client closed)
2025-09-28 21:19:05 +0200 <tomsmeding> there are very specific reasons why you may need such a thing sometimes (in particular if it appears in a QuantifiedConstraint elsewhere), but none of those apply here
2025-09-28 21:18:37 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2025-09-28 21:18:24 +0200 <tomsmeding> a class with a single, blanket instance (like you have here with VerseIndex) is very rarely useful
2025-09-28 21:18:07 +0200vanishingideal(~vanishing@user/vanishingideal) (Remote host closed the connection)
2025-09-28 21:17:40 +0200 <tomsmeding> dcpagan: why is the instance still there? Why are Verses/Stanza/Song not just top-level type families at this point?
2025-09-28 21:17:16 +0200 <tomsmeding> dcpagan: use ShowType? https://hackage.haskell.org/package/base-4.20.0.1/docs/GHC-TypeError.html#t:ErrorMessage
2025-09-28 21:13:43 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-28 21:12:53 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2025-09-28 21:12:36 +0200tromp(~textual@2001:1c00:3487:1b00:259a:5516:59ca:4e5)