2024/05/30

Newest at the top

2024-05-30 17:16:57 +0200destituion(~destituio@2a02:2121:2c1:d808:3194:9b7f:f69a:e531)
2024-05-30 17:13:41 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi)
2024-05-30 17:10:58 +0200econo_(uid147250@id-147250.tinside.irccloud.com)
2024-05-30 17:10:21 +0200segfaultfizzbuzz(~segfaultf@23-93-189-95.fiber.dynamic.sonic.net)
2024-05-30 17:10:16 +0200destituion(~destituio@85.221.111.174) (Ping timeout: 256 seconds)
2024-05-30 17:10:03 +0200Guest8883(arsen@aarsen.me) (Client Quit)
2024-05-30 17:09:54 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.1)
2024-05-30 17:09:51 +0200ArsenGuest8883
2024-05-30 17:09:50 +0200sprout(~quassel@84-80-106-227.fixed.kpn.net)
2024-05-30 17:09:27 +0200Arsen(arsen@aarsen.me)
2024-05-30 17:08:34 +0200Arsen(arsen@gentoo/developer/managarm.dev.Arsen) (Quit: Quit.)
2024-05-30 17:07:35 +0200segfaultfizzbuzz(~segfaultf@23-93-189-95.fiber.dynamic.sonic.net) (Remote host closed the connection)
2024-05-30 17:06:49 +0200sprout(~quassel@2a02-a448-3a80-0-d87b-5f06-a0ad-e4e3.fixed6.kpn.net) (Ping timeout: 256 seconds)
2024-05-30 16:58:35 +0200segfaultfizzbuzz(~segfaultf@23-93-189-95.fiber.dynamic.sonic.net)
2024-05-30 16:54:24 +0200danse-nr3(~danse-nr3@151.35.245.180) (Ping timeout: 256 seconds)
2024-05-30 16:54:11 +0200son0p(~ff@186.121.56.64)
2024-05-30 16:51:42 +0200rvalue(~rvalue@user/rvalue)
2024-05-30 16:51:11 +0200rvalue(~rvalue@user/rvalue) (Read error: Connection reset by peer)
2024-05-30 16:47:56 +0200euleritian(~euleritia@dynamic-176-003-083-232.176.3.pool.telefonica.de)
2024-05-30 16:45:57 +0200euleritian(~euleritia@77.22.252.56) (Read error: Connection reset by peer)
2024-05-30 16:41:46 +0200 <c_wraith> This aspect also helps with documentation. You don't need to go searching around for every class with a ReaderT instance. You can put the entire API into a single module, if you like.
2024-05-30 16:40:25 +0200 <c_wraith> With a newtype, you get much better control over what you make available, so you can narrowly tailor it to your application's needs.
2024-05-30 16:39:50 +0200 <c_wraith> If you use a type alias, you don't have any choice - you get the whole ReaderT api.
2024-05-30 16:39:28 +0200 <c_wraith> My other point was that ReaderT has a *huge* API, and sometimes you just don't want to expose all of it. You want something more narrowly-tailored to your use case.
2024-05-30 16:38:40 +0200 <c_wraith> So you're allowed to compartmentalize your reasoning more. You can ignore what it expands to in a lot more cases.
2024-05-30 16:38:30 +0200 <lxsameer> thank you
2024-05-30 16:38:27 +0200 <lxsameer> ah got it
2024-05-30 16:37:56 +0200 <c_wraith> A newtype, on the other hand, is always a distinct type. It will always show up in type errors.
2024-05-30 16:37:30 +0200 <c_wraith> So... type aliases get expanded. GHC doesn't do a pass to try to match types with existing aliases when reporting type errors. Sometimes it will already have the info on hand and use the alias, sometimes it won't use the alias.
2024-05-30 16:36:21 +0200Guest5837(~ars23@2a02:2f09:3614:4900:d407:6f69:717f:f669) (Remote host closed the connection)
2024-05-30 16:34:54 +0200 <c_wraith> Some people will also argue that implementation hiding allows for implementation changes more easily, but I don't really buy that in many cases. If you're changing the implementation in a way that's visible in the type, you're probably also changing enough of the API that things will need to adapt anyway.
2024-05-30 16:33:41 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 240 seconds)
2024-05-30 16:31:16 +0200 <lxsameer> c_wraith: could you please elaborate?
2024-05-30 16:28:31 +0200 <c_wraith> the two main reasons are error messages can be more specific and you can control the api more precisely.
2024-05-30 16:26:49 +0200 <lxsameer> Hey folks, I see people using `newtype App m a = App {unApp :: ReaderT Env m a}` to pass an static Env around. Why not `type App m a = ReaderT Env m a`?
2024-05-30 16:26:48 +0200segfaultfizzbuzz(~segfaultf@23-93-189-95.fiber.dynamic.sonic.net) (Read error: Connection reset by peer)
2024-05-30 16:19:48 +0200euleritian(~euleritia@77.22.252.56)
2024-05-30 16:15:59 +0200euleritian(~euleritia@dynamic-176-003-083-232.176.3.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-30 16:05:09 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
2024-05-30 16:04:26 +0200Guest2112(~ars23@79.114.53.79) (Ping timeout: 252 seconds)
2024-05-30 16:01:15 +0200ars23Guest5837
2024-05-30 16:00:51 +0200ars23(~ars23@2a02:2f09:3614:4900:d407:6f69:717f:f669)
2024-05-30 15:58:15 +0200ars23Guest2112
2024-05-30 15:57:51 +0200ars23(~ars23@79.114.53.79)
2024-05-30 15:57:07 +0200ars23(~ars23@user/ars23) (Ping timeout: 256 seconds)
2024-05-30 15:56:01 +0200euleritian(~euleritia@dynamic-176-003-083-232.176.3.pool.telefonica.de)
2024-05-30 15:55:20 +0200CiaoSen(~Jura@2a05:5800:2da:8d00:e6b9:7aff:fe80:3d03) (Quit: CiaoSen)
2024-05-30 15:54:45 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds)
2024-05-30 15:53:06 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net)
2024-05-30 15:52:05 +0200segfaultfizzbuzz(~segfaultf@23-93-189-95.fiber.dynamic.sonic.net)