IRCBrowse

2023/09/19

2023-09-19 00:01:16 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
2023-09-19 00:02:07 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 264 seconds)
2023-09-19 00:05:22 +0200coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-09-19 00:11:50 +0200sord937(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2023-09-19 00:12:48 +0200Sgeo(~Sgeo@user/sgeo)
2023-09-19 00:15:15 +0200SheShE
2023-09-19 00:17:37 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-09-19 00:20:03 +0200ShEShe
2023-09-19 00:29:05 +0200mysl(~mysl@user/mysl) (Ping timeout: 240 seconds)
2023-09-19 00:37:41 +0200 <Axman6> Can anyone name a better documented library than formatting? https://hackage.haskell.org/package/formatting look at this, Alex (et al.) has done an amazing job
2023-09-19 00:40:13 +0200pavonia(~user@user/siracusa)
2023-09-19 00:40:48 +0200 <monochrom> Perhaps lens, if you measure the ratio how-good-it-is : intrinsically-how-hard-to-doc-at-all
2023-09-19 00:41:45 +0200 <Axman6> yeah it would have to be up there too
2023-09-19 00:45:52 +0200fweht(uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2023-09-19 00:47:50 +0200 <Axman6> Oh man, I totally should have read those docs I'm going on about, I would've learned about viewed, which I reinvented a few weeks ago
2023-09-19 00:49:36 +0200wroathe(~wroathe@user/wroathe)
2023-09-19 00:51:59 +0200wroathe(~wroathe@user/wroathe) (Client Quit)
2023-09-19 00:52:08 +0200wroathe(~wroathe@user/wroathe)
2023-09-19 00:57:03 +0200bsima(~bsima@2604:a880:400:d0::19f1:7001) (Server closed connection)
2023-09-19 00:57:23 +0200bsima(~bsima@2604:a880:400:d0::19f1:7001)
2023-09-19 01:07:35 +0200libertyprime(~libertypr@203.96.203.44) (Ping timeout: 240 seconds)
2023-09-19 01:10:35 +0200emmanuelux(~emmanuelu@user/emmanuelux) (Ping timeout: 240 seconds)
2023-09-19 01:12:06 +0200 <jackdk> wow, that's a cool combinator
2023-09-19 01:14:33 +0200privacy(~privacy@47.219.84.6)
2023-09-19 01:15:08 +0200 <Axman6> jackdk: should remind you of the convo we had a few weeks elsewhere, about adding a premap combinator
2023-09-19 01:16:02 +0200 <jackdk> Axman6: the one I wanted to call `>%<`? Is that `accessed`?
2023-09-19 01:16:24 +0200 <Axman6> yeah, i wanted an infix accessed
2023-09-19 01:17:00 +0200Inst(~Inst@120.244.192.250)
2023-09-19 01:18:33 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 01:23:43 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 264 seconds)
2023-09-19 01:35:57 +0200libertyprime(~libertypr@210.55.232.12)
2023-09-19 01:36:02 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.)
2023-09-19 01:47:15 +0200shaprhops randomly
2023-09-19 01:47:57 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 244 seconds)
2023-09-19 01:52:39 +0200libertyprime(~libertypr@210.55.232.12) (Ping timeout: 240 seconds)
2023-09-19 01:57:50 +0200 <Axman6> Woah now, we'll have none of that impurity around here, thank you very much!
2023-09-19 01:58:11 +0200 <jackdk> shapr hops exactly four times, then another four, then another four, ...
2023-09-19 01:58:26 +0200 <Axman6> much better
2023-09-19 01:58:48 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 244 seconds)
2023-09-19 01:59:11 +0200 <geekosaur> IO Shapr
2023-09-19 01:59:26 +0200 <meejah> +1 for "any prose docs at all" -- that's one thing I find "many" Haskell libs don't have (or need more of) ... as a beginner ;)
2023-09-19 02:00:16 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2023-09-19 02:02:26 +0200 <EvanR> as long as the type signature is somewhere near the top of the page of docs for function f
2023-09-19 02:02:48 +0200 <EvanR> big docs for function or method in other languages are sometimes hard to see or aren't there at all
2023-09-19 02:02:56 +0200 <EvanR> type signature that is
2023-09-19 02:06:21 +0200 <jackdk> The trouble is when the type signature is something like `Lens (Producer a' m x) (Producer a m x) (FreeT (Producer a' m) m x) (FreeT (Producer a m) m x)`, a fair amount of mental bootstrapping is required to get into the library's space at all
2023-09-19 02:07:41 +0200geekosaurgot that… he thinks
2023-09-19 02:08:39 +0200AlexZenon(~alzenon@178.34.160.78) (Ping timeout: 240 seconds)
2023-09-19 02:09:42 +0200libertyprime(~libertypr@210.55.232.12)
2023-09-19 02:10:04 +0200libertyprime(~libertypr@210.55.232.12) (Client Quit)
2023-09-19 02:10:10 +0200Alex_test(~al_test@178.34.160.78) (Ping timeout: 244 seconds)
2023-09-19 02:13:17 +0200AlexZenon(~alzenon@178.34.160.78)
2023-09-19 02:18:03 +0200geekosaur[c](sid609282@xmonad/geekosaur) (Server closed connection)
2023-09-19 02:18:13 +0200geekosaur[c](sid609282@xmonad/geekosaur)
2023-09-19 02:18:22 +0200 <geekosaur> meep?
2023-09-19 02:18:42 +0200Alex_test(~al_test@178.34.160.78)
2023-09-19 02:18:50 +0200 <EvanR> didn't hear anything
2023-09-19 02:21:05 +0200Inst(~Inst@120.244.192.250) (Ping timeout: 240 seconds)
2023-09-19 02:21:24 +0200 <geekosaur> irccloud just disconnected and reconnected my puppet for unknown reasons. you won't have noticed if you have joins/parts silenced
2023-09-19 02:24:03 +0200glowcoil(sid3405@id-3405.tinside.irccloud.com) (Server closed connection)
2023-09-19 02:24:12 +0200glowcoil(sid3405@id-3405.tinside.irccloud.com)
2023-09-19 02:25:55 +0200emmanuelux(~emmanuelu@user/emmanuelux)
2023-09-19 02:30:27 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2023-09-19 02:43:45 +0200smoothdev(~smoothdev@2a01:e0a:279:fb20:34b3:e617:3265:c11f) (Quit: smoothdev)
2023-09-19 02:45:40 +0200 <institor> geekosaur: yes libera has apparently been "shedding" connections recently
2023-09-19 02:45:50 +0200 <institor> i also received "Server closed connection" recently
2023-09-19 02:46:02 +0200 <institor> not sure why
2023-09-19 02:46:09 +0200 <Axman6> Should've written the server in Haskell
2023-09-19 02:56:38 +0200emmanuelux(~emmanuelu@user/emmanuelux) (Quit: au revoir)
2023-09-19 03:01:42 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-09-19 03:01:42 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-09-19 03:01:42 +0200wroathe(~wroathe@user/wroathe)
2023-09-19 03:06:59 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 03:10:39 +0200jargon(~jargon@184.101.67.95)
2023-09-19 03:11:37 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2023-09-19 03:15:27 +0200bontaq(~user@ool-45707d2c.dyn.optonline.net) (Ping timeout: 240 seconds)
2023-09-19 03:23:07 +0200hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 264 seconds)
2023-09-19 03:27:03 +0200bradparker(sid262931@id-262931.uxbridge.irccloud.com) (Server closed connection)
2023-09-19 03:27:12 +0200bradparker(sid262931@id-262931.uxbridge.irccloud.com)
2023-09-19 03:35:27 +0200bliminse(~bliminse@user/bliminse) (Ping timeout: 240 seconds)
2023-09-19 03:36:10 +0200hugo(znc@verdigris.lysator.liu.se)
2023-09-19 03:37:43 +0200bliminse(~bliminse@user/bliminse)
2023-09-19 03:40:15 +0200otto_s(~user@p5de2f2af.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2023-09-19 03:42:14 +0200otto_s(~user@p5de2f287.dip0.t-ipconnect.de)
2023-09-19 03:45:14 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 244 seconds)
2023-09-19 03:46:05 +0200bilegeek(~bilegeek@2600:1008:b04f:99ac:7630:f7e4:827e:bff6)
2023-09-19 03:46:12 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-09-19 03:46:23 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-09-19 03:49:23 +0200Inst(~Inst@120.244.192.250)
2023-09-19 03:50:07 +0200danse-nr3__(~francesco@rm-19-21-9.service.infuturo.it)
2023-09-19 03:50:55 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 244 seconds)
2023-09-19 03:57:41 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer)
2023-09-19 04:00:55 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 264 seconds)
2023-09-19 04:04:08 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a5af:6cb4:7eeb:d04f) (Remote host closed the connection)
2023-09-19 04:04:24 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a5af:6cb4:7eeb:d04f)
2023-09-19 04:08:56 +0200jargon(~jargon@184.101.67.95) (Remote host closed the connection)
2023-09-19 04:27:08 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-09-19 04:27:08 +0200finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-09-19 04:27:08 +0200finn_elijaFinnElija
2023-09-19 04:28:49 +0200codaraxis___(~codaraxis@user/codaraxis)
2023-09-19 04:29:02 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-09-19 04:29:24 +0200Sgeo(~Sgeo@user/sgeo)
2023-09-19 04:32:43 +0200codaraxis__(~codaraxis@user/codaraxis) (Ping timeout: 264 seconds)
2023-09-19 04:34:24 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 246 seconds)
2023-09-19 04:40:05 +0200td_(~td@i5387090C.versanet.de) (Ping timeout: 240 seconds)
2023-09-19 04:41:52 +0200td_(~td@i5387090C.versanet.de)
2023-09-19 04:42:05 +0200rekahsoft(~rekahsoft@bras-base-orllon1122w-grc-30-70-51-230-102.dsl.bell.ca)
2023-09-19 04:50:28 +0200libertyprime(~libertypr@125-237-102-54-adsl.sparkbb.co.nz)
2023-09-19 04:51:03 +0200jonrh(sid5185@id-5185.ilkley.irccloud.com) (Server closed connection)
2023-09-19 04:51:13 +0200jonrh(sid5185@id-5185.ilkley.irccloud.com)
2023-09-19 04:52:55 +0200rekahsoft(~rekahsoft@bras-base-orllon1122w-grc-30-70-51-230-102.dsl.bell.ca) (Ping timeout: 244 seconds)
2023-09-19 04:54:47 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 04:55:24 +0200libertyprime(~libertypr@125-237-102-54-adsl.sparkbb.co.nz) (Quit: leaving)
2023-09-19 04:59:32 +0200sm(~sm@plaintextaccounting/sm)
2023-09-19 05:03:03 +0200T_S____(sid501726@id-501726.uxbridge.irccloud.com) (Server closed connection)
2023-09-19 05:03:17 +0200T_S____(sid501726@id-501726.uxbridge.irccloud.com)
2023-09-19 05:04:12 +0200sm(~sm@plaintextaccounting/sm) (Ping timeout: 260 seconds)
2023-09-19 05:05:03 +0200danse-nr3__(~francesco@rm-19-21-9.service.infuturo.it) (Remote host closed the connection)
2023-09-19 05:09:27 +0200hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds)
2023-09-19 05:14:10 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 252 seconds)
2023-09-19 05:14:56 +0200hugo(znc@verdigris.lysator.liu.se)
2023-09-19 05:15:03 +0200sclv(sid39734@haskell/developer/sclv) (Server closed connection)
2023-09-19 05:15:13 +0200sclv(sid39734@haskell/developer/sclv)
2023-09-19 05:16:49 +0200sm(~sm@plaintextaccounting/sm)
2023-09-19 05:29:17 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2023-09-19 05:29:52 +0200Inst(~Inst@120.244.192.250) (Ping timeout: 260 seconds)
2023-09-19 05:35:05 +0200sm(~sm@plaintextaccounting/sm) (Ping timeout: 240 seconds)
2023-09-19 05:35:34 +0200Inst(~Inst@120.244.192.250)
2023-09-19 05:42:17 +0200haskl(~haskl@user/haskl) (Read error: Connection reset by peer)
2023-09-19 05:44:21 +0200libertyprime(~libertypr@203.96.203.44)
2023-09-19 05:44:25 +0200haskl(~haskl@user/haskl)
2023-09-19 05:46:49 +0200haskl(~haskl@user/haskl) (Read error: Connection reset by peer)
2023-09-19 05:48:47 +0200haskl(~haskl@user/haskl)
2023-09-19 06:00:10 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net)
2023-09-19 06:00:58 +0200aforemny_(~aforemny@i59F516CB.versanet.de)
2023-09-19 06:01:19 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net) (Client Quit)
2023-09-19 06:02:09 +0200aforemny(~aforemny@i59f516ff.versanet.de) (Ping timeout: 244 seconds)
2023-09-19 06:05:35 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-09-19 06:12:59 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 246 seconds)
2023-09-19 06:19:05 +0200Square3(~Square4@user/square) (Ping timeout: 240 seconds)
2023-09-19 06:19:11 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net)
2023-09-19 06:21:02 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net) (Client Quit)
2023-09-19 06:25:33 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2023-09-19 06:26:09 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2023-09-19 06:29:16 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net)
2023-09-19 06:30:42 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net) (Client Quit)
2023-09-19 06:38:08 +0200bilegeek(~bilegeek@2600:1008:b04f:99ac:7630:f7e4:827e:bff6) (Quit: Leaving)
2023-09-19 06:42:47 +0200libertyprime(~libertypr@203.96.203.44) (Ping timeout: 260 seconds)
2023-09-19 06:45:52 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 06:50:04 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 06:50:21 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-09-19 06:50:37 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Client Quit)
2023-09-19 06:52:27 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-09-19 06:53:30 +0200libertyprime(~libertypr@203.96.203.44)
2023-09-19 06:53:42 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2023-09-19 06:54:31 +0200acidjnk(~acidjnk@p200300d6e7072f09040c85b81d4e368d.dip0.t-ipconnect.de)
2023-09-19 06:57:27 +0200Inst(~Inst@120.244.192.250) (Ping timeout: 240 seconds)
2023-09-19 07:01:08 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2023-09-19 07:01:25 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2023-09-19 07:03:15 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-09-19 07:03:15 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-09-19 07:03:15 +0200wroathe(~wroathe@user/wroathe)
2023-09-19 07:05:28 +0200Inst(~Inst@120.244.192.250)
2023-09-19 07:09:17 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 07:11:35 +0200Square3(~Square4@user/square)
2023-09-19 07:16:37 +0200hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds)
2023-09-19 07:17:28 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 07:19:18 +0200 <Inst> is Cabal a strong Haskell codebase?
2023-09-19 07:19:32 +0200michalz(~michalz@185.246.207.215)
2023-09-19 07:19:34 +0200 <Inst> I'm having usual ambivalence about going through the codebase, for instance, I noticed a bunch of import Prelude () declares
2023-09-19 07:20:07 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 264 seconds)
2023-09-19 07:20:36 +0200 <davean> Inst: what about that?
2023-09-19 07:20:59 +0200 <Inst> that seems to be actually -XNoImplicitPrelude in non-language form, but importing instances?
2023-09-19 07:21:33 +0200 <davean> Well you can't not import instances.
2023-09-19 07:21:45 +0200 <davean> And yes, because language extensions are definitionally non-portable
2023-09-19 07:23:06 +0200 <Inst> well, the library enables type operators
2023-09-19 07:23:43 +0200 <int-e> ...what is the goal here...
2023-09-19 07:24:29 +0200 <Inst> what is goal referring to?
2023-09-19 07:24:40 +0200 <int-e> a purpose
2023-09-19 07:24:48 +0200 <Inst> my goal?
2023-09-19 07:25:19 +0200 <int-e> yes
2023-09-19 07:26:33 +0200 <Inst> just to understand Cabal
2023-09-19 07:26:53 +0200 <Inst> I need to look into the parser, but Cabal is beautiful in its own way, a 200k LOC (possibly 100K SLOC) codebase
2023-09-19 07:28:05 +0200 <int-e> so how does wondering aobut `import Prelude ()` vs NoImplicitPrelude help you with that?
2023-09-19 07:29:30 +0200 <Inst> I'm just trying to assess the quality of the codebase, import Prelude () is a weird idiom
2023-09-19 07:29:30 +0200hugo(znc@verdigris.lysator.liu.se)
2023-09-19 07:30:12 +0200 <int-e> Well, not really. It's pure Haskell rather than a weird GHC specific extension.
2023-09-19 07:30:29 +0200 <int-e> And it avoids clashing identifiers just fine.
2023-09-19 07:30:38 +0200 <Inst> the way I understand it, import declarations are not stateful
2023-09-19 07:30:54 +0200 <Inst> that is to say, they don't override previous import declarations
2023-09-19 07:30:58 +0200 <int-e> (Cabal is old enough that it was originally written to work with other Haskell implementations.)
2023-09-19 07:31:07 +0200 <Inst> yeah, UHC is mentioned
2023-09-19 07:31:26 +0200 <Inst> but I guess the point is that implicit prelude must be something defined by Haskell report
2023-09-19 07:31:36 +0200 <Inst> and import Prelude () overrides the implicit Prelude declaration
2023-09-19 07:31:43 +0200 <int-e> There is no previous import of Prelude... Prelude is *only* implicitely imported if it's not imported explicitly.
2023-09-19 07:32:01 +0200 <davean> Inst: Thats specificly covered in the report
2023-09-19 07:32:11 +0200 <davean> have you not read the report?
2023-09-19 07:32:17 +0200CiaoSen(~Jura@2a05:5800:29b:e900:664b:f0ff:fe37:9ef)
2023-09-19 07:32:19 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-09-19 07:32:46 +0200 <Inst> Honestly, no, I've skimmed it, I used to try to go through Haskell report when I was just starting out
2023-09-19 07:33:17 +0200 <Inst> but at that stage, I was unable to parse it profitably, so
2023-09-19 07:34:27 +0200 <davean> https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1110005.6
2023-09-19 07:34:47 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-09-19 07:35:10 +0200 <Inst> yeah, you're on cabal team
2023-09-19 07:35:14 +0200 <Inst> what you do is to import a custom prelude
2023-09-19 07:35:53 +0200 <int-e> to what end?
2023-09-19 07:36:57 +0200 <Inst> myself or cabal team?
2023-09-19 07:37:21 +0200coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-09-19 07:37:39 +0200 <int-e> well you seem to be trying to talk on behalf on the cabal team there
2023-09-19 07:37:47 +0200 <int-e> so yourself
2023-09-19 07:38:40 +0200 <Inst> "What you do is to import a custom prelude" (They're already importing a custom prelude)
2023-09-19 07:38:54 +0200 <Inst> I got confused for a bit because I see use of fmap operator, and there's no explicit import.
2023-09-19 07:39:06 +0200 <Inst> Not an imperative, a descriptive statement.
2023-09-19 07:39:33 +0200 <davean> You still have to deal with Prelude being implicite. You don't know whats in an arbitrary prelude. This is how you safely work with various haskell implimentations
2023-09-19 07:39:48 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 244 seconds)
2023-09-19 07:40:06 +0200 <int-e> Ah, you must be talking about Distribution.Compat.Prelude stuff.
2023-09-19 07:41:26 +0200 <int-e> So this *is* a custom prelude, for coping with the evolution of and different versions of base
2023-09-19 07:41:49 +0200 <Inst> I'm not sure if my bringing up this conversation topic is unwelcome?
2023-09-19 07:41:53 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-09-19 07:42:11 +0200 <Inst> Like I said, I find Cabal fascinating, GHC is definitely going to be beyond my ken for quite some time
2023-09-19 07:42:30 +0200 <Inst> also, GHC has some interesting totally redundant do keywords
2023-09-19 07:42:47 +0200 <int-e> Regardless, there's nothing wrong with or smelly about `import Prelude ()`.
2023-09-19 07:43:17 +0200 <Inst> Well, it's my fault, I misunderstood the idiom.
2023-09-19 07:44:11 +0200 <int-e> I've used "superfluous" `do` myself for uniformity when writing monadic code.
2023-09-19 07:44:35 +0200Square3(~Square4@user/square) (Ping timeout: 240 seconds)
2023-09-19 07:44:41 +0200 <Inst> I also got recommended to try pandoc code base
2023-09-19 07:44:53 +0200 <Inst> as an example of a canonical "this is professional, high-quality Haskell that in theory can be accessible"
2023-09-19 07:45:13 +0200 <Inst> cabal project has tautologically adroit usage of cabal,project and *.cabal
2023-09-19 07:45:45 +0200 <Inst> https://gitlab.haskell.org/ghc/ghc/-/blob/master/ghc/Main.hs#146 <---note the do usage here
2023-09-19 07:46:13 +0200mysl(~mysl@user/mysl)
2023-09-19 07:47:10 +0200 <monochrom> This is interesting. We keep hearing the advice "read some real code and learn from it". I see now what's wrong with that.
2023-09-19 07:47:31 +0200 <monochrom> Receivers of that advice interpret it as "in a vacuum".
2023-09-19 07:47:58 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-09-19 07:49:26 +0200 <monochrom> But real code is never in a vacuum. Firstly it serves a purpose (or even multiple purposes) and that affects a lot of choices made. Secondly it depends on what kind of people are intended to be collaborators. Thirdly it also depends on a lot of incidental or even accidental constraints like "this has to work for 5 incompatible compilers". etc etc etc.
2023-09-19 07:51:48 +0200 <Inst> That's sort of the "beauty" of it, no? That is to say, you can read and understand the context of the code from the code structure itself.
2023-09-19 07:52:47 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
2023-09-19 07:53:24 +0200 <davean> Inst: Are you sure you're right?
2023-09-19 07:53:52 +0200 <davean> Also I figured out your GHC do exmaple, its pretty obvious why it is that way
2023-09-19 07:54:32 +0200dtman34(~dtman34@2601:447:d000:93c9:e3fb:cd8e:9d7a:53c5) (Ping timeout: 260 seconds)
2023-09-19 07:55:06 +0200 <Inst> i'm assuming it's to make clear that it's quoting a monadic action
2023-09-19 07:55:14 +0200 <davean> Nope
2023-09-19 07:55:30 +0200 <davean> Inst: your GHC thing first off A) there absolutely is a reason that do is there B) your claim above is somewhat disproven by this example of yours
2023-09-19 07:55:49 +0200 <davean> look at the commit that introduces it.
2023-09-19 07:56:10 +0200 <davean> that do is *vestigial* it *was* required when that code was writen
2023-09-19 07:56:22 +0200 <davean> the code has changed, but they didn't restructure other code that had no reason to be touched
2023-09-19 07:57:05 +0200 <davean> it use to "exitWith ExitSuccess" after the case.
2023-09-19 07:58:03 +0200 <davean> Its vestigial, not redundent
2023-09-19 07:59:51 +0200 <int-e> I'm so confused, aren't we talking about this `do`? https://gitlab.haskell.org/ghc/ghc/-/commit/1c1980863810c6b1bbed2ebbcce882a0f9144ade#519f43ef6302b…
2023-09-19 08:00:53 +0200 <int-e> Which really isn't required. (I'd also prefer it to be at the end of the previous line, but whatever)
2023-09-19 08:01:33 +0200 <davean> Thats the removal, not the introdxuction, look in the deleted lines
2023-09-19 08:01:56 +0200 <int-e> AH
2023-09-19 08:01:57 +0200 <int-e> thanks
2023-09-19 08:02:37 +0200 <Inst> So, I'll ask the obvious question: why hasn't it been removed?
2023-09-19 08:02:48 +0200 <int-e> (not sure why I didn't do that on my own. sigh.)
2023-09-19 08:02:53 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-09-19 08:03:22 +0200 <int-e> because it was there and doesn't hurt
2023-09-19 08:03:23 +0200 <davean> Inst: Its formally the same - why make merges hard?
2023-09-19 08:04:13 +0200 <Inst> I hope I haven't been too irritating in getting you to educate me.
2023-09-19 08:04:14 +0200 <int-e> Could it have been removed with that commit? Sure. But it wasn't.
2023-09-19 08:04:34 +0200 <int-e> . o O ( That hope is entirely unfounded. )
2023-09-19 08:05:14 +0200 <davean> I mean who would anyone making the change that commit did look for that do to remove it anyway?
2023-09-19 08:05:17 +0200 <Inst> Explicitly, I've been irritating with this question?
2023-09-19 08:05:22 +0200 <davean> one of the properties of haskell is we don't have to
2023-09-19 08:05:33 +0200 <int-e> davean's point explains why it hasn't been removed in the meantime (assuming anyone even noticed it)
2023-09-19 08:10:08 +0200 <Inst> I... don't get it, tbh, have I caused offense?
2023-09-19 08:10:14 +0200 <davean> Anyway, I think this is a good example of why reading the code alone doesn't work.
2023-09-19 08:10:46 +0200chele(~chele@user/chele)
2023-09-19 08:10:50 +0200 <Inst> via sclv, I'm told Cabal team is overworked, so I wouldn't have been surprised if QC got cut, and rae I think reported that GHC's code base was on shaky foundations as to why he couldn't move ahead with Dependent Haskell
2023-09-19 08:11:27 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 260 seconds)
2023-09-19 08:11:50 +0200hpc(~juzz@ip98-169-35-163.dc.dc.cox.net) (Ping timeout: 244 seconds)
2023-09-19 08:12:29 +0200 <davean> Inst: I don't think anymore minds your questions
2023-09-19 08:13:53 +0200hpc(~juzz@ip98-169-35-163.dc.dc.cox.net)
2023-09-19 08:14:20 +0200 <Inst> So, I mean, on one hand, the experience and skill of the collaborators is immense, on the other hand, it's a real world project; i.e, it's closer to a repair shop or lab in operation than "FizzBuzz Enterprise Edition", which is some overpolished toy intended as a joke.
2023-09-19 08:15:11 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2023-09-19 08:15:53 +0200sm(~sm@plaintextaccounting/sm)
2023-09-19 08:16:03 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2023-09-19 08:18:03 +0200idnar(sid12240@debian/mithrandi) (Server closed connection)
2023-09-19 08:18:14 +0200idnar(sid12240@debian/mithrandi)
2023-09-19 08:18:25 +0200 <davean> I would not call "FizzBuzz Enterprise Edition" polished
2023-09-19 08:20:04 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net)
2023-09-19 08:22:56 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-09-19 08:23:54 +0200 <Inst> What would you use as an example instead, then?
2023-09-19 08:24:42 +0200 <Inst> And, if it's not too irritating, is there any project / library you might recommend as a platonic ideal of a Haskell project?
2023-09-19 08:25:17 +0200 <davean> "FizzBuzz Enterprise Edition" is litterly *miss application of patterns people see*
2023-09-19 08:27:49 +0200 <institor> fizzbuzz enterprise edition is like using a centrifuge to prepare a solution of sugar and tap water
2023-09-19 08:28:22 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 260 seconds)
2023-09-19 08:28:28 +0200 <monochrom> Wait, so this Fizzbuzz Enterprise Edition is not made up?
2023-09-19 08:28:41 +0200 <institor> https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
2023-09-19 08:29:04 +0200 <institor> i've poked around this repo multiple times and i still can't tell where the actual logic is
2023-09-19 08:29:55 +0200 <jackdk> My favourite over-engineered fizzbuzz is https://themonadreader.files.wordpress.com/2014/04/fizzbuzz.pdf , which also manages to be quite instructive
2023-09-19 08:29:56 +0200 <davean> Its a litteral *joke*
2023-09-19 08:31:15 +0200 <davean> "So badly done its funny"
2023-09-19 08:31:23 +0200 <monochrom> Heh
2023-09-19 08:32:12 +0200 <Inst> I don't know Java, I had heard of the package but assumed it was overengineered and overpolished, in reality, it's only overly contrived.
2023-09-19 08:32:41 +0200 <institor> why not read the XMonad source or something
2023-09-19 08:33:01 +0200 <institor> it's written in haskell, it's not a very large codebase, and it's built to be user-extensible so you can actually work with the codebase and do something with it
2023-09-19 08:33:09 +0200 <Inst> Would you recommend the XMonad project, then? I had heard they don't have the labor available to move it to Wayland, unfortunately.
2023-09-19 08:33:10 +0200 <institor> instead of passively consuming the source
2023-09-19 08:33:36 +0200 <Inst> Ehhh, in my case, I'm still trying to build a parser for my project for cabal files.
2023-09-19 08:34:16 +0200 <Inst> Exact parser, rather. That means that I need to understand how the cabal parser works, since it was reported that it's, ummm, unpredictable with the rarely-used braces option.
2023-09-19 08:34:17 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 08:34:21 +0200sord937(~sord937@gateway/tor-sasl/sord937)
2023-09-19 08:34:46 +0200 <Inst> So reading over Cabal, as monochro m mentioned, I get an idea of the context in which the parser exists.
2023-09-19 08:35:02 +0200 <institor> i don't know if cabal is really exemplary software
2023-09-19 08:35:08 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net) (Quit: smoothdev)
2023-09-19 08:35:26 +0200 <Inst> Or, if it's reasonable for me to aspire to contribute to it within the span of a year.
2023-09-19 08:36:14 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net)
2023-09-19 08:36:48 +0200 <institor> have you gone through the issue tracker
2023-09-19 08:37:17 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 08:37:48 +0200 <Inst> Or the pull release queue?
2023-09-19 08:37:55 +0200 <Inst> ugh
2023-09-19 08:38:02 +0200 <Inst> pull request
2023-09-19 08:38:05 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 08:38:16 +0200 <institor> sometimes they label good starter issues
2023-09-19 08:38:19 +0200 <institor> just pick one and go with it
2023-09-19 08:38:34 +0200codaraxis__(~codaraxis@user/codaraxis)
2023-09-19 08:38:40 +0200 <Inst> Thanks for the suggestion.
2023-09-19 08:42:15 +0200codaraxis___(~codaraxis@user/codaraxis) (Ping timeout: 246 seconds)
2023-09-19 08:42:22 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2023-09-19 08:44:55 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:4096:dbe8:3b65:83c5)
2023-09-19 08:50:53 +0200dtman34(~dtman34@2601:447:d000:93c9:a832:b3a1:c57:ffa2)
2023-09-19 08:51:03 +0200integral(sid296274@user/integral) (Server closed connection)
2023-09-19 08:51:16 +0200integral(sid296274@user/integral)
2023-09-19 08:52:17 +0200michalz(~michalz@185.246.207.215) (Ping timeout: 260 seconds)
2023-09-19 08:53:08 +0200 <Inst> but, honestly, despite any issues with Cabal codebase, I still find it beautiful
2023-09-19 08:54:46 +0200danza(~francesco@na-19-75-108.service.infuturo.it)
2023-09-19 08:57:53 +0200_0xa(~user@user/0xa/x-3134607)
2023-09-19 08:58:08 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2023-09-19 08:58:16 +0200ursa-major(~ursa-majo@37.19.210.38)
2023-09-19 08:58:33 +0200fendor(~fendor@2a02:8388:1640:be00:aab:1226:f274:5021)
2023-09-19 08:59:34 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-09-19 09:02:38 +0200 <sm> that's the spirit!
2023-09-19 09:03:05 +0200 <sm> #hackage is where the Cabal devs hang out, by the way
2023-09-19 09:04:16 +0200 <Inst> I'm mirrored via Matrix.
2023-09-19 09:06:34 +0200cfricke(~cfricke@user/cfricke)
2023-09-19 09:07:46 +0200sabino(~sabino@user/sabino) (Quit: Lambda _ -> x)
2023-09-19 09:09:01 +0200aforemny_aforemny
2023-09-19 09:12:15 +0200sm(~sm@plaintextaccounting/sm) (Quit: sm)
2023-09-19 09:16:57 +0200_0xa(~user@user/0xa/x-3134607) (Remote host closed the connection)
2023-09-19 09:18:32 +0200danza(~francesco@na-19-75-108.service.infuturo.it) (Ping timeout: 260 seconds)
2023-09-19 09:19:11 +0200fendor(~fendor@2a02:8388:1640:be00:aab:1226:f274:5021) (Remote host closed the connection)
2023-09-19 09:20:30 +0200fendor(~fendor@2a02:8388:1640:be00:aab:1226:f274:5021)
2023-09-19 09:30:03 +0200conjunctive(sid433686@id-433686.helmsley.irccloud.com) (Server closed connection)
2023-09-19 09:30:13 +0200conjunctive(sid433686@id-433686.helmsley.irccloud.com)
2023-09-19 09:36:03 +0200cbarrett(sid192934@id-192934.helmsley.irccloud.com) (Server closed connection)
2023-09-19 09:36:12 +0200cbarrett(sid192934@id-192934.helmsley.irccloud.com)
2023-09-19 09:43:04 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-09-19 09:46:52 +0200acidjnk(~acidjnk@p200300d6e7072f09040c85b81d4e368d.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-09-19 09:47:16 +0200acidjnk(~acidjnk@p200300d6e7072f09040c85b81d4e368d.dip0.t-ipconnect.de)
2023-09-19 09:56:38 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-09-19 10:02:07 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 264 seconds)
2023-09-19 10:03:31 +0200gmg(~user@user/gehmehgeh)
2023-09-19 10:11:39 +0200 <Inst> this is honestly so fascinating
2023-09-19 10:12:37 +0200 <Inst> here, someone's using long type variables idiom, whereas in other parts of the codebase, it's traditional haskell single letter type variables
2023-09-19 10:13:13 +0200jackneill__(~Jackneill@20014C4E1E062E00A473EFF2719A535F.dsl.pool.telekom.hu)
2023-09-19 10:13:40 +0200__monty__(~toonn@user/toonn)
2023-09-19 10:26:06 +0200phma(phma@2001:5b0:215a:ad98:b113:d71c:5609:dd28) (Read error: Connection reset by peer)
2023-09-19 10:26:30 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 10:26:55 +0200phma(~phma@host-67-44-208-47.hnremote.net)
2023-09-19 10:31:46 +0200ubert(~Thunderbi@91.141.40.168.wireless.dyn.drei.com)
2023-09-19 10:33:03 +0200snek(sid280155@id-280155.lymington.irccloud.com) (Server closed connection)
2023-09-19 10:33:12 +0200snek(sid280155@id-280155.lymington.irccloud.com)
2023-09-19 10:34:47 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 10:36:03 +0200iphy(sid67735@id-67735.lymington.irccloud.com) (Server closed connection)
2023-09-19 10:36:13 +0200iphy(sid67735@id-67735.lymington.irccloud.com)
2023-09-19 10:38:48 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 10:39:43 +0200danse-nr3(~francesco@rm-19-39-103.service.infuturo.it)
2023-09-19 10:39:49 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-09-19 10:41:19 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a5af:6cb4:7eeb:d04f) (Ping timeout: 245 seconds)
2023-09-19 10:44:21 +0200lottaquestions_(~nick@2607:fa49:503d:b200:f390:54fb:be02:a16f) (Quit: Konversation terminated!)
2023-09-19 10:44:44 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-09-19 10:45:03 +0200Guest3051(sid1055@id-1055.tinside.irccloud.com) (Server closed connection)
2023-09-19 10:45:34 +0200Guest3051(sid1055@id-1055.tinside.irccloud.com)
2023-09-19 10:48:11 +0200lottaquestions(~nick@2607:fa49:503d:b200:c12f:231b:a760:9783)
2023-09-19 10:48:31 +0200_xor(~xor@ip-50-5-233-250.dynamic.fuse.net) (Quit: Ping timeout (120 seconds))
2023-09-19 10:50:21 +0200_xor(~xor@ip-50-5-233-250.dynamic.fuse.net)
2023-09-19 10:50:54 +0200econo_(uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2023-09-19 10:55:49 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com)
2023-09-19 10:56:43 +0200 <institor> https://degoes.net/articles/insufficiently-polymorphic
2023-09-19 10:59:06 +0200mc47(~mc47@xmonad/TheMC47)
2023-09-19 10:59:41 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net) (Quit: smoothdev)
2023-09-19 11:00:02 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2023-09-19 11:00:38 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net)
2023-09-19 11:06:58 +0200 <[exa]> "descriptive variable names are a code smell" ok whoa I will need to confront pythonfolk with this
2023-09-19 11:07:15 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2023-09-19 11:08:16 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net) (Quit: smoothdev)
2023-09-19 11:09:10 +0200 <dminuoso> [exa]: Yeah, its why I use lsp-mode to automatically rename identifiers to random 3 letter combinations.
2023-09-19 11:09:20 +0200 <dminuoso> Ever since it stopped smelling in my office.
2023-09-19 11:09:32 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-c970-1295-69c1-54c4.res6.spectrum.com) (Ping timeout: 255 seconds)
2023-09-19 11:10:08 +0200 <int-e> (well, former office, they fired me because nobody could make sense of my code)
2023-09-19 11:10:19 +0200 <Inst> also, https://contributors.scala-lang.org/t/is-john-de-goes-a-respected-member-of-the-scala-community/3659
2023-09-19 11:10:20 +0200 <probie> Why do you need random 3 letter combinations? You've got all the alphabets in unicode to work with
2023-09-19 11:10:53 +0200 <int-e> the irony is that we don't even pick random single letter identifiers
2023-09-19 11:11:15 +0200 <int-e> f for function, x or a for a value... n m i j k for integers
2023-09-19 11:11:38 +0200 <int-e> (a bit like Fortran... god is real unless declared integer)
2023-09-19 11:12:10 +0200 <int-e> (I barely know enough Fortran to understand that joke)
2023-09-19 11:12:32 +0200 <probie> but also k for continuations - we've got to keep it ambiguous
2023-09-19 11:14:30 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com)
2023-09-19 11:16:41 +0200 <int-e> Well, the point that when you have a generic function then it is often helpful to write it with general types rather than the concrete types you need is valid.
2023-09-19 11:16:53 +0200marinelli(~weechat@gateway/tor-sasl/marinelli)
2023-09-19 11:17:01 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 11:23:59 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-09-19 11:24:13 +0200 <Inst> actually, sorry
2023-09-19 11:24:32 +0200arahael(~arahael@1.145.97.55)
2023-09-19 11:24:44 +0200 <Inst> i got confused about john de goes; it turns out consensus on him is ambivalent and JDG is just in a feud with Travis Brown
2023-09-19 11:29:51 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com) (Ping timeout: 240 seconds)
2023-09-19 11:35:14 +0200mastarija(~mastarija@141-136-170-127.dsl.iskon.hr)
2023-09-19 11:36:10 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net)
2023-09-19 11:38:20 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-09-19 11:38:49 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net) (Client Quit)
2023-09-19 11:39:36 +0200 <mastarija> Can anyone help me with encoding my recursive Haskell type into Dhall?
2023-09-19 11:39:43 +0200 <mastarija> I have this code over here: https://paste.tomsmeding.com/vCPvIcQg
2023-09-19 11:40:04 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Excess Flood)
2023-09-19 11:40:15 +0200 <mastarija> Basically, I have `Charge` that's recursive. I've succesfully used `Fix` to encode it to `Dhall`.
2023-09-19 11:40:19 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com)
2023-09-19 11:40:40 +0200 <mastarija> Problem is, how do I encode and decode things that aren't recursive but they have `Charge` inside of them.
2023-09-19 11:40:57 +0200 <mastarija> I have this type `Q c` that takes the `Charge` representation.
2023-09-19 11:41:09 +0200 <mastarija> And I have problem expressing it in Dhall.
2023-09-19 11:42:25 +0200 <mastarija> I can successfully extract `Charge` from a `Dhall` file that only returns `Charge`, but I don't know how to decode `Q` from a `Dhall` file that's supposed to return `Q` that has `Charge` within.
2023-09-19 11:43:06 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-09-19 11:46:07 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com) (Ping timeout: 260 seconds)
2023-09-19 11:49:28 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-09-19 11:50:17 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-09-19 11:50:30 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-09-19 11:54:04 +0200sudden(~cat@user/sudden) (Remote host closed the connection)
2023-09-19 11:54:38 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a12d:97a5:968a:df7f)
2023-09-19 11:54:57 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
2023-09-19 11:55:06 +0200mmhat(~mmh@p200300f1c70f84f3ee086bfffe095315.dip0.t-ipconnect.de)
2023-09-19 11:55:10 +0200mmhat(~mmh@p200300f1c70f84f3ee086bfffe095315.dip0.t-ipconnect.de) (Client Quit)
2023-09-19 11:56:07 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 264 seconds)
2023-09-19 12:04:13 +0200ft(~ft@p3e9bc680.dip0.t-ipconnect.de) (Quit: leaving)
2023-09-19 12:05:01 +0200robosexual(~spaceoyst@77.223.88.70)
2023-09-19 12:07:15 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-09-19 12:13:32 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 260 seconds)
2023-09-19 12:19:44 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 255 seconds)
2023-09-19 12:19:46 +0200danse-nr3(~francesco@rm-19-39-103.service.infuturo.it) (Remote host closed the connection)
2023-09-19 12:20:09 +0200danse-nr3(~francesco@rm-19-39-103.service.infuturo.it)
2023-09-19 12:21:07 +0200pavonia(~user@user/siracusa) (Ping timeout: 260 seconds)
2023-09-19 12:22:02 +0200sudden(~cat@user/sudden)
2023-09-19 12:24:20 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-09-19 12:29:52 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 260 seconds)
2023-09-19 12:31:59 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 12:35:57 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 12:38:03 +0200 <tomsmeding> mastarija: not too familiar with Dhall, but in Haskell land, could you not just go 'data ChargeF r = ... ; newtype Charge = Charge (Fix ChargeF) ; data Q = ... Charge ...'?
2023-09-19 12:38:15 +0200CiaoSen(~Jura@2a05:5800:29b:e900:664b:f0ff:fe37:9ef) (Ping timeout: 240 seconds)
2023-09-19 12:38:29 +0200 <tomsmeding> or data Q c = ... ; and then 'Q Charge' is perfectly valid
2023-09-19 12:39:18 +0200 <mastarija> Yeah. That's another problem. Right now I'm more concerned about how to express `Q` in Dhall, I think I'm getting closer to the solution. I actually got it working, now I just need to create a few utilities to make construction easier.
2023-09-19 12:40:05 +0200 <mastarija> Basically, instead of a list of `Charge`s, I need to provide a list of functions `Charge Type -> (Fix : ChargeF Charge -> Charge) -> Charge`.
2023-09-19 12:45:14 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 12:47:44 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-09-19 12:51:34 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection)
2023-09-19 12:51:53 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan)
2023-09-19 12:53:35 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 240 seconds)
2023-09-19 12:57:08 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 12:58:55 +0200arahael(~arahael@1.145.97.55) (Quit: "Gotta fly away!")
2023-09-19 13:03:17 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 13:03:31 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com)
2023-09-19 13:04:00 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 13:04:56 +0200danse-nr3(~francesco@rm-19-39-103.service.infuturo.it) (Ping timeout: 246 seconds)
2023-09-19 13:05:12 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-09-19 13:07:48 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com) (Ping timeout: 240 seconds)
2023-09-19 13:08:03 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 13:11:14 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 13:18:34 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 13:19:38 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 13:25:22 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2023-09-19 13:25:49 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 13:27:21 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 13:27:43 +0200billchenchina(~billchenc@2a0c:b641:7a2:320:ee3e:47ca:6070:d71a)
2023-09-19 13:29:37 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 13:30:34 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2023-09-19 13:30:56 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 13:31:37 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com)
2023-09-19 13:33:32 +0200libertyprime(~libertypr@203.96.203.44) (Quit: leaving)
2023-09-19 13:36:22 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com) (Ping timeout: 260 seconds)
2023-09-19 13:37:41 +0200mastarija(~mastarija@141-136-170-127.dsl.iskon.hr) (Quit: Client closed)
2023-09-19 13:41:53 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 13:45:49 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 13:48:39 +0200vglfr(~vglfr@188.239.201.89) (Ping timeout: 240 seconds)
2023-09-19 13:48:46 +0200danse-nr3(~francesco@rm-19-39-103.service.infuturo.it)
2023-09-19 13:49:42 +0200vglfr(~vglfr@37.73.18.140)
2023-09-19 13:53:17 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2023-09-19 13:55:17 +0200cayley5cayley10
2023-09-19 13:56:29 +0200vglfr(~vglfr@37.73.18.140) (Ping timeout: 255 seconds)
2023-09-19 13:58:44 +0200cayley10cayley5_
2023-09-19 13:59:24 +0200 <dminuoso> Switching from data to newtype for something, would PVP mandate a major version bump?
2023-09-19 14:00:34 +0200vglfr(~vglfr@cli-188-239-201-89.bbn.slav.dn.ua)
2023-09-19 14:00:56 +0200cayley5(~cayley5@user/phileasfogg)
2023-09-19 14:02:06 +0200 <lortabac> dminuoso: it looks like a breaking change to me. Someone might be relying on newtype-specific tools for that type (Coerce etc.)
2023-09-19 14:02:46 +0200 <lortabac> ah sorry it's in the opposite direction (data -> newtype)
2023-09-19 14:03:51 +0200 <dminuoso> Yeah. Ill add the additional information, that while the constructor is exported, its content is only ever produced by my library without any bottoms (assuming lack of bugs). At best it seems it could have only some performance implications
2023-09-19 14:03:52 +0200 <lortabac> I'd still consider it a breaking change, even though the probability of breakage is extremely low
2023-09-19 14:05:10 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 14:11:29 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 14:12:29 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 14:20:38 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net)
2023-09-19 14:21:36 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 14:21:44 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 14:24:44 +0200 <Inst> i hope you don't mind, but we do have function dependency tree visualizers up, right?
2023-09-19 14:26:13 +0200bliminse(~bliminse@user/bliminse) (Quit: leaving)
2023-09-19 14:28:27 +0200danse-nr3_(~francesco@na-19-69-5.service.infuturo.it)
2023-09-19 14:28:34 +0200danse-nr3(~francesco@rm-19-39-103.service.infuturo.it) (Read error: Connection reset by peer)
2023-09-19 14:32:37 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 14:35:42 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 14:41:42 +0200 <Taneb> dminuoso: does the type in question have a Generic instance
2023-09-19 14:41:49 +0200 <dminuoso> Taneb: No
2023-09-19 14:42:00 +0200 <dminuoso> And no Data instance either
2023-09-19 14:42:03 +0200SethTisue(sid14912@id-14912.ilkley.irccloud.com) (Server closed connection)
2023-09-19 14:42:07 +0200 <Taneb> And is the constructor exported?
2023-09-19 14:42:09 +0200 <dminuoso> And actually, I was wrong. Previously the constructor was not even exported.
2023-09-19 14:42:12 +0200SethTisue(sid14912@id-14912.ilkley.irccloud.com)
2023-09-19 14:43:15 +0200foul_owl_(~kerry@185.219.141.160) (Ping timeout: 252 seconds)
2023-09-19 14:45:37 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2023-09-19 14:47:36 +0200sord937(~sord937@gateway/tor-sasl/sord937) (Ping timeout: 246 seconds)
2023-09-19 14:49:03 +0200sord937(~sord937@gateway/tor-sasl/sord937)
2023-09-19 14:50:24 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be)
2023-09-19 14:51:58 +0200 <Taneb> Then I'm pretty sure that's not breaking
2023-09-19 14:51:59 +0200dfg(~dfg@user/dfg) (Quit: I hate quit messages.)
2023-09-19 14:53:52 +0200CiaoSen(~Jura@2a05:5800:29b:e900:664b:f0ff:fe37:9ef)
2023-09-19 14:57:34 +0200foul_owl_(~kerry@174-21-66-189.tukw.qwest.net)
2023-09-19 14:58:07 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:4096:dbe8:3b65:83c5) (Quit: WeeChat 2.8)
2023-09-19 15:07:18 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com)
2023-09-19 15:09:59 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 15:12:09 +0200tremon(~tremon@83.80.159.219)
2023-09-19 15:12:37 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com) (Ping timeout: 260 seconds)
2023-09-19 15:19:11 +0200 <L29Ah> how do i ask cabal what packages do i need to install to satisfy the dependency list of a .cabal package?
2023-09-19 15:21:16 +0200pyooque(~puke@user/puke)
2023-09-19 15:21:16 +0200pukeGuest6095
2023-09-19 15:21:16 +0200Guest6095(~puke@user/puke) (Killed (tungsten.libera.chat (Nickname regained by services)))
2023-09-19 15:21:16 +0200pyooquepuke
2023-09-19 15:21:44 +0200 <dminuoso> L29Ah: Mmm. I always type `cabal build`, ^C when it starts building, and then inspect cabal-plan.
2023-09-19 15:21:55 +0200 <dminuoso> There's probably a few more elegant ways, but its a way at least.
2023-09-19 15:23:49 +0200 <L29Ah> dminuoso: it won't start building as i have offline mode enabled
2023-09-19 15:24:03 +0200 <L29Ah> it will complain about a single missing package and then quit, and i want them all!
2023-09-19 15:24:52 +0200 <haskellbridge> <s​m> cabal build --dry-run
2023-09-19 15:25:32 +0200cfricke(~cfricke@user/cfricke) (Quit: WeeChat 4.0.4)
2023-09-19 15:27:37 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 15:29:25 +0200 <L29Ah> no effect
2023-09-19 15:30:14 +0200 <dminuoso> L29Ah: Will it generate a build plan?
2023-09-19 15:30:26 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com)
2023-09-19 15:30:38 +0200bontaq(~user@ool-45707d2c.dyn.optonline.net)
2023-09-19 15:30:42 +0200mysl(~mysl@user/mysl) (Ping timeout: 260 seconds)
2023-09-19 15:31:37 +0200 <L29Ah> dminuoso: it just fails at the first unknown package it encounters
2023-09-19 15:31:50 +0200 <dminuoso> L29Ah: Yes thats fine.
2023-09-19 15:32:04 +0200 <L29Ah> it doesn't list them all
2023-09-19 15:32:15 +0200 <dminuoso> Have you tried `cabal-plan` like I suggested above?
2023-09-19 15:32:33 +0200 <dminuoso> The only point of causing `cabal build`, is because it spits out its generated build plan inside dist-newstyle
2023-09-19 15:32:36 +0200 <dminuoso> Even if the build fails.
2023-09-19 15:32:46 +0200 <dminuoso> You either look at it manually, or use `cabal-plan` to inspect it.
2023-09-19 15:32:48 +0200 <tomsmeding> (or inspect dist-newstyle/cache/plan.json manually)
2023-09-19 15:33:16 +0200 <tomsmeding> doesn't cabal emit that build plan also if you do `cabal freeze`? Of course that also writes a freeze file
2023-09-19 15:33:23 +0200 <L29Ah> ah sorry i missed that it's a command
2023-09-19 15:33:23 +0200 <dminuoso> Yes it does.
2023-09-19 15:33:31 +0200 <dminuoso> L29Ah: No worry.
2023-09-19 15:33:59 +0200 <tomsmeding> cabal freeze might be a bit neater than 'cabal build; ^C' if you already have a freeze file :p
2023-09-19 15:34:12 +0200 <tomsmeding> oh, and also, the freeze file will of course also contain all the dependencies!
2023-09-19 15:34:39 +0200 <tomsmeding> without needing an external tool (cabal-plan) or to inspect a big json document manually
2023-09-19 15:34:51 +0200 <tomsmeding> L29Ah: ^
2023-09-19 15:34:54 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com) (Ping timeout: 246 seconds)
2023-09-19 15:35:01 +0200 <dminuoso> cabal-plan is really yummy though.
2023-09-19 15:35:23 +0200 <dminuoso> Its probably my favourite haskell tool.
2023-09-19 15:35:53 +0200 <tomsmeding> if L29Ah is running cabal with --offline they're probably in a situation where less external tools is also better
2023-09-19 15:40:34 +0200 <dminuoso> That's a fair point
2023-09-19 15:40:40 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 15:40:53 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 15:46:43 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net) (Quit: smoothdev)
2023-09-19 15:47:06 +0200danse-nr3_(~francesco@na-19-69-5.service.infuturo.it) (Ping timeout: 255 seconds)
2023-09-19 15:51:13 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-09-19 15:53:55 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer)
2023-09-19 15:56:57 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
2023-09-19 15:57:18 +0200 <exarkun> I used cabal-plan for the first time a few days ago - it didn't generate a build plan for me, it only consumed the build plan cabal wrote. Was I using it wrong?
2023-09-19 15:57:29 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com)
2023-09-19 15:57:43 +0200 <tomsmeding> no
2023-09-19 15:57:53 +0200 <tomsmeding> that's the intended behaviour
2023-09-19 15:58:54 +0200 <exarkun> okay, great, thanks
2023-09-19 16:05:07 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com) (Ping timeout: 260 seconds)
2023-09-19 16:07:07 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 16:08:05 +0200danse-nr3_(~francesco@na-19-69-5.service.infuturo.it)
2023-09-19 16:09:03 +0200PotatoGim(sid99505@id-99505.lymington.irccloud.com) (Server closed connection)
2023-09-19 16:09:25 +0200PotatoGim(sid99505@id-99505.lymington.irccloud.com)
2023-09-19 16:11:25 +0200dcoutts_(~duncan@82-69-94-207.dsl.in-addr.zen.co.uk) (Ping timeout: 252 seconds)
2023-09-19 16:14:54 +0200privacy_(~privacy@47.219.84.6)
2023-09-19 16:15:02 +0200privacy(~privacy@47.219.84.6) (Ping timeout: 260 seconds)
2023-09-19 16:15:32 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d)
2023-09-19 16:15:36 +0200JeremyB99(~JeremyB99@2607:fb90:8d60:ee30:fc70:2f19:34ae:43d) (Read error: Connection reset by peer)
2023-09-19 16:21:13 +0200fweht(uid404746@id-404746.lymington.irccloud.com)
2023-09-19 16:22:26 +0200Inst(~Inst@120.244.192.250) (Remote host closed the connection)
2023-09-19 16:22:36 +0200dfg(~dfg@dfg.rocks)
2023-09-19 16:22:36 +0200dfg(~dfg@dfg.rocks) (Changing host)
2023-09-19 16:22:36 +0200dfg(~dfg@user/dfg)
2023-09-19 16:22:53 +0200Inst(~Inst@120.244.192.250)
2023-09-19 16:25:35 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com)
2023-09-19 16:28:15 +0200JeremyB99(~JeremyB99@172.58.124.68)
2023-09-19 16:30:05 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com) (Ping timeout: 240 seconds)
2023-09-19 16:30:42 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com)
2023-09-19 16:32:44 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2023-09-19 16:38:49 +0200sm(~sm@plaintextaccounting/sm)
2023-09-19 16:40:14 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2023-09-19 16:44:44 +0200CiaoSen(~Jura@2a05:5800:29b:e900:664b:f0ff:fe37:9ef) (Ping timeout: 246 seconds)
2023-09-19 16:47:05 +0200Square3(~Square4@user/square)
2023-09-19 16:48:47 +0200dcoutts_(~duncan@2a02:8012:ae9a:0:217c:5666:d075:6292)
2023-09-19 16:50:05 +0200JeremyB99(~JeremyB99@172.58.124.68) (Ping timeout: 240 seconds)
2023-09-19 16:51:12 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 16:51:36 +0200Square3(~Square4@user/square) (Ping timeout: 244 seconds)
2023-09-19 16:54:22 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 16:54:50 +0200gmg(~user@user/gehmehgeh)
2023-09-19 16:56:42 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 16:56:48 +0200smoothdev(~smoothdev@91-169-231-236.subs.proxad.net)
2023-09-19 17:02:20 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 17:02:23 +0200mysl(~mysl@user/mysl)
2023-09-19 17:03:35 +0200hyiltiz(~hyiltiz@2603-8080-1f00-082f-5873-e3c7-acc6-fcd7.res6.spectrum.com) (Ping timeout: 240 seconds)
2023-09-19 17:06:24 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 17:06:37 +0200sm(~sm@plaintextaccounting/sm) (Quit: sm)
2023-09-19 17:06:52 +0200ph88(~ph88@ip5b403cd4.dynamic.kabel-deutschland.de) (Ping timeout: 248 seconds)
2023-09-19 17:08:19 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-09-19 17:08:28 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 17:11:27 +0200dtman34(~dtman34@2601:447:d000:93c9:a832:b3a1:c57:ffa2) (Ping timeout: 240 seconds)
2023-09-19 17:16:29 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 17:16:42 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 17:22:38 +0200hyiltiz(~hyiltiz@2620:149:13d1:100::431)
2023-09-19 17:25:26 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2023-09-19 17:26:58 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 17:27:45 +0200dtman34(~dtman34@2601:447:d000:93c9:a832:b3a1:c57:ffa2)
2023-09-19 17:31:07 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a12d:97a5:968a:df7f) (Remote host closed the connection)
2023-09-19 17:34:56 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a12d:97a5:968a:df7f)
2023-09-19 17:37:46 +0200christiaanb(sid84827@id-84827.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2023-09-19 17:38:04 +0200qqq(~qqq@92.43.167.61) (Remote host closed the connection)
2023-09-19 17:41:26 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 17:42:19 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 264 seconds)
2023-09-19 17:44:45 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a12d:97a5:968a:df7f) (Remote host closed the connection)
2023-09-19 17:45:25 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a12d:97a5:968a:df7f)
2023-09-19 17:45:56 +0200econo_(uid147250@id-147250.tinside.irccloud.com)
2023-09-19 17:46:26 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 17:46:40 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 17:56:34 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 17:58:22 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 17:58:23 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 17:59:07 +0200 <kuribas> Would it be safe to run accelerate for a production project?
2023-09-19 17:59:26 +0200 <kuribas> Like time series calculations?
2023-09-19 18:03:03 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 240 seconds)
2023-09-19 18:04:24 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-09-19 18:07:00 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a12d:97a5:968a:df7f) (Remote host closed the connection)
2023-09-19 18:16:50 +0200sabino(~sabino@user/sabino)
2023-09-19 18:17:07 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 18:19:20 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 18:19:49 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2023-09-19 18:24:14 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2023-09-19 18:25:43 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-09-19 18:26:15 +0200danse-nr3_(~francesco@na-19-69-5.service.infuturo.it) (Ping timeout: 240 seconds)
2023-09-19 18:28:35 +0200pounce(~pounce@user/cute/pounce) (Ping timeout: 240 seconds)
2023-09-19 18:29:04 +0200pounce(~pounce@user/cute/pounce)
2023-09-19 18:37:18 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 18:37:57 +0200hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds)
2023-09-19 18:38:51 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection)
2023-09-19 18:39:49 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 18:40:21 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a12d:97a5:968a:df7f)
2023-09-19 18:41:03 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 240 seconds)
2023-09-19 18:45:03 +0200acertain_(sid470584@id-470584.hampstead.irccloud.com) (Server closed connection)
2023-09-19 18:45:18 +0200acertain_(sid470584@id-470584.hampstead.irccloud.com)
2023-09-19 18:46:29 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 18:51:12 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 18:52:19 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 18:57:02 +0200marinelli(~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli)
2023-09-19 18:57:26 +0200phma(~phma@host-67-44-208-47.hnremote.net) (Read error: Connection reset by peer)
2023-09-19 18:57:45 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 18:58:49 +0200phma(phma@2001:5b0:211f:8718:5d9f:d28d:c834:ebef)
2023-09-19 18:59:09 +0200hugo-(znc@verdigris.lysator.liu.se)
2023-09-19 18:59:33 +0200robosexual(~spaceoyst@77.223.88.70) (Quit: Konversation terminated!)
2023-09-19 19:00:14 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-09-19 19:01:20 +0200bliminse(~bliminse@user/bliminse)
2023-09-19 19:03:25 +0200 <tomsmeding> @tell kuribas safe in what way?
2023-09-19 19:03:25 +0200 <lambdabot> Consider it noted.
2023-09-19 19:07:48 +0200hugo-hugo
2023-09-19 19:09:22 +0200Square3(~Square4@user/square)
2023-09-19 19:12:18 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 19:12:39 +0200otto_s(~user@p5de2f287.dip0.t-ipconnect.de) (Ping timeout: 244 seconds)
2023-09-19 19:12:46 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 19:14:42 +0200otto_s(~user@p4ff27687.dip0.t-ipconnect.de)
2023-09-19 19:15:09 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 19:15:29 +0200mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2023-09-19 19:20:00 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a12d:97a5:968a:df7f) (Remote host closed the connection)
2023-09-19 19:20:34 +0200danza(~francesco@na-19-70-234.service.infuturo.it)
2023-09-19 19:24:19 +0200wootehfoot(~wootehfoo@user/wootehfoot)
2023-09-19 19:24:32 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-09-19 19:26:15 +0200Square3(~Square4@user/square) (Ping timeout: 240 seconds)
2023-09-19 19:27:09 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-09-19 19:28:35 +0200mysl(~mysl@user/mysl) (Ping timeout: 240 seconds)
2023-09-19 19:29:07 +0200deriamis_(deriamis@50.34.50.53)
2023-09-19 19:32:43 +0200deriamis(deriamis@50.34.50.53) (Ping timeout: 264 seconds)
2023-09-19 19:33:53 +0200mysl(~mysl@user/mysl)
2023-09-19 19:34:39 +0200puke(~puke@user/puke) (Ping timeout: 246 seconds)
2023-09-19 19:38:34 +0200 <tomsmeding> @tell kuribas The cpu backend (accelerate-llvm-native) is solid, the gpu backend (accelerate-llvm-ptx) works decently but for larger programs it tends to crash somewhere relating the nvidia gpu driver (if I remember correctly), and we haven't been able to figure out what happens
2023-09-19 19:38:34 +0200 <lambdabot> Consider it noted.
2023-09-19 19:39:02 +0200polyphem(~polyphem@p4fc2c546.dip0.t-ipconnect.de)
2023-09-19 19:41:32 +0200privacy_(~privacy@47.219.84.6) (Ping timeout: 260 seconds)
2023-09-19 19:41:53 +0200lambdap237(~lambdap@static.167.190.119.168.clients.your-server.de) (Quit: lambdap237)
2023-09-19 19:42:22 +0200lambdap2371(~lambdap@static.167.190.119.168.clients.your-server.de)
2023-09-19 19:42:33 +0200lambdap2371(~lambdap@static.167.190.119.168.clients.your-server.de) (Client Quit)
2023-09-19 19:42:50 +0200lambdap2371(~lambdap@static.167.190.119.168.clients.your-server.de)
2023-09-19 19:44:59 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a12d:97a5:968a:df7f)
2023-09-19 19:45:02 +0200privacy(~privacy@47.219.84.6)
2023-09-19 19:47:33 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 19:50:17 +0200danza(~francesco@na-19-70-234.service.infuturo.it) (Ping timeout: 260 seconds)
2023-09-19 19:51:00 +0200privacy_(~privacy@47.219.84.6)
2023-09-19 19:51:03 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 19:51:24 +0200privacy(~privacy@47.219.84.6) (Ping timeout: 244 seconds)
2023-09-19 19:52:59 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-09-19 19:54:03 +0200astra(sid289983@id-289983.hampstead.irccloud.com) (Server closed connection)
2023-09-19 19:54:25 +0200astra(sid289983@id-289983.hampstead.irccloud.com)
2023-09-19 19:55:13 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 19:55:15 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 19:58:22 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 19:58:22 +0200polyphem(~polyphem@p4fc2c546.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-09-19 19:58:22 +0200p0lyph3m(~polyphem@p4fc2c546.dip0.t-ipconnect.de)
2023-09-19 19:58:27 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
2023-09-19 20:00:03 +0200tnks(sid412124@id-412124.helmsley.irccloud.com) (Server closed connection)
2023-09-19 20:00:13 +0200tnks(sid412124@id-412124.helmsley.irccloud.com)
2023-09-19 20:04:28 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 20:04:43 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 20:05:05 +0200hyiltiz(~hyiltiz@2620:149:13d1:100::431) (Ping timeout: 240 seconds)
2023-09-19 20:08:49 +0200hyiltiz(~hyiltiz@2620:149:13d1:100::431)
2023-09-19 20:13:02 +0200 <yin> what's the canonical way of doing `[a -> a] -> a -> a` ?
2023-09-19 20:13:20 +0200tomsmedingalways does foldr (.) id
2023-09-19 20:13:30 +0200 <yin> tomsmeding: elegant
2023-09-19 20:13:41 +0200 <erisco> head
2023-09-19 20:13:44 +0200 <tomsmeding> I mean you can always getEndo . foldMap Endo if you are so inclined :p
2023-09-19 20:15:03 +0200hongminhee(sid295@id-295.tinside.irccloud.com) (Server closed connection)
2023-09-19 20:15:12 +0200hongminhee(sid295@id-295.tinside.irccloud.com)
2023-09-19 20:15:14 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 20:15:54 +0200 <EvanR> > head [] x
2023-09-19 20:15:56 +0200 <lambdabot> *Exception: Prelude.head: empty list
2023-09-19 20:16:18 +0200 <EvanR> I want my money back
2023-09-19 20:17:56 +0200 <tomsmeding> yin: if you're using hlint, beware of hlint being condescending about 'foldr (.) id (map ... l)'
2023-09-19 20:18:58 +0200 <tomsmeding> no, 'foldr ((.) . f) id l' is not clearer than 'foldr (.) id (map f l)', and yes I did need to think >10sec before being reasonably sure that ((.) . f) is the right expression
2023-09-19 20:19:15 +0200 <erisco> EvanR, my apologies. foldr const id
2023-09-19 20:19:37 +0200 <tomsmeding> can remove the foldr
2023-09-19 20:20:13 +0200hugoimagines a good functional lanuage which doesn't look like someone rolled their head through the specal keys
2023-09-19 20:20:35 +0200 <tomsmeding> haskell can be like that if you care about readability
2023-09-19 20:20:39 +0200 <tomsmeding> hlint evidently does not :p
2023-09-19 20:20:49 +0200 <EvanR> the readable haskell movement
2023-09-19 20:20:55 +0200 <EvanR> I'm card carrying
2023-09-19 20:21:04 +0200 <yin> tomsmeding: i have a huuuge .hlint.yaml ;)
2023-09-19 20:21:12 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2023-09-19 20:21:17 +0200 <tomsmeding> to wit also that '(\x -> f x + 3) <$> something' is not more readable than 'do { x <- something ; return (f x + 3) }'
2023-09-19 20:21:35 +0200 <tomsmeding> yin: the first thing I do after installing HLS is disabling hlint
2023-09-19 20:21:39 +0200 <monochrom> Sapir-Whorf implies that every language rolls your head through its special keys.
2023-09-19 20:21:52 +0200 <monochrom> Every language. No exception.
2023-09-19 20:22:14 +0200 <tomsmeding> monochrom: that's one for your tautologies page
2023-09-19 20:22:15 +0200 <monochrom> Every language brainwashes you. Do not think that any of them is "natural".
2023-09-19 20:22:20 +0200 <tomsmeding> also holds for languages without special keys
2023-09-19 20:22:22 +0200Inst(~Inst@120.244.192.250) (Ping timeout: 260 seconds)
2023-09-19 20:22:23 +0200 <tomsmeding> it's just a no-op then
2023-09-19 20:22:46 +0200tomsmeding. o O ( COBOL )
2023-09-19 20:23:12 +0200 <monochrom> COBOL's special key is clumsy English and in all caps.
2023-09-19 20:23:31 +0200hugoSELECT's `COBOL` FROM TABLES
2023-09-19 20:23:43 +0200 <monochrom> Plus some random requirement on compulsory indentation.
2023-09-19 20:23:47 +0200 <tomsmeding> hot take: applescript is cobol tried again
2023-09-19 20:24:07 +0200 <tomsmeding> still clumsy English, not all caps any more
2023-09-19 20:24:35 +0200 <monochrom> Actually I write the <$> more often now.
2023-09-19 20:24:47 +0200 <tomsmeding> also if that makes you write a lambda before the <$> ?
2023-09-19 20:24:56 +0200 <tomsmeding> if it was just 'return (f x)', I would also write f <$>
2023-09-19 20:24:59 +0200 <monochrom> I can agree that both forms are on par.
2023-09-19 20:25:02 +0200 <erisco> You know, it does irritate me that "readable" (and most -ables) is so nonobviously subjective
2023-09-19 20:25:28 +0200 <monochrom> Well that's why I brought up Sapir-Whorf.
2023-09-19 20:25:46 +0200 <monochrom> You have been brainwashed by your first language, therefore anything different is "unreadable".
2023-09-19 20:25:49 +0200 <tomsmeding> (I also use lambda plus <$> sometimes, but only if there is some other reason to fit the thing on one line -- perhaps because it's one of 15 of such lines, and it's good to have the whole thing be compact)
2023-09-19 20:25:50 +0200 <erisco> It is a common thing I hear when using anything other than the most popular of choices, be it languages or code libraries.
2023-09-19 20:26:04 +0200 <monochrom> In fact I have banned "readable" and "unreadable" from my vocab.
2023-09-19 20:26:17 +0200 <tomsmeding> monochrom: fair
2023-09-19 20:26:18 +0200 <Rembane> monochrom: What do you use instead?
2023-09-19 20:26:53 +0200 <[Leary]> tomsmeding: `something <&> \x -> f x + 3`.
2023-09-19 20:26:58 +0200 <monochrom> I use "comprehensible" and sometimes clarify with "by the TAs".
2023-09-19 20:27:09 +0200tzh(~tzh@c-73-25-201-16.hsd1.or.comcast.net)
2023-09-19 20:27:17 +0200 <tomsmeding> comprehensible is precisely as bad as readable
2023-09-19 20:27:25 +0200 <tomsmeding> it's the qualifier that improves things
2023-09-19 20:27:34 +0200 <monochrom> Well that's why I add "by the TAs".
2023-09-19 20:27:36 +0200 <tomsmeding> [Leary]: hmm
2023-09-19 20:27:55 +0200 <erisco> I just gently suggest they mean "familiar" and "unfamiliar" rather than "readable" and "unreadable"
2023-09-19 20:28:07 +0200 <tomsmeding> erisco: good that you do that gently
2023-09-19 20:28:17 +0200 <monochrom> And I assure you, when the day comes that "comprehensible" is also widely abused, I will switch to another word.
2023-09-19 20:29:00 +0200 <hugo> erisco: I hear what you say, but consider invoke(([ws] & qn(([ws] & 'f')) & (([ws] & '(') | nop) & [ws] & ([ws] & string([String])) & [ws] & ',' & [ws] & [ws] & ('{' | nop) & [ws] & qn(([ws] & 'x')) & [ws] & '=>' & [ws] & [ws] & '1' & (([ws] & ',') | nop) & [ws] & qn(([ws] & 'y')) & [ws] & '=>' & [ws] & [ws] & '2' & (([ws] & ',') | nop) & [ws] & ('}' | nop) & (([ws] & ',') | nop) & (([ws] & ')') |
2023-09-19 20:29:00 +0200 <hugo> nop) & (([ws] & nop) | nop)))
2023-09-19 20:29:00 +0200 <hugo> It's familiar to me, but not to you
2023-09-19 20:29:08 +0200 <dolio> Why does hlint suggest manually fusing that? There's a whole framework that exists so you don't have to.
2023-09-19 20:29:58 +0200 <tomsmeding> hugo: no clue what language/library that is, but it looks like a grammar, and I'm confused by the nops
2023-09-19 20:30:03 +0200yvan-sraka(sid419690@id-419690.lymington.irccloud.com) (Server closed connection)
2023-09-19 20:30:13 +0200yvan-sraka(sid419690@id-419690.lymington.irccloud.com)
2023-09-19 20:30:43 +0200 <hugo> tomsmeding: I wrote a parser combinator in Python. The nops mean parse nothing and succeed
2023-09-19 20:30:58 +0200 <tomsmeding> right, that's what I expected
2023-09-19 20:31:09 +0200 <hugo> My point was that it's hard to read for most of you, but I have stared at it so much that I can read it rather quickly
2023-09-19 20:31:12 +0200 <tomsmeding> meaning that ([ws] & nop) is just [ws]
2023-09-19 20:31:19 +0200 <hugo> tomsmeding: Indeed
2023-09-19 20:31:36 +0200 <hugo> All the extra '& nop' is due to how it's generated
2023-09-19 20:32:30 +0200 <tomsmeding> I think it's readable enough; I don't know what qn is, nor invoke, but that's relatively benign I'd expect. It's just way too verbose. In my experience, I find it easier to read something the more compactly it is presented, as long as I can intuitively read that notation
2023-09-19 20:32:45 +0200 <tomsmeding> (this may mean that the more familiar you get with the topic, the more compact representations you desire)
2023-09-19 20:33:02 +0200 <monochrom> You know, "foo | nop" can be refactored to "optional foo" by defining "optional p = p | nop".
2023-09-19 20:33:19 +0200 <monochrom> which is what Control.Applicative did.
2023-09-19 20:33:24 +0200 <tomsmeding> here, when familiar with regular expressions, there is very little new stuff to learn, so a _way_ more compact representation would be more readable to me
2023-09-19 20:33:31 +0200 <tomsmeding> monochrom: this is python
2023-09-19 20:33:52 +0200 <EvanR> haskell is unreadable by some people not because they can't read it but because they won't xD
2023-09-19 20:33:56 +0200 <tomsmeding> hugo: is 'qn' optional, perhaps?
2023-09-19 20:34:00 +0200 <hugo> I confess that this is a bad example, it's the expanded form, which makes it lessreadable
2023-09-19 20:34:01 +0200 <tomsmeding> as in "question"
2023-09-19 20:34:03 +0200 <monochrom> Well yeah, but it's still legitimate to pose the refactoring challenge.
2023-09-19 20:34:19 +0200 <erisco> hugo, I wouldn't be saying your grammar is unreadable. I might suggest introducing more named production rules to break that up though
2023-09-19 20:34:32 +0200 <hugo> monochrom: foo | nop is already represented in the source as optional(foo), see my previous poit
2023-09-19 20:34:45 +0200 <monochrom> OK cool.
2023-09-19 20:35:38 +0200 <hugo> tomsmeding: qn I belive is a "qualified name", the example parser puppet code
2023-09-19 20:35:56 +0200 <monochrom> Do you support recursion? p ::= '(' p ')' | nop
2023-09-19 20:35:59 +0200 <tomsmeding> ah, so it's a subgrammar
2023-09-19 20:36:28 +0200 <hugo> But it's good to hear that my dumps are "readable". You really don't want to see the non-prettified grammar
2023-09-19 20:36:34 +0200 <tomsmeding> :D
2023-09-19 20:36:43 +0200 <tomsmeding> they're comprehensible, not very readable
2023-09-19 20:36:44 +0200 <tomsmeding> ;)
2023-09-19 20:36:45 +0200Pickchea(~private@user/pickchea)
2023-09-19 20:37:33 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a12d:97a5:968a:df7f) (Remote host closed the connection)
2023-09-19 20:37:39 +0200 <hugo> monochrom: Recursion is supported, the problem being that lazy evaluation is achived through local lambdas, which means that it it's non-trivial to compare recursive steps
2023-09-19 20:37:52 +0200 <hugo> (I'm very open to solutions)
2023-09-19 20:38:16 +0200 <hugo> tomsmeding: Is there a difference between a grammar and a sub-grammar? Rather than how large it is?
2023-09-19 20:38:53 +0200 <tomsmeding> hugo: no, just that qn is apparently not a builtin primitive grammar construct, but rather a function that constructs another grammar
2023-09-19 20:38:57 +0200 <hugo> tomsmeding: Nice to hear that they are comprehensible. I personally feed them through a rainbow-parenthesis script to understand them
2023-09-19 20:39:02 +0200 <tomsmeding> :p
2023-09-19 20:39:14 +0200 <tomsmeding> the parentheses are fairly flat here, vim % was sufficient for me
2023-09-19 20:39:17 +0200jackneill__(~Jackneill@20014C4E1E062E00A473EFF2719A535F.dsl.pool.telekom.hu) (Ping timeout: 260 seconds)
2023-09-19 20:39:45 +0200 <tomsmeding> re recursion, python is imperative and mutable state is no issue, so perhaps put a unique generated ID in every grammar AST node
2023-09-19 20:40:01 +0200 <tomsmeding> then you can detect recursion by finding cycles in the graph, using IDs as node identifiers
2023-09-19 20:40:03 +0200 <EvanR> every language recognized by the subgrammar of g is recognized by g!
2023-09-19 20:40:17 +0200 <tomsmeding> what is "the" subgrammar of g :p
2023-09-19 20:40:22 +0200 <EvanR> s/the/a
2023-09-19 20:40:30 +0200 <tomsmeding> not true
2023-09-19 20:40:42 +0200 <EvanR> not to be confused with the subgenius
2023-09-19 20:40:43 +0200 <tomsmeding> let g be the regex abcd
2023-09-19 20:40:51 +0200 <tomsmeding> bc is a subgrammar of g
2023-09-19 20:40:57 +0200 <monochrom> Wait, are you just making a joke that references a definition of infinite sets?
2023-09-19 20:41:00 +0200 <erisco> sublanguage versus subgrammar
2023-09-19 20:41:05 +0200xmachina(~xmachina@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 4.0.4)
2023-09-19 20:41:09 +0200 <erisco> though I haven't heard of "subgrammar" before
2023-09-19 20:41:12 +0200 <hugo> tomsmeding: 'qn' is technically not a sub-grammar, since it parser it's contents as given (it just changes the output). [ws] (and everything within brackes) is however a subgrammar
2023-09-19 20:41:18 +0200 <Rembane> Does this imply that supergrammars exist?
2023-09-19 20:41:29 +0200 <exarkun> I think my grammars are super.
2023-09-19 20:41:29 +0200 <tomsmeding> hugo: I see
2023-09-19 20:41:41 +0200danso(~danso@user/danso) (Quit: quittin time)
2023-09-19 20:41:41 +0200 <exarkun> wait, that doesn't sound right ...
2023-09-19 20:42:16 +0200 <monochrom> Clearly, Σ* is the super gramma of them all
2023-09-19 20:42:17 +0200 <erisco> Would a subgrammar define a language of substrings?
2023-09-19 20:42:33 +0200 <monochrom> And Gaia is the super grandma of them all.
2023-09-19 20:42:39 +0200 <hugo> tomsmeding: Reganding the rather flat parethesis, this is from a rather simple example, and I have already flattened the tree quite a bit in this output
2023-09-19 20:43:02 +0200 <tomsmeding> my (self-coined, to be fair) usage of subgrammar was intended to mean a subexpression of the grammar
2023-09-19 20:43:21 +0200 <tomsmeding> ah :p
2023-09-19 20:43:41 +0200 <hugo> For example, if I haven't cleaned up [ws] it would expand to string(([ws] & ('always'
2023-09-19 20:43:42 +0200 <hugo> | ("'" & ['a', 'l', 'w', 'a', 'y', 's'] & "'")
2023-09-19 20:43:44 +0200 <hugo> | ('"' & [rich_char(c='a'), rich_char(c='l'), rich_char(c='w'), rich_char(c='a'), rich_char(c='y'), rich_char(c='s')] & '"'))))
2023-09-19 20:43:48 +0200 <hugo> GLHF
2023-09-19 20:43:48 +0200 <erisco> tomsmeding, is it closed?
2023-09-19 20:43:56 +0200 <tomsmeding> beauty
2023-09-19 20:44:24 +0200 <monochrom> Actually, the linebreaks make that more readable...
2023-09-19 20:44:24 +0200 <tomsmeding> erisco: what does closed mean? It looks like these grammars don't have variables or anything of the sort
2023-09-19 20:44:27 +0200xmachina(~xmachina@modemcable048.127-56-74.mc.videotron.ca)
2023-09-19 20:44:40 +0200danso(~danso@user/danso)
2023-09-19 20:45:15 +0200 <erisco> tomsmeding, that all production rules referenced in the subgrammar are in the subgrammar
2023-09-19 20:46:23 +0200 <tomsmeding> right, yes that's what I was assuming
2023-09-19 20:46:44 +0200 <tomsmeding> note that qn here is a function, presumably Grammar -> Grammar, and the subgrammar in question would be qn(g'), not qn
2023-09-19 20:47:08 +0200 <tomsmeding> and in expanded form it's unclear whether there are even local definitions at all, so whether scoping is a thing at all
2023-09-19 20:47:13 +0200 <erisco> I guess there is a topology to grammars
2023-09-19 20:47:31 +0200califax_(~califax@user/califx)
2023-09-19 20:47:53 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 20:48:06 +0200califax(~califax@user/califx) (Ping timeout: 246 seconds)
2023-09-19 20:48:43 +0200 <hugo> The line breaks in my example are manually added by me
2023-09-19 20:48:44 +0200 <ncf> is there?
2023-09-19 20:48:51 +0200califax_califax
2023-09-19 20:48:53 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-09-19 20:49:01 +0200 <monochrom> Darn.
2023-09-19 20:49:05 +0200 <hugo> The definition (from a grammar persepctive) of qn is:
2023-09-19 20:49:26 +0200 <tomsmeding> hugo: are you sick of us already :p
2023-09-19 20:50:15 +0200 <hugo> Sorry, I was busy locking up the definition
2023-09-19 20:50:29 +0200 <monochrom> tomsmeding: I teach my students both "pure (\x y -> ...) <*> m1 <*> m2" and "m1 >>= \x -> m2 >>= \y -> pure (...)", and let them choose which one they prefer, I just require them to be able to understand both when they see it. I don't teach them do-notation.
2023-09-19 20:50:49 +0200 <tomsmeding> was with you until "I don't teach them do-notation"
2023-09-19 20:50:56 +0200 <monochrom> haha
2023-09-19 20:51:00 +0200 <hugo> Let's just say `qn(_, x) -> x`
2023-09-19 20:51:01 +0200 <erisco> it's unreadable, is why
2023-09-19 20:51:03 +0200 <hugo> Or the other way around
2023-09-19 20:51:06 +0200 <Rembane> monochrom: What has do-notation ever done to you?
2023-09-19 20:51:17 +0200 <hugo> All it does is attach metadata to the attached parser
2023-09-19 20:51:18 +0200 <tomsmeding> genuinely, I also like my students to understand the more basic definitions
2023-09-19 20:51:33 +0200 <tomsmeding> hugo: ... qn takes 1 argument in your example grammar
2023-09-19 20:51:38 +0200 <tomsmeding> I see
2023-09-19 20:52:03 +0200 <hugo> tomsmeding: Then the gammar is `qn(x) -> x`, since qn only attaches metadata
2023-09-19 20:52:06 +0200 <monochrom> My first time teaching this stuff, I taught do-notation. Then both TAs and students who understood recommended not teaching do-notation.
2023-09-19 20:52:23 +0200 <tomsmeding> hugo: right
2023-09-19 20:52:25 +0200 <hugo> (I know this technically doesn't type check, but it works out i my non-typed Scheme
2023-09-19 20:52:28 +0200 <hugo> )
2023-09-19 20:52:34 +0200 <tomsmeding> monochrom: interesting
2023-09-19 20:52:45 +0200 <tomsmeding> what was the motivation for that?
2023-09-19 20:53:15 +0200 <EvanR> starting with do notation is like starting to teach C by writing everything in macros
2023-09-19 20:53:17 +0200 <hugo> do-notation, and bind in general is for from trivial, I didn't understand it propertly until I re-implemented it in scheme
2023-09-19 20:53:26 +0200 <tomsmeding> EvanR: I never said _start_ with do-notation
2023-09-19 20:53:28 +0200 <hugo> EvanR: a bit like that
2023-09-19 20:53:51 +0200 <monochrom> I guess it's again "the basics first".
2023-09-19 20:54:17 +0200 <hugo> However; sometimes when people tell me that Haskell is "impossible", I show them 'main = println "Hello, World!"'
2023-09-19 20:54:28 +0200 <tomsmeding> *putStrLn
2023-09-19 20:54:46 +0200 <monochrom> My course also has higher priorities than teaching more Haskell, so we may as well save some time by skipping do-notation. Only >>= and pure are strictly necessary.
2023-09-19 20:54:46 +0200 <EvanR> % print "Hello World"
2023-09-19 20:54:46 +0200 <yahb2> "Hello World"
2023-09-19 20:54:47 +0200 <hugo> tomsmeding: I have written to many other languages recently
2023-09-19 20:54:50 +0200 <tomsmeding> (I know that's not relevant to the point :p)
2023-09-19 20:54:53 +0200 <monochrom> Hell, I don't even teach IO.
2023-09-19 20:55:07 +0200 <EvanR> IO is overrated
2023-09-19 20:55:09 +0200 <monochrom> Instead, we have monadic parsing!
2023-09-19 20:55:28 +0200 <tomsmeding> monochrom: right, your course sounds more theoretical than ours. We have a different course ("languages & compilers") that does lots of parsing stuff, including monadic parsing
2023-09-19 20:55:30 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 20:55:39 +0200 <hugo> Did any previous question pertain to me that I missed?
2023-09-19 20:55:46 +0200 <tomsmeding> the "functional programming" course is slightly more applied, and comes first
2023-09-19 20:55:51 +0200 <EvanR> but one complaint I heard was from someone who heard that haskell is bad at I/O and only good for non-I/O
2023-09-19 20:55:56 +0200 <tomsmeding> hugo: I suggested something about the recursion stuff
2023-09-19 20:55:59 +0200 <EvanR> so not teaching it doesn't help that
2023-09-19 20:56:27 +0200 <hugo> tomsmeding: "Motivation for that?" Or another post?
2023-09-19 20:56:35 +0200 <monochrom> My course is not a Haskell course. (At least, not supposed to.) It's a "principles of programming languages" course.
2023-09-19 20:56:36 +0200 <erisco> ncf, I guess starting nonterminal is important and I am not sure what to make of that
2023-09-19 20:57:00 +0200 <tomsmeding> hugo: re recursion, python is imperative and mutable state is no issue, so perhaps put a unique generated ID in every grammar AST node. then you can detect recursion by finding cycles in the graph, using IDs as node identifiers
2023-09-19 20:57:16 +0200 <tomsmeding> monochrom: see, that's the difference; ours is outspokenly a haskell course
2023-09-19 20:57:28 +0200 <tomsmeding> then one cannot really get around teaching do-notation, because after all, that's what people use
2023-09-19 20:57:47 +0200 <monochrom> So I only need to cover enough Haskell to enable me talking about types, type inference, parametricity, recursive descent parsing, denotational semantics...
2023-09-19 20:58:37 +0200 <monochrom> I also announce at the beginning "Haskell is a practical language, it just doesn't look like it in my course because I use it for academic purposes".
2023-09-19 20:58:39 +0200 <tomsmeding> we have a "concepts of programming language design" course, which is a mandatory master's course for the CS master, and also uses haskell but doesn't use monads at all
2023-09-19 20:59:21 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-09-19 20:59:29 +0200 <hugo> tomsmeding: I haven't looked deeper into finding recursion loops yet. I chose my current stack due to python having the libraries I needed. Whenever I try mutable state I lose track of what I am doing. So my Python is basically (bad) Haskell at this point
2023-09-19 20:59:35 +0200 <monochrom> Oh, in fact, this year I managed to ban the words "monad", "applicative", "functor" until the last lecture. :)
2023-09-19 20:59:39 +0200 <hugo> (don't say anything about my analogy)
2023-09-19 20:59:41 +0200 <tomsmeding> hugo: lol
2023-09-19 20:59:54 +0200xmachina(~xmachina@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 4.0.4)
2023-09-19 21:00:28 +0200 <EvanR> you can ease people into do notation by first teaching don't notation
2023-09-19 21:00:34 +0200 <EvanR> it's simpler
2023-09-19 21:00:41 +0200 <hugo> tomsmeding: Haskell isn't about Monads, but the monad abstraction is one of the best abstractions I have seen
2023-09-19 21:00:50 +0200sord937(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2023-09-19 21:00:56 +0200 <hugo> EvanR: What is don't notation?
2023-09-19 21:01:01 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 21:01:02 +0200 <tomsmeding> @hackage acme-dont
2023-09-19 21:01:02 +0200 <lambdabot> https://hackage.haskell.org/package/acme-dont
2023-09-19 21:01:03 +0200 <monochrom> That's like "you can ease people into static typing by first teaching the () type" :)
2023-09-19 21:01:25 +0200 <EvanR> hey I have seen confusion about the () type
2023-09-19 21:01:31 +0200 <EvanR> they sometimes think it's an empty list
2023-09-19 21:01:49 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 21:01:54 +0200 <EvanR> or the same thing as Void because C
2023-09-19 21:02:04 +0200 <hugo> As a teacher aid for bachelors, I have seen most confusions first hand
2023-09-19 21:02:24 +0200 <hugo> EvanR: () and (C's) void are the same thing
2023-09-19 21:02:40 +0200 <tomsmeding> but not the same as Void
2023-09-19 21:03:06 +0200 <monochrom> You can fix that by "there is no Void in C".
2023-09-19 21:03:29 +0200 <hugo> A void procedure in C never returns a value, while a `-> ()` function in Haskell always returns a null value. 0! = 1!
2023-09-19 21:03:49 +0200 <monochrom> I do sometimes grill my students with "it's the year 2023 of our lord, why do you still treat programming languages as case-insenstive!"
2023-09-19 21:04:23 +0200 <hugo> monochrom: What are you talking about?
2023-09-19 21:04:30 +0200 <monochrom> "Void" vs "void"
2023-09-19 21:04:41 +0200 <hugo> go home
2023-09-19 21:04:53 +0200 <tomsmeding> % :i Data.Void.Void
2023-09-19 21:04:53 +0200 <yahb2> type Data.Void.Void :: * ; data Data.Void.Void ; -- Defined in ‘Data.Void’ ; instance [safe] Eq Data.Void.Void -- Defined in ‘Data.Void’ ; instance [safe] Ord Data.Void.Void -- Defined in ‘Data....
2023-09-19 21:05:07 +0200 <monochrom> If you write your C code like "file *f = FOPEN(..." is it not going to compile, no?
2023-09-19 21:06:26 +0200 <EvanR> we should go further and make bold italic and underline result in different identifiers
2023-09-19 21:07:07 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 21:07:08 +0200 <geekosaur> inb4 esolang using only attributes
2023-09-19 21:07:15 +0200 <hugo> 1. When did I write "Void", 2. Have you seen PEP 3131
2023-09-19 21:07:40 +0200 <monochrom> EvanR wrote "Void". That's all.
2023-09-19 21:07:42 +0200 <EvanR> see () causing confusion
2023-09-19 21:07:47 +0200 <EvanR> again
2023-09-19 21:08:14 +0200 <monochrom> I am OK with "() and void are the same" 99.9% of the time.
2023-09-19 21:08:32 +0200caryhartline(~caryhartl@168.182.58.169)
2023-09-19 21:08:44 +0200 <hugo> I usually tell my (python) students that a procedure without a return return "Nothing", and don't go into details that "Nothing" is the literal "None" object untli they ask."
2023-09-19 21:09:57 +0200 <EvanR> C sucks because its own calling convention ensures something is returned, you just can't use it
2023-09-19 21:10:00 +0200 <hugo> monochrom: Only diffenence I see between "()" and "void" is that one can be asignable to a variable, while the other can't. But what should you do with '()
2023-09-19 21:10:13 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:a12d:97a5:968a:df7f)
2023-09-19 21:10:49 +0200 <hugo> EvanR: C's calling convention just returns, void means that no value is return
2023-09-19 21:10:59 +0200 <EvanR> *that you know of*
2023-09-19 21:11:08 +0200 <hugo> a = [void returnig function] is undefined
2023-09-19 21:11:32 +0200 <hugo> Anything you have seen is undefined, which means that all bets are off
2023-09-19 21:11:49 +0200 <EvanR> undefined is javascript, that's something else
2023-09-19 21:12:01 +0200 <monochrom> haha
2023-09-19 21:12:15 +0200 <erisco> Unit in PureScript is anything. I guess like C!
2023-09-19 21:13:21 +0200 <hugo> EvanR: Have you read the C standard?
2023-09-19 21:13:30 +0200 <EvanR> we are in the wrong room for that
2023-09-19 21:14:01 +0200 <hugo> EvanR: You are trying to pull a Hayman here
2023-09-19 21:14:04 +0200p0lyph3m(~polyphem@p4fc2c546.dip0.t-ipconnect.de) (Quit: CoreIRC for Android - www.coreirc.com)
2023-09-19 21:14:43 +0200 <EvanR> calling conventions isn't in the standards, aiui
2023-09-19 21:15:12 +0200 <EvanR> that's implementation details
2023-09-19 21:16:07 +0200 <hugo> The (nonexistent) value of a void expression (an expression that has type void) shall not
2023-09-19 21:16:09 +0200 <hugo> be used in any way, and implicit or explicit conversions (except to void) shall not be
2023-09-19 21:16:11 +0200 <hugo> applied to such an expression. If an expression of any other type is evaluated as a void
2023-09-19 21:16:13 +0200 <hugo> expression, its value or designator is discarded. (A void expression is evaluated for its
2023-09-19 21:16:15 +0200 <hugo> side effects.)
2023-09-19 21:16:17 +0200 <hugo> C11, ISO 9899:201x
2023-09-19 21:16:23 +0200 <EvanR> WRONG ROOM
2023-09-19 21:16:52 +0200 <geekosaur> then why were you talking about calling conventions?
2023-09-19 21:16:59 +0200 <hugo> So the difference is that void expressions in C can't be checked, and '() expressions in Haskell is worthless to check
2023-09-19 21:17:09 +0200 <erisco> pretty sure Haskell has a C FFI
2023-09-19 21:17:44 +0200 <EvanR> there may be not much to say about () and void and Void when you get down to brass tacks, so I guess we can move on!
2023-09-19 21:18:35 +0200actioninja6(~actioninj@user/actioninja)
2023-09-19 21:19:21 +0200 <erisco> Pascal had this all figured out when it separated procedures from functions
2023-09-19 21:19:43 +0200 <monochrom> Pascal followed Algol in this.
2023-09-19 21:20:10 +0200 <monochrom> C also took a lot from Algol, but they decided to deviate from this one.
2023-09-19 21:20:20 +0200 <EvanR> what's the difference between a procedure and a function
2023-09-19 21:20:43 +0200actioninja(~actioninj@user/actioninja) (Ping timeout: 264 seconds)
2023-09-19 21:20:43 +0200actioninja6actioninja
2023-09-19 21:21:04 +0200 <monochrom> But Algol's 2nd crime was "function but with side effects".
2023-09-19 21:22:44 +0200 <erisco> EvanR, functions have returns, procedures do not
2023-09-19 21:23:02 +0200 <EvanR> "interesting"
2023-09-19 21:23:42 +0200 <hugo> erisco: *procedures may not
2023-09-19 21:23:55 +0200 <monochrom> My unpopular opinion is that we should use the word "procedure" throughout, and accept that some procedures take 0 parameters, and some procedures don't have return values. I don't mind any syntax or reserved word for them, but that should be the fundamental concept.
2023-09-19 21:24:41 +0200 <monochrom> So C got that basically right except they used the word "function" throughout.
2023-09-19 21:24:54 +0200 <hugo> monochrom: My take is that functions are "pure" functions, as in mathematics, while procedures are the programming construct often called functions
2023-09-19 21:24:58 +0200 <erisco> if it unclutters the meaning of "functional programming" then I'm down
2023-09-19 21:25:01 +0200 <monochrom> But that's my point. "function but with side effects" is just illogical.
2023-09-19 21:25:33 +0200 <Hecate> and yet
2023-09-19 21:25:38 +0200 <hugo> monochrom: The scheme world is with you, they use procedure just as you sugests
2023-09-19 21:25:39 +0200 <Hecate> I write these for a living :D
2023-09-19 21:26:41 +0200 <monochrom> Correction: ... accept that procedures can take 0 or more parameters, and have 0 or 1 return values.
2023-09-19 21:27:02 +0200 <erisco> What does Golang have then?
2023-09-19 21:27:15 +0200 <hugo> Why can't a procedure have multiple return values?
2023-09-19 21:27:28 +0200 <geekosaur> golang's do
2023-09-19 21:27:48 +0200 <geekosaur> then again it just looks like a tuple without the parens
2023-09-19 21:27:49 +0200 <Hecate> geekosaur: I've always been surprised by this, isn't it a tuple that is returned?
2023-09-19 21:27:59 +0200 <Hecate> okay yeah, like Python's?
2023-09-19 21:28:04 +0200 <monochrom> One point being instead of the stupid division "0 return value => procedure, 1 return value => function", and doubling down on that error with "oh functions can have side effects too so they are secretly procedures".
2023-09-19 21:28:26 +0200 <EvanR> can I have procedures sometimes return 2 values, please
2023-09-19 21:28:38 +0200 <Hecate> EvanR: only if you eat your vegetables
2023-09-19 21:28:38 +0200 <hugo> The call stack is flexible, and can return multiple values natively
2023-09-19 21:28:46 +0200 <EvanR> why is that too much to ask
2023-09-19 21:29:00 +0200 <hugo> EvanR: Change to a better language
2023-09-19 21:29:03 +0200vglfr(~vglfr@cli-188-239-201-89.bbn.slav.dn.ua) (Ping timeout: 244 seconds)
2023-09-19 21:29:06 +0200 <monochrom> There are two known meanings for "multiple return values". But neither was in Algol so I will pass.
2023-09-19 21:29:07 +0200 <EvanR> don't say python
2023-09-19 21:29:18 +0200 <geekosaur> don't say golang
2023-09-19 21:29:37 +0200 <hugo> Worth noting, most procedural languagse returning 0 values actually return a value (See Python and it's 'None' returns)
2023-09-19 21:30:35 +0200 <hugo> geekosaur: Doesn't golang have true multiple return?
2023-09-19 21:31:14 +0200 <Hecate> hugo: no it's a tuple
2023-09-19 21:31:15 +0200 <Hecate> https://gobyexample.com/multiple-return-values
2023-09-19 21:31:18 +0200 <Hecate> (int, int)
2023-09-19 21:31:20 +0200 <Hecate> that's a tuple
2023-09-19 21:31:30 +0200 <EvanR> I think my gripe was "better language"
2023-09-19 21:31:44 +0200 <erisco> Hecate, but you cannot assign a multiple return to a variable
2023-09-19 21:31:47 +0200sabino(~sabino@user/sabino) (Ping timeout: 260 seconds)
2023-09-19 21:32:08 +0200 <monochrom> No one wants to ask me "you said '2nd crime' so what's the 1st crime?"? :)
2023-09-19 21:32:16 +0200 <hugo> Hecate: "Go has built-in support for multiple return values", are you sure it's a tuple
2023-09-19 21:32:24 +0200 <geekosaur> right, in haskell-speak you must deconstruct it immediately
2023-09-19 21:32:33 +0200 <geekosaur> that strikes me more as multiple return than as tuple
2023-09-19 21:32:38 +0200 <hugo> erisco: You are talking syntax
2023-09-19 21:32:54 +0200 <Hecate> erisco: ah yes indeed
2023-09-19 21:33:00 +0200 <Hecate> so, it's a shittier tuple
2023-09-19 21:33:02 +0200 <Hecate> incredible
2023-09-19 21:33:07 +0200 <monochrom> Wait, is that just like Lisp's multiple return values?
2023-09-19 21:33:11 +0200 <geekosaur> that's golang for you
2023-09-19 21:33:15 +0200 <hugo> Hecate: It's a faster "tuple"
2023-09-19 21:33:25 +0200 <Hecate> hugo: faster on which plan?
2023-09-19 21:33:43 +0200sabino(~sabino@user/sabino)
2023-09-19 21:33:54 +0200 <Hecate> memory layout can't be that different from a tuple in a similar language
2023-09-19 21:33:57 +0200 <hugo> Multiple return values doesn't incur an heap allocation
2023-09-19 21:34:05 +0200 <hugo> And hap allocations are "slow"
2023-09-19 21:34:10 +0200 <Hecate> hugo: where did you read that?
2023-09-19 21:34:39 +0200tzh(~tzh@c-73-25-201-16.hsd1.or.comcast.net) (Ping timeout: 252 seconds)
2023-09-19 21:34:41 +0200 <hugo> I'm actually in search for a good source that heap allocations are slow, currently I only have the general word of mouth
2023-09-19 21:35:02 +0200 <EvanR> heap allocation doesn't necessarily mean malloc
2023-09-19 21:35:05 +0200 <monochrom> I agree that the heap is more expensive.
2023-09-19 21:35:22 +0200 <monochrom> If anything, there is GC to worry about later.
2023-09-19 21:35:44 +0200 <EvanR> unless you're UrWeb
2023-09-19 21:35:45 +0200xmachina(~xmachina@modemcable048.127-56-74.mc.videotron.ca)
2023-09-19 21:35:53 +0200 <monochrom> In principle, GC turns a linear-time linear-space algorithm to quadratic time.
2023-09-19 21:36:03 +0200gmc(sid58314@id-58314.ilkley.irccloud.com) (Server closed connection)
2023-09-19 21:36:09 +0200 <dolio> You don't need to distinguish returning tuples and 'multiple returns' to make things efficient.
2023-09-19 21:36:14 +0200gmc(sid58314@id-58314.ilkley.irccloud.com)
2023-09-19 21:36:59 +0200 <hugo> Technically you can have "wide returns", but we are "unfortunally" stuck with the calling conventions of our host systems
2023-09-19 21:37:37 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 21:37:47 +0200 <tomsmeding> _tuple_ doesn't necessarily mean heap allocation, unless you're haskell and the function is not inlined so it has to conform to GHC's calling convention which is heap-allocated
2023-09-19 21:38:13 +0200 <tomsmeding> to make things even more muddled :D
2023-09-19 21:38:19 +0200 <dolio> You don't need to inline, either.
2023-09-19 21:38:28 +0200 <tomsmeding> in haskell you do, right?
2023-09-19 21:38:35 +0200 <monochrom> Yeah, even more muddled because sometimes GHC can optimize that away. (And sometimes not.)
2023-09-19 21:38:53 +0200 <tomsmeding> I mean, worker-wrapper exists, but then the wrapper needs to be inlined for the scheme to work
2023-09-19 21:38:59 +0200 <EvanR> using multiple returns in C-- ?
2023-09-19 21:39:01 +0200 <tomsmeding> (no, not that Scheme)
2023-09-19 21:39:08 +0200 <Hecate> hohai tomsmeding
2023-09-19 21:39:14 +0200 <tomsmeding> hai!
2023-09-19 21:39:26 +0200 <hugo> (values 1 2)
2023-09-19 21:39:27 +0200 <dolio> I mean, the compiler has to keep track of this stuff.
2023-09-19 21:39:32 +0200 <monochrom> But all the more important for what dolio said. Separate the denotational semantics from optimizing the operational semantics already.
2023-09-19 21:39:39 +0200 <tomsmeding> I left the conversation when it was about Void, then I took a shower, now it's about multiple return
2023-09-19 21:39:41 +0200 <dolio> That doesn't mean the surface syntax needs it.
2023-09-19 21:39:57 +0200 <dolio> Or, that most people need to worry about it in the surface syntax at least.
2023-09-19 21:40:04 +0200 <hugo> But we are stuck in a world of actual compilers, in theory we could live in a multiple-return-world
2023-09-19 21:40:31 +0200caryhartline(~caryhartl@168.182.58.169) (Quit: caryhartline)
2023-09-19 21:40:41 +0200 <EvanR> unless we're writing in asm compilers are great
2023-09-19 21:40:41 +0200 <dolio> You only need to force users to care about all this stuff if you're unwilling to make the compiler keep track of it.
2023-09-19 21:40:41 +0200 <hugo> Multiple returns is the same discussion as 0 returns
2023-09-19 21:42:01 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-09-19 21:42:07 +0200 <monochrom> I'm going to be arrogant and divisive and say Pike ≠ SPJ so Pike knew no better than letting this detail leak to the supposedly high-level language.
2023-09-19 21:42:26 +0200 <hugo> tomsmeding: Ayr you multiple people? You "brack" was 16s long
2023-09-19 21:42:37 +0200 <dolio> Letting it leak is Industry Standard.
2023-09-19 21:43:23 +0200 <tomsmeding> hugo: I'm talking about 21:04 till 21:37 :p
2023-09-19 21:43:49 +0200 <tomsmeding> if it was still about Void then, my reading comprehension could use a touch-up
2023-09-19 21:44:22 +0200 <dolio> tomsmeding: 0 is a multiple. :þ
2023-09-19 21:44:38 +0200 <monochrom> Nah don't worry, we drifted. :)
2023-09-19 21:44:39 +0200 <hugo> I had completely missed that we talked about Void
2023-09-19 21:44:58 +0200 <hugo> monochrom: Is the Pike you mention this pike https://pike.lysator.liu.se/?
2023-09-19 21:45:06 +0200 <monochrom> Just be thankful no one dared to try fractal return values!
2023-09-19 21:45:21 +0200 <hugo> monochrom: Dear god
2023-09-19 21:45:25 +0200 <tomsmeding> hugo: https://en.wikipedia.org/wiki/Rob_Pike
2023-09-19 21:45:28 +0200 <EvanR> there's a rule that says if you allow 0, 1 or 2 returns you have to also allow infinite returns
2023-09-19 21:45:33 +0200 <monochrom> Go's Pike.
2023-09-19 21:45:49 +0200 <hugo> Thank God it's not "that" Pike
2023-09-19 21:46:34 +0200danza(~francesco@na-19-76-177.service.infuturo.it)
2023-09-19 21:47:59 +0200ubert(~Thunderbi@91.141.40.168.wireless.dyn.drei.com) (Ping timeout: 245 seconds)
2023-09-19 21:48:36 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-09-19 21:49:52 +0200caryhartline(~caryhartl@168.182.58.169)
2023-09-19 21:50:24 +0200vglfr(~vglfr@88.154.54.160)
2023-09-19 21:51:20 +0200infinity0(~infinity0@pwned.gg) (Remote host closed the connection)
2023-09-19 21:53:22 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Ping timeout: 260 seconds)
2023-09-19 21:53:27 +0200infinity0(~infinity0@pwned.gg)
2023-09-19 22:01:19 +0200infinity0(~infinity0@pwned.gg) (Remote host closed the connection)
2023-09-19 22:03:27 +0200infinity0(~infinity0@pwned.gg)
2023-09-19 22:04:24 +0200johnw(~johnw@69.62.242.138) (Quit: ZNC - http://znc.in)
2023-09-19 22:05:15 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-09-19 22:06:53 +0200vglfr(~vglfr@88.154.54.160) (Ping timeout: 258 seconds)
2023-09-19 22:08:57 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 246 seconds)
2023-09-19 22:10:08 +0200danza(~francesco@na-19-76-177.service.infuturo.it) (Ping timeout: 255 seconds)
2023-09-19 22:10:21 +0200tzh(~tzh@c-73-25-201-16.hsd1.or.comcast.net)
2023-09-19 22:10:52 +0200hyiltiz(~hyiltiz@2620:149:13d1:100::431) (Ping timeout: 260 seconds)
2023-09-19 22:11:06 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2023-09-19 22:11:38 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 22:11:56 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 255 seconds)
2023-09-19 22:12:16 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 22:14:02 +0200pavonia(~user@user/siracusa)
2023-09-19 22:15:07 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 22:17:03 +0200hyiltiz(~hyiltiz@2620:149:13d1:100::431)
2023-09-19 22:18:45 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 246 seconds)
2023-09-19 22:20:40 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 22:21:01 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-09-19 22:23:33 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2023-09-19 22:32:00 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-09-19 22:33:47 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-09-19 22:34:51 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 246 seconds)
2023-09-19 22:37:46 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-09-19 22:38:22 +0200accord(uid568320@id-568320.hampstead.irccloud.com)
2023-09-19 22:46:02 +0200td_(~td@i5387090C.versanet.de) (Ping timeout: 244 seconds)
2023-09-19 22:46:36 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2023-09-19 22:47:49 +0200td_(~td@i53870901.versanet.de)
2023-09-19 22:48:12 +0200vglfr(~vglfr@cli-188-239-201-89.bbn.slav.dn.ua)
2023-09-19 22:52:52 +0200mstruebing(~mstruebin@2a02:8108:483f:b989:1963:6bff:ae27:c9d3)
2023-09-19 22:54:00 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-09-19 22:54:37 +0200tzh(~tzh@c-73-25-201-16.hsd1.or.comcast.net) (Ping timeout: 260 seconds)
2023-09-19 22:59:19 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
2023-09-19 23:04:09 +0200caryhartline(~caryhartl@168.182.58.169) (Quit: caryhartline)
2023-09-19 23:06:05 +0200_xor8(~xor@ip-50-5-233-250.dynamic.fuse.net)
2023-09-19 23:07:39 +0200_xor(~xor@ip-50-5-233-250.dynamic.fuse.net) (Ping timeout: 255 seconds)
2023-09-19 23:07:40 +0200_xor8_xor
2023-09-19 23:09:47 +0200acidjnk(~acidjnk@p200300d6e7072f09040c85b81d4e368d.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2023-09-19 23:11:49 +0200renegade(~renegade@bcdcac82.skybroadband.com) (Read error: Connection reset by peer)
2023-09-19 23:13:13 +0200tzh(~tzh@c-73-25-201-16.hsd1.or.comcast.net)
2023-09-19 23:15:24 +0200renegade(~renegade@188.220.172.130)
2023-09-19 23:17:29 +0200emmanuelux(~emmanuelu@user/emmanuelux)
2023-09-19 23:19:45 +0200chele(~chele@user/chele) (Remote host closed the connection)
2023-09-19 23:22:23 +0200fendor(~fendor@2a02:8388:1640:be00:aab:1226:f274:5021) (Remote host closed the connection)
2023-09-19 23:22:30 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-09-19 23:24:28 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-09-19 23:25:53 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2023-09-19 23:28:42 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-09-19 23:33:50 +0200liz(~liz@212.132.163.201)
2023-09-19 23:46:26 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8) (Read error: Connection reset by peer)
2023-09-19 23:47:19 +0200johnw(~johnw@69.62.242.138)
2023-09-19 23:47:49 +0200JeremyB99(~JeremyB99@2607:fb91:17ee:23f5:edee:2b44:e73e:1db8)
2023-09-19 23:50:27 +0200caryhartline(~caryhartl@168.182.58.169)
2023-09-19 23:52:57 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 260 seconds)
2023-09-19 23:54:47 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-09-19 23:58:27 +0200monochrom(trebla@216.138.220.146) (Quit: NO CARRIER)