2023/10/11

2023-10-11 00:00:07 +0200	<geekosaur>	I had to push them onto 9…
2023-10-11 00:00:37 +0200	<geekosaur>	(when they added linear haskell. I think that was on ghc-devs)
2023-10-11 00:01:03 +0200	alphacentauri	(alphacenta@gateway/vpn/protonvpn/alphacentauri) (Quit: WeeChat 4.0.5)
2023-10-11 00:02:04 +0200	tromp	(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-10-11 00:02:08 +0200	<mauke>	... yep, three decades is about right. on 2024-10-17, perl 5 will celebrate its 30th birthday
2023-10-11 00:02:09 +0200	<monochrom>	Haha, in that case, how about a release with lots of great new features that nobody wants to use so people stay on the previous major version number for three decades >:D
2023-10-11 00:03:45 +0200	<Rembane>	Dependent types in Perl 5 ftw!
2023-10-11 00:04:10 +0200	<monochrom>	Ah, maybe I misread. You probably meant instead you talked the GHC devs out of calling linear haskell "8.12".
2023-10-11 00:04:14 +0200	<geekosaur>	actually Krzysztof suggested it first, I just got behind and pushed when people wanted to save that for Dependent Haskell
2023-10-11 00:04:34 +0200	<geekosaur>	("that" = ghc 9.0)
2023-10-11 00:04:39 +0200	<tomsmeding>	if people wait for DH that's actually going to be three decades
2023-10-11 00:05:34 +0200	<geekosaur>	yeh, that was pretty much my point. https://mail.haskell.org/pipermail/ghc-devs/2020-July/019057.html
2023-10-11 00:07:02 +0200	Maeda	(~Maeda@91-161-10-149.subs.proxad.net) (Quit: leaving)
2023-10-11 00:09:29 +0200	<mauke>	https://hackage.haskell.org/package/ghc-bignum-1.3/docs/GHC-Num-Integer.html#t:Integer why does the haddock render wrong?
2023-10-11 00:09:42 +0200	<mauke>	it shows Integer where the source uses 'IP'
2023-10-11 00:11:25 +0200	hiyori	(~hiyori@user/hiyori)
2023-10-11 00:11:46 +0200	privacy	(~privacy@user/privacy) (Quit: Leaving)
2023-10-11 00:11:49 +0200	<Rembane>	geekosaur: Is Dependent Haskell something that's on its way into the main language?
2023-10-11 00:12:08 +0200	<geekosaur>	eventually
2023-10-11 00:12:30 +0200	<geekosaur>	mauke, it does it twice, even. sounds like a Haddock bug
2023-10-11 00:14:26 +0200	<mauke>	I wonder if one of the imports contains 'type IP = Integer' or similar, or if something is going wrong with CPP
2023-10-11 00:16:24 +0200	<geekosaur>	it's not cpp or the constructor would have been renamed, which ":i Integer" in ghci says it hasn't
2023-10-11 00:16:43 +0200	thegeekinside	(~thegeekin@189.217.90.224)
2023-10-11 00:20:14 +0200	alphacentauri	(alphacenta@gateway/vpn/protonvpn/alphacentauri)
2023-10-11 00:29:58 +0200	wroathe	(~wroathe@user/wroathe)
2023-10-11 00:33:46 +0200	falafel	(~falafel@62.175.113.194.dyn.user.ono.com)
2023-10-11 00:53:26 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-10-11 00:55:22 +0200	Sgeo	(~Sgeo@user/sgeo)
2023-10-11 00:58:31 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 264 seconds)
2023-10-11 01:00:29 +0200	lisbeths	(uid135845@id-135845.lymington.irccloud.com)
2023-10-11 01:08:33 +0200	pounce_	(~pounce@user/cute/pounce)
2023-10-11 01:08:45 +0200	falafel	(~falafel@62.175.113.194.dyn.user.ono.com) (Remote host closed the connection)
2023-10-11 01:09:24 +0200	[itchyjunk]	(~itchyjunk@user/itchyjunk/x-7353470)
2023-10-11 01:09:32 +0200	hugo	(znc@verdigris.lysator.liu.se) (Ping timeout: 248 seconds)
2023-10-11 01:10:12 +0200	vglfr	(~vglfr@88.155.165.25) (Ping timeout: 240 seconds)
2023-10-11 01:10:17 +0200	[itchyjunk]	(~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2023-10-11 01:10:28 +0200	Square2	(~Square4@user/square)
2023-10-11 01:10:35 +0200	[itchyjunk]	(~itchyjunk@user/itchyjunk/x-7353470)
2023-10-11 01:11:10 +0200	wroathe	(~wroathe@user/wroathe) (Ping timeout: 272 seconds)
2023-10-11 01:11:45 +0200	pounce_	pounce
2023-10-11 01:13:35 +0200	Square	(~Square@user/square) (Ping timeout: 258 seconds)
2023-10-11 01:20:31 +0200	pounce	(~pounce@user/cute/pounce) (Remote host closed the connection)
2023-10-11 01:20:49 +0200	pounce	(~pounce@user/cute/pounce)
2023-10-11 01:21:03 +0200	ph88	(~ph88@ip5b406c07.dynamic.kabel-deutschland.de)
2023-10-11 01:24:03 +0200	YuutaW	(~YuutaW@mail.yuuta.moe) (Read error: Connection reset by peer)
2023-10-11 01:24:15 +0200	yuuta	(~YuutaW@mail.yuuta.moe)
2023-10-11 01:25:46 +0200	hugo	(znc@verdigris.lysator.liu.se)
2023-10-11 01:27:21 +0200	alphacentauri	(alphacenta@gateway/vpn/protonvpn/alphacentauri) (Quit: WeeChat 4.0.5)
2023-10-11 01:28:11 +0200	harveypwca	(~harveypwc@2601:246:c280:6a90:837d:db39:3eea:f7db) (Quit: Leaving)
2023-10-11 01:30:07 +0200	alphacentauri	(alphacenta@gateway/vpn/protonvpn/alphacentauri)
2023-10-11 01:31:10 +0200	YuutaW	(~YuutaW@mail.yuuta.moe)
2023-10-11 01:31:26 +0200	yuuta	(~YuutaW@mail.yuuta.moe) (Ping timeout: 260 seconds)
2023-10-11 01:46:55 +0200	notzmv	(~zmv@user/notzmv)
2023-10-11 01:49:15 +0200	waleee	(~waleee@2001:9b0:21c:e600:f2f3:f744:435d:137c)
2023-10-11 01:57:23 +0200	cheater_	(~Username@user/cheater)
2023-10-11 01:58:30 +0200	cheater_	(~Username@user/cheater) (Read error: Connection reset by peer)
2023-10-11 01:58:31 +0200	cheater	(~Username@user/cheater) (Ping timeout: 255 seconds)
2023-10-11 01:59:15 +0200	cheater_	(~Username@user/cheater)
2023-10-11 01:59:15 +0200	cheater_	cheater
2023-10-11 02:01:43 +0200	bitdex	(~bitdex@gateway/tor-sasl/bitdex)
2023-10-11 02:20:26 +0200	machinedgod	(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds)
2023-10-11 02:31:48 +0200	Sciencentistguy6	(~sciencent@hacksoc/ordinary-member)
2023-10-11 02:33:35 +0200	Sciencentistguy	(~sciencent@hacksoc/ordinary-member) (Ping timeout: 240 seconds)
2023-10-11 02:33:35 +0200	Sciencentistguy6	Sciencentistguy
2023-10-11 02:39:08 +0200	TonyStone	(~TonyStone@cpe-74-76-57-186.nycap.res.rr.com) (Remote host closed the connection)
2023-10-11 02:51:21 +0200	wroathe	(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-10-11 02:51:21 +0200	wroathe	(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-10-11 02:51:21 +0200	wroathe	(~wroathe@user/wroathe)
2023-10-11 02:51:35 +0200	Lord_of_Life	(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds)
2023-10-11 02:52:39 +0200	Lord_of_Life	(~Lord@user/lord-of-life/x-2819915)
2023-10-11 02:55:27 +0200	lg188	(~lg188@82.18.98.230) (Ping timeout: 240 seconds)
2023-10-11 02:55:58 +0200	lg188	(~lg188@82.18.98.230)
2023-10-11 02:56:20 +0200	Tuplanolla	(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Ping timeout: 255 seconds)
2023-10-11 02:57:10 +0200	machinedgod	(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-10-11 03:01:08 +0200	oo_miguel	(~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (Quit: oo_miguel)
2023-10-11 03:03:05 +0200	Guest23	(~Guest23@149.19.169.127)
2023-10-11 03:03:09 +0200	<Guest23>	Garfield's Foursome with Nermal, Edna Skilton, and Jean Pierre Manikariza
2023-10-11 03:03:09 +0200	<Guest23>	Garfield, Nermal, Edna Skilton, and Jean Pierre Manikariza have an orgy over lasagna! https://justpaste.it/Garfield-Foursome-Nermal-Skilton
2023-10-11 03:03:46 +0200	Guest23	(~Guest23@149.19.169.127) (K-Lined)
2023-10-11 03:19:42 +0200	grnman_	(~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net)
2023-10-11 03:22:40 +0200	otto_s	(~user@p5b044f94.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
2023-10-11 03:24:34 +0200	otto_s	(~user@p4ff272d5.dip0.t-ipconnect.de)
2023-10-11 03:27:25 +0200	hiyori	(~hiyori@user/hiyori) (Quit: Client closed)
2023-10-11 03:29:28 +0200	hiyori	(~hiyori@user/hiyori)
2023-10-11 03:29:56 +0200	waleee	(~waleee@2001:9b0:21c:e600:f2f3:f744:435d:137c) (Ping timeout: 246 seconds)
2023-10-11 03:30:05 +0200	<EvanR>	I've heard that unsafeInterleaveIO is not actually unsafe. In what sense is it not unsafe. Should it say unhaskellyInterleaveIO instead because evaluating the results causes side effects
2023-10-11 03:30:21 +0200	waleee	(~waleee@h-176-10-137-138.NA.cust.bahnhof.se)
2023-10-11 03:31:39 +0200	<geekosaur>	it's unsafe because I/O actions are triggered in apparently pure code. the Haskell report actually mitigates this to some extent by requiring silent failure in cases where this would be revealed (e.g. exceptions), but GHC's RTS throws them instead
2023-10-11 03:33:50 +0200	j1grosuc	(~j1grosuc@190.123.12.128)
2023-10-11 03:34:02 +0200	<EvanR>	not throwing exceptions is safer??
2023-10-11 03:34:07 +0200	sabino	(~sabino@user/sabino) (Quit: Lambda _ -> x)
2023-10-11 03:34:21 +0200	<geekosaur>	from a purity standpoint, yes
2023-10-11 03:34:26 +0200	j1grosuc	(~j1grosuc@190.123.12.128) (K-Lined)
2023-10-11 03:34:43 +0200	<geekosaur>	no unexpected bottoms
2023-10-11 03:35:57 +0200	<geekosaur>	you lose the ability to reason about code when an invisible I/O action can inject unexpected bottoms
2023-10-11 03:35:59 +0200	<EvanR>	ok the "as long as the program doesn't crash" anti-erlang philosophy
2023-10-11 03:37:56 +0200	<EvanR>	well yeah this whole narrative seems paint unsafeInterleaveIO as pretty bad either way
2023-10-11 03:38:30 +0200	<EvanR>	but somehow I recall it being considered not as bad as unsafePerformIO
2023-10-11 03:39:24 +0200	<geekosaur>	I've seen both takes
2023-10-11 03:40:39 +0200	<geekosaur>	I think it's still out of sequence with other I/O actions, but at least hypothetically can't interfere with or be interfered with by them (in particular the RTS is supposed to "lock" any resources that are under control of unsafeInterleaveIO)
2023-10-11 03:41:49 +0200	<EvanR>	how does that work. getContents does the half closing of the handle, but in general?
2023-10-11 03:42:02 +0200	<geekosaur>	getContents is unsafeInterleaveIO
2023-10-11 03:42:07 +0200	<EvanR>	yeah
2023-10-11 03:42:51 +0200	<geekosaur>	and that's what does the half closing. my read of the Report is that it's supposed to be impossible to reopen a file for which a half-closed handle exists
2023-10-11 03:43:04 +0200	<geekosaur>	not merely impossible to touch that handle
2023-10-11 03:43:13 +0200	<EvanR>	in general how does it know what resources are involved in your mad science unsafeInterleaveIO
2023-10-11 03:43:19 +0200	<EvanR>	GC reachable?
2023-10-11 03:45:13 +0200	<geekosaur>	actually you're expected to tell it yourself, as with hGetContents (https://downloads.haskell.org/ghc/9.2.5/docs/html/libraries/base-4.16.4.0/src/GHC.IO.Handle.Text.h…)
2023-10-11 03:45:19 +0200	FinnElija	(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2023-10-11 03:45:27 +0200	<geekosaur>	it can't be automatic because, as you point out, how can it know?
2023-10-11 03:45:48 +0200	FinnElija	(~finn_elij@user/finn-elija/x-0085643)
2023-10-11 03:47:23 +0200	<geekosaur>	so in the general case you must know how to tell the RTS that some resources can no longer be touched. this is a problem with unsafeInterleaveIO because there are no documented ways to do this in the Report and the only documentation for GHC is in GHC.IO.Handle iirc
2023-10-11 03:47:50 +0200	<EvanR>	interesting
2023-10-11 03:47:58 +0200	<geekosaur>	and that might not be enough to deal with, say, a database connection
2023-10-11 03:49:36 +0200	hiyori	(~hiyori@user/hiyori) (Quit: Client closed)
2023-10-11 03:52:24 +0200	_xor8	(~xor@ip-50-5-233-250.dynamic.fuse.net)
2023-10-11 03:54:19 +0200	_xor	(~xor@ip-50-5-233-250.dynamic.fuse.net) (Ping timeout: 255 seconds)
2023-10-11 03:54:19 +0200	_xor8	_xor
2023-10-11 04:08:26 +0200	machinedgod	(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds)
2023-10-11 04:13:07 +0200	xff0x	(~xff0x@2405:6580:b080:900:f7aa:8fa9:8388:1900) (Ping timeout: 260 seconds)
2023-10-11 04:13:56 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection)
2023-10-11 04:14:10 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34)
2023-10-11 04:17:06 +0200	[itchyjunk]	(~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer)
2023-10-11 04:18:06 +0200	jinsun	(~jinsun@user/jinsun) (Read error: Connection reset by peer)
2023-10-11 04:21:43 +0200	thegeekinside	(~thegeekin@189.217.90.224) (Remote host closed the connection)
2023-10-11 04:28:34 +0200	thegeekinside	(~thegeekin@189.217.90.224)
2023-10-11 04:37:00 +0200	Sanguine	(~Sanguine@bcdcac82.skybroadband.com) (Ping timeout: 248 seconds)
2023-10-11 04:39:31 +0200	grnman_	(~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) (Ping timeout: 252 seconds)
2023-10-11 04:40:31 +0200	waleee	(~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 255 seconds)
2023-10-11 04:42:45 +0200	FinnElija	(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-10-11 04:42:45 +0200	finn_elija	(~finn_elij@user/finn-elija/x-0085643)
2023-10-11 04:42:45 +0200	finn_elija	FinnElija
2023-10-11 04:49:06 +0200	arahael	(~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net)
2023-10-11 04:53:16 +0200	td_	(~td@i53870936.versanet.de) (Ping timeout: 260 seconds)
2023-10-11 04:54:57 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-10-11 04:59:33 +0200	sm	(~sm@plaintextaccounting/sm)
2023-10-11 04:59:41 +0200	td_	(~td@2001:9e8:19f7:c900:55c4:edef:d459:6ff7)
2023-10-11 04:59:52 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
2023-10-11 05:03:51 +0200	sm	(~sm@plaintextaccounting/sm) (Ping timeout: 240 seconds)
2023-10-11 05:04:08 +0200	xff0x	(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2023-10-11 05:07:49 +0200	Sanguine	(~Sanguine@176.254.244.83)
2023-10-11 05:11:31 +0200	__monty__	(~toonn@user/toonn)
2023-10-11 05:15:48 +0200	__monty__	(~toonn@user/toonn) (Ping timeout: 240 seconds)
2023-10-11 05:16:56 +0200	aforemny_	(~aforemny@i59f516dd.versanet.de)
2023-10-11 05:18:09 +0200	aforemny	(~aforemny@i59F516D8.versanet.de) (Ping timeout: 258 seconds)
2023-10-11 05:20:57 +0200	sm	(~sm@plaintextaccounting/sm)
2023-10-11 05:25:01 +0200	ss4	(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2023-10-11 05:27:02 +0200	wroathe	(~wroathe@user/wroathe) (Ping timeout: 272 seconds)
2023-10-11 05:38:35 +0200	sm	(~sm@plaintextaccounting/sm) (Ping timeout: 240 seconds)
2023-10-11 05:40:05 +0200	YuutaW	(~YuutaW@mail.yuuta.moe) (Ping timeout: 240 seconds)
2023-10-11 05:40:07 +0200	gehmehgeh	(~user@user/gehmehgeh)
2023-10-11 05:41:29 +0200	gmg	(~user@user/gehmehgeh) (Ping timeout: 252 seconds)
2023-10-11 05:41:50 +0200	YuutaW	(~YuutaW@mail.yuuta.moe)
2023-10-11 05:42:56 +0200	Unicorn_Princess	(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2023-10-11 05:45:27 +0200	thegeekinside	(~thegeekin@189.217.90.224) (Read error: Connection reset by peer)
2023-10-11 05:49:12 +0200	shapr	(~user@2600:1700:c640:3100:4d15:1e8d:2f46:bef9) (Remote host closed the connection)
2023-10-11 05:49:25 +0200	shapr	(~user@2600:1700:c640:3100:5112:c2fa:e8e6:5128)
2023-10-11 06:07:53 +0200	stiell	(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 252 seconds)
2023-10-11 06:09:27 +0200	_ht	(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-10-11 06:13:01 +0200	azimut	(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 252 seconds)
2023-10-11 06:13:23 +0200	califax	(~califax@user/califx) (Ping timeout: 252 seconds)
2023-10-11 06:13:24 +0200	azimut	(~azimut@gateway/tor-sasl/azimut)
2023-10-11 06:13:36 +0200	califax_	(~califax@user/califx)
2023-10-11 06:14:51 +0200	califax_	califax
2023-10-11 06:20:05 +0200	lisbeths	(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2023-10-11 06:20:11 +0200	tzh_	(~tzh@c-71-193-181-0.hsd1.or.comcast.net)
2023-10-11 06:20:21 +0200	vglfr	(~vglfr@88.155.190.13)
2023-10-11 06:20:29 +0200	stiell	(~stiell@gateway/tor-sasl/stiell)
2023-10-11 06:20:48 +0200	vglfr	(~vglfr@88.155.190.13) (Remote host closed the connection)
2023-10-11 06:22:27 +0200	vglfr	(~vglfr@88.155.190.13)
2023-10-11 06:22:40 +0200	tzh	(~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Ping timeout: 255 seconds)
2023-10-11 06:24:53 +0200	vglfr	(~vglfr@88.155.190.13) (Remote host closed the connection)
2023-10-11 06:25:37 +0200	tzh_	(~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Ping timeout: 258 seconds)
2023-10-11 06:25:42 +0200	vglfr	(~vglfr@88.155.190.13)
2023-10-11 06:25:51 +0200	vglfr	(~vglfr@88.155.190.13) (Remote host closed the connection)
2023-10-11 06:28:19 +0200	vglfr	(~vglfr@88.155.190.13)
2023-10-11 06:30:04 +0200	vglfr	(~vglfr@88.155.190.13) (Read error: Connection reset by peer)
2023-10-11 06:30:24 +0200	vglfr	(~vglfr@149.102.244.115)
2023-10-11 06:33:14 +0200	vglfr	(~vglfr@149.102.244.115) (Remote host closed the connection)
2023-10-11 06:34:09 +0200	vglfr	(~vglfr@88.155.190.13)
2023-10-11 06:34:17 +0200	vglfr	(~vglfr@88.155.190.13) (Read error: Connection reset by peer)
2023-10-11 06:34:37 +0200	vglfr	(vglfr@gateway/vpn/protonvpn/vglfr)
2023-10-11 06:44:18 +0200	vglfr	(vglfr@gateway/vpn/protonvpn/vglfr) (Ping timeout: 272 seconds)
2023-10-11 06:44:58 +0200	vglfr	(~vglfr@88.155.190.13)
2023-10-11 06:45:33 +0200	danza	(~francesco@151.35.192.230)
2023-10-11 06:47:34 +0200	Pixi`	(~Pixi@user/pixi) (Read error: Connection reset by peer)
2023-10-11 06:52:05 +0200	danza	(~francesco@151.35.192.230) (Ping timeout: 240 seconds)
2023-10-11 06:54:10 +0200	phma	(~phma@host-67-44-208-50.hnremote.net) (Read error: Connection reset by peer)
2023-10-11 06:58:18 +0200	phma	(~phma@2001:5b0:211c:9d28:dc53:577d:4a04:1d14)
2023-10-11 06:58:22 +0200	tzh	(~tzh@c-71-193-181-0.hsd1.or.comcast.net)
2023-10-11 06:58:35 +0200	jinsun	(~jinsun@user/jinsun)
2023-10-11 07:01:42 +0200	__monty__	(~toonn@user/toonn)
2023-10-11 07:05:33 +0200	Pixi	(~Pixi@user/pixi)
2023-10-11 07:11:58 +0200	michalz	(~michalz@185.246.207.200)
2023-10-11 07:14:41 +0200	phma	(~phma@2001:5b0:211c:9d28:dc53:577d:4a04:1d14) (Read error: Connection reset by peer)
2023-10-11 07:14:55 +0200	takuan	(~takuan@178-116-218-225.access.telenet.be)
2023-10-11 07:16:46 +0200	phma	(~phma@host-67-44-208-58.hnremote.net)
2023-10-11 07:34:06 +0200	Square3	(~Square4@user/square)
2023-10-11 07:34:46 +0200	danse-nr3	(~francesco@151.35.192.230)
2023-10-11 07:35:23 +0200	_ht	(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-10-11 07:36:52 +0200	Square2	(~Square4@user/square) (Ping timeout: 272 seconds)
2023-10-11 07:44:56 +0200	idgaen	(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-10-11 07:47:29 +0200	misterfish	(~misterfis@84-53-85-146.bbserv.nl)
2023-10-11 07:49:31 +0200	vglfr	(~vglfr@88.155.190.13) (Ping timeout: 264 seconds)
2023-10-11 07:50:48 +0200	<danse-nr3>	good morning #haskell
2023-10-11 07:58:20 +0200	acidjnk	(~acidjnk@p200300d6e7072f8019cae40178150491.dip0.t-ipconnect.de)
2023-10-11 07:59:06 +0200	vglfr	(~vglfr@88.155.190.13)
2023-10-11 08:00:12 +0200	Unicorn_Princess	(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2023-10-11 08:07:21 +0200	<dminuoso>	Good morning.
2023-10-11 08:08:06 +0200	hugo	(znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds)
2023-10-11 08:11:36 +0200	tromp	(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-10-11 08:13:03 +0200	notzmv	(~zmv@user/notzmv) (Ping timeout: 240 seconds)
2023-10-11 08:17:21 +0200	sord937	(~sord937@gateway/tor-sasl/sord937)
2023-10-11 08:21:28 +0200	bilegeek	(~bilegeek@2600:1008:b004:d50e:d8be:4118:2b29:669c) (Quit: Leaving)
2023-10-11 08:22:53 +0200	hugo	(znc@verdigris.lysator.liu.se)
2023-10-11 08:29:16 +0200	hugo	(znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds)
2023-10-11 08:32:40 +0200	Jesin	(~Jesin@pool-72-83-12-199.washdc.fios.verizon.net)
2023-10-11 08:38:57 +0200	danse-nr3_	(~francesco@151.35.192.230)
2023-10-11 08:41:27 +0200	danse-nr3	(~francesco@151.35.192.230) (Ping timeout: 260 seconds)
2023-10-11 08:42:11 +0200	danse-nr3	(~francesco@151.35.192.230)
2023-10-11 08:42:12 +0200	CiaoSen	(~Jura@2a05:5800:2c3:8c00:664b:f0ff:fe37:9ef)
2023-10-11 08:44:48 +0200	Jesin	(~Jesin@pool-72-83-12-199.washdc.fios.verizon.net) (Quit: Jesin)
2023-10-11 08:45:16 +0200	danse-nr3_	(~francesco@151.35.192.230) (Quit: Leaving)
2023-10-11 08:50:26 +0200	lortabac	(~lortabac@2a01:e0a:541:b8f0:8b9c:51e3:d64a:72e4)
2023-10-11 08:56:28 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-10-11 09:01:03 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
2023-10-11 09:04:21 +0200	danse-nr3	(~francesco@151.35.192.230) (Read error: Connection reset by peer)
2023-10-11 09:04:27 +0200	danse-nr3_	(~francesco@151.35.217.158)
2023-10-11 09:09:47 +0200	azimut	(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2023-10-11 09:10:09 +0200	azimut	(~azimut@gateway/tor-sasl/azimut)
2023-10-11 09:11:41 +0200	cfricke	(~cfricke@user/cfricke)
2023-10-11 09:14:55 +0200	fendor	(~fendor@2a02:8388:1640:be00:aab:1226:f274:5021)
2023-10-11 09:17:54 +0200	hugo-	(znc@verdigris.lysator.liu.se)
2023-10-11 09:20:31 +0200	lisbeths	(uid135845@id-135845.lymington.irccloud.com)
2023-10-11 09:34:09 +0200	idgaen	(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.5)
2023-10-11 09:36:18 +0200	zer0bitz	(~zer0bitz@user/zer0bitz) (Read error: Connection reset by peer)
2023-10-11 09:36:20 +0200	<Hecate>	morning morning
2023-10-11 09:37:21 +0200	Pickchea	(~private@user/pickchea)
2023-10-11 09:37:52 +0200	<tomsmeding>	The haskell playground currently has so far carried compilers back to ghc 8.6.5. Just now I added 8.4.4 because I could. Should it go further back? Should we drop old compilers at some point? Or should the list ever keep getting longer?
2023-10-11 09:37:57 +0200	<tomsmeding>	Opinion time! :D
2023-10-11 09:39:01 +0200	<Hecate>	well, having these older versions are indeed nice because you get to compare the generated Core/STG/ASM outputs
2023-10-11 09:39:06 +0200	<Hecate>	that is objectively useful
2023-10-11 09:39:41 +0200	<Hecate>	now the "problem" (which is quite unavoidable) is that the packages that are exposed will certainly have opinions about which GHC versions they want to run on
2023-10-11 09:40:50 +0200	tromp	(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-10-11 09:41:06 +0200	<tomsmeding>	In what sense? They can just select their preferred GHC version, right?
2023-10-11 09:41:07 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds)
2023-10-11 09:41:32 +0200	<tomsmeding>	I have a wishlist of packages and provide, for each GHC version, all that will build
2023-10-11 09:41:35 +0200	euleritian	(~euleritia@dynamic-046-114-204-165.46.114.pool.telefonica.de)
2023-10-11 09:42:13 +0200	<tomsmeding>	It's a bit imperfect because sometimes cabal's solver tends to select very old versions to make the plan work and I should probably avoid that with some well-chosen lower boubds
2023-10-11 09:42:42 +0200	euleritian	(~euleritia@dynamic-046-114-204-165.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-10-11 09:42:59 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-10-11 09:45:40 +0200	aforemny_	aforemny
2023-10-11 09:49:48 +0200	shriekingnoise	(~shrieking@186.137.175.87) (Ping timeout: 240 seconds)
2023-10-11 09:55:18 +0200	tromp	(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-10-11 09:57:44 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 246 seconds)
2023-10-11 09:58:37 +0200	euleritian	(~euleritia@dynamic-046-114-204-165.46.114.pool.telefonica.de)
2023-10-11 10:03:48 +0200	Pickchea	(~private@user/pickchea) (Quit: Leaving)
2023-10-11 10:10:07 +0200	zer0bitz	(~zer0bitz@user/zer0bitz)
2023-10-11 10:16:18 +0200	<[exa]>	tomsmeding: opinion: I'm trying not to care about ghc version
2023-10-11 10:16:39 +0200	<[exa]>	but still thanks for the great effort
2023-10-11 10:18:18 +0200	euleritian	(~euleritia@dynamic-046-114-204-165.46.114.pool.telefonica.de) (Ping timeout: 258 seconds)
2023-10-11 10:19:21 +0200	dsrt^	(~cd@76.145.193.217) (Remote host closed the connection)
2023-10-11 10:19:39 +0200	dsrt^	(~cd@76.145.193.217)
2023-10-11 10:20:05 +0200	<tomsmeding>	<3
2023-10-11 10:22:07 +0200	notzmv	(~zmv@user/notzmv)
2023-10-11 10:23:24 +0200	mc47	(~mc47@xmonad/TheMC47)
2023-10-11 10:26:41 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection)
2023-10-11 10:27:29 +0200	tomih_	(tomith@85-156-187-17.elisa-laajakaista.fi)
2023-10-11 10:28:12 +0200	danse-nr3_	(~francesco@151.35.217.158) (Ping timeout: 240 seconds)
2023-10-11 10:28:57 +0200	bitdex	(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds)
2023-10-11 10:30:03 +0200	azimut	(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 252 seconds)
2023-10-11 10:30:07 +0200	tomith	(tomith@user/tomith) (Read error: Connection reset by peer)
2023-10-11 10:30:10 +0200	tomih_	tomith
2023-10-11 10:33:26 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net)
2023-10-11 10:35:03 +0200	Jackneill	(~Jackneill@20014C4E1E021C00E4226B7959631CE0.dsl.pool.telekom.hu)
2023-10-11 10:35:24 +0200	coot	(~coot@89-69-206-216.dynamic.chello.pl)
2023-10-11 10:37:30 +0200	chele	(~chele@user/chele)
2023-10-11 10:38:42 +0200	Square3	(~Square4@user/square) (Ping timeout: 260 seconds)
2023-10-11 10:38:43 +0200	tromp	(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-10-11 10:41:20 +0200	<cpressey>	tomsmeding: I don't have enough context to give you an opinion, but as a data point, I regularly use a tool that only works with ghc 7.10. (I run it from a Docker container).
2023-10-11 10:43:47 +0200	<tomsmeding>	heh
2023-10-11 10:44:19 +0200	<tomsmeding>	cpressey: for my curiosity, in what way does it break if you run it with ghc 8.0?
2023-10-11 10:44:56 +0200	<tomsmeding>	(ghc 7.10 doesn't install from ghcup -- something _segfaults_, of all things)
2023-10-11 10:45:20 +0200	tzh	(~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Quit: zzz)
2023-10-11 10:46:44 +0200	<cpressey>	tomsmeding: It's https://github.com/valderman/haste-compiler . As I understand it, it relies on ghc internals to do the compiling. ghc internals change (obvs), it was a thesis project of the author's and they have insufficient interest in it to update it.
2023-10-11 10:47:26 +0200	<tomsmeding>	fair, I wasn't wondering why it wasn't updated -- these things happen. I was just wondering if it relied on GHC internals, and if it had any right to do so :p
2023-10-11 10:47:30 +0200	<tomsmeding>	but it seems this clearly does
2023-10-11 10:48:42 +0200	<tomsmeding>	I mean, GHCJS exists
2023-10-11 10:48:51 +0200	<tomsmeding>	but "if it works, don't touch it"
2023-10-11 10:48:52 +0200	<cpressey>	I could try switching to a different Haskell-to-JS compiler but all the ones I've seen seem immensely complicated to set up compared to haste.
2023-10-11 10:51:39 +0200	econo_	(uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2023-10-11 10:57:35 +0200	machinedgod	(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-10-11 10:58:17 +0200	hugo-	(znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds)
2023-10-11 10:58:55 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34)
2023-10-11 11:02:04 +0200	danse-nr3_	(~francesco@151.35.217.158)
2023-10-11 11:02:41 +0200	Sgeo	(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-10-11 11:03:48 +0200	<sshine>	have you considered ghc wasm backend?
2023-10-11 11:05:39 +0200	tromp	(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-10-11 11:08:59 +0200	simendsjo	(~user@84.211.91.241)
2023-10-11 11:20:53 +0200	<cpressey>	sshine: Not yet, and I wouldn't expect it to happen unless/until my perception of "messing with wasm" switches from it being a "dreadful thing" to it being a "fun thing". I don't have an ETA on that at present.
2023-10-11 11:24:14 +0200	<ncf>	there's a js backend now
2023-10-11 11:24:31 +0200	vglfr	(~vglfr@88.155.190.13) (Read error: Connection reset by peer)
2023-10-11 11:25:24 +0200	<arahael>	That js backend terrifies me.
2023-10-11 11:25:48 +0200	<haskellbridge>	<sm> cpressey I like this metric, could apply to many things
2023-10-11 11:29:02 +0200	hugo-	(znc@verdigris.lysator.liu.se)
2023-10-11 11:36:52 +0200	<sand-witch>	tomsmeding: Vlad also wants to implement T2T for both patterns and expressions at 9.10, so you would able to write "id t x = x :: t" (where "id :: forall a -> a -> a") and apply it as "id Int 5", without any "type" keywords
2023-10-11 11:40:23 +0200	shapr	(~user@2600:1700:c640:3100:5112:c2fa:e8e6:5128) (Remote host closed the connection)
2023-10-11 11:40:36 +0200	shapr	(~user@2600:1700:c640:3100:fb57:2f19:4620:f3bb)
2023-10-11 11:42:15 +0200	hugo-	(znc@verdigris.lysator.liu.se) (Ping timeout: 258 seconds)
2023-10-11 11:42:55 +0200	xigua	(~xigua@user/xigua) (Remote host closed the connection)
2023-10-11 11:43:29 +0200	xigua	(~xigua@user/xigua)
2023-10-11 11:43:54 +0200	<albet70>	what is functor compose?
2023-10-11 11:44:34 +0200	<albet70>	foldr (:) [] (Compose [Nothing, Just 3])
2023-10-11 11:44:40 +0200	<ncf>	like function composition, but for functors
2023-10-11 11:45:06 +0200	<ncf>	:k Compose
2023-10-11 11:45:07 +0200	<lambdabot>	error:
2023-10-11 11:45:07 +0200	<lambdabot>	Not in scope: type constructor or class ‘Compose’
2023-10-11 11:45:10 +0200	hiyori	(~hiyori@user/hiyori)
2023-10-11 11:46:17 +0200	<albet70>	foldr (:) [] on this functor compose, why [3] is left?
2023-10-11 11:47:08 +0200	<sshine>	sand-witch, is that types as values?
2023-10-11 11:48:00 +0200	<ncf>	albet70: this appears to be using the (Foldable f, Foldable g) => Foldable (Compose f g) instance
2023-10-11 11:48:10 +0200	<ncf>	:t foldr (:) []
2023-10-11 11:48:11 +0200	<lambdabot>	Foldable t => t a -> [a]
2023-10-11 11:49:00 +0200	<ncf>	if you see [_, _] as a container with two holes, Nothing as a container with zero holes and Just _ as a container with one hole, then via the composite instance [Nothing, Just 3] contains just 3
2023-10-11 11:52:04 +0200	hugo-	(znc@verdigris.lysator.liu.se)
2023-10-11 11:52:44 +0200	<tomsmeding>	sand-witch: :D
2023-10-11 11:55:13 +0200	<sand-witch>	sshine: nope, they would be erased on compile time
2023-10-11 11:57:24 +0200	ft	(~ft@p3e9bc680.dip0.t-ipconnect.de) (Quit: leaving)
2023-10-11 11:59:37 +0200	<dminuoso>	In some sense `(Foldable f, Foldable g) => Foldable (Compose f g)` is just another way of expressing `Monad []`
2023-10-11 12:00:36 +0200	<albet70>	this Compose reminds me 'maybe' somehow, and 'traverse'
2023-10-11 12:01:18 +0200	<albet70>	maybe can turn Maybe monad to another monad
2023-10-11 12:01:24 +0200	<dminuoso>	Or let me ponder about this.
2023-10-11 12:01:53 +0200	<dminuoso>	Actually on second thought, those things are not equivalent.
2023-10-11 12:01:53 +0200	<albet70>	but monad does not compose, this functor do compose
2023-10-11 12:02:01 +0200	<dminuoso>	> join [[1,2], [3,4]]
2023-10-11 12:02:02 +0200	<ncf>	(f a -> [a]) -> (g a -> [a]) -> (f (g a) -> [a]) does turn into join :: [[a]] -> [a] by yoneda, but you don't get return out of this
2023-10-11 12:02:02 +0200	<lambdabot>	[1,2,3,4]
2023-10-11 12:02:08 +0200	<dminuoso>	Or no, actually they are the same.
2023-10-11 12:02:14 +0200	<dminuoso>	Nevermind, its a good statement.
2023-10-11 12:02:25 +0200	<dminuoso>	albet70: Well monad is about composition.
2023-10-11 12:02:37 +0200	<ncf>	so it's a way of expressing half of the [] monad :)
2023-10-11 12:02:45 +0200	<dminuoso>	Its quite literally about being able to do `T :.: T ~> T` in a sensible way
2023-10-11 12:03:21 +0200	<dminuoso>	Where :.: is just infix Compose
2023-10-11 12:05:44 +0200	<albet70>	dminuoso , what's its name? natural transparent?
2023-10-11 12:05:58 +0200	hiyori	(~hiyori@user/hiyori) (Ping timeout: 245 seconds)
2023-10-11 12:06:59 +0200	<dminuoso>	albet70: Its a natural transformation. But if we ignore this fancy sounding name `T :.: T ~> T` is just another way of expressing `T a :.: T a -> T a`
2023-10-11 12:07:40 +0200	<dminuoso>	Which using Compose would just be written `(Compose T T) a -> T a`, which is isomorphic to just `T (T a) -> T a`
2023-10-11 12:07:43 +0200	<dminuoso>	And indeed:
2023-10-11 12:07:46 +0200	<dminuoso>	:t join
2023-10-11 12:07:47 +0200	<lambdabot>	Monad m => m (m a) -> m a
2023-10-11 12:07:50 +0200	<dminuoso>	:t join @[]
2023-10-11 12:07:51 +0200	<lambdabot>	error:
2023-10-11 12:07:51 +0200	<lambdabot>	Pattern syntax in expression context: join@[]
2023-10-11 12:07:51 +0200	<lambdabot>	Did you mean to enable TypeApplications?
2023-10-11 12:08:01 +0200	<dminuoso>	% set -XTypeApplications
2023-10-11 12:08:01 +0200	<yahb2>	<interactive>:7:1: error: ; • Variable not in scope: set ; • Perhaps you meant ‘seq’ (imported from Prelude) ; ; <interactive>:7:6: error: ; Data constructor not in scope: XTypeApplica...
2023-10-11 12:08:06 +0200	<dminuoso>	% :set -XTypeApplications
2023-10-11 12:08:06 +0200	<yahb2>	<no output>
2023-10-11 12:08:14 +0200	<dminuoso>	% :t join @[]
2023-10-11 12:08:14 +0200	<yahb2>	<interactive>:1:1: error: Variable not in scope: join
2023-10-11 12:08:17 +0200	<dminuoso>	Jeez.
2023-10-11 12:08:41 +0200	<dminuoso>	% :t join @[]
2023-10-11 12:08:41 +0200	<yahb2>	join @[] :: Monad [] => [[a]] -> [a]
2023-10-11 12:12:28 +0200	__monty__	(~toonn@user/toonn) (Ping timeout: 248 seconds)
2023-10-11 12:14:53 +0200	xff0x	(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 255 seconds)
2023-10-11 12:20:56 +0200	__monty__	(~toonn@user/toonn)
2023-10-11 12:26:56 +0200	__monty__	(~toonn@user/toonn) (Ping timeout: 272 seconds)
2023-10-11 12:40:49 +0200	coot	(~coot@89-69-206-216.dynamic.chello.pl) (Ping timeout: 255 seconds)
2023-10-11 12:41:45 +0200	[itchyjunk]	(~itchyjunk@user/itchyjunk/x-7353470)
2023-10-11 12:44:33 +0200	pavonia	(~user@user/siracusa) (Quit: Bye!)
2023-10-11 12:48:11 +0200	hugo-	(znc@verdigris.lysator.liu.se) (Ping timeout: 246 seconds)
2023-10-11 12:48:14 +0200	smalltalkman	(uid545680@id-545680.hampstead.irccloud.com) (Quit: Connection closed for inactivity)
2023-10-11 12:48:51 +0200	hiyori	(~hiyori@user/hiyori)
2023-10-11 12:48:51 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed)
2023-10-11 12:54:30 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net)
2023-10-11 12:55:32 +0200	privacy	(~privacy@user/privacy)
2023-10-11 12:57:59 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-10-11 13:03:16 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
2023-10-11 13:04:18 +0200	danse-nr3__	(~francesco@151.37.199.183)
2023-10-11 13:04:29 +0200	danse-nr3_	(~francesco@151.35.217.158) (Read error: Connection reset by peer)
2023-10-11 13:04:52 +0200	Unicorn_Princess	(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2023-10-11 13:06:19 +0200	arahael	(~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) (Ping timeout: 255 seconds)
2023-10-11 13:06:44 +0200	xff0x	(~xff0x@ai101218.d.east.v6connect.net)
2023-10-11 13:08:04 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-10-11 13:09:41 +0200	CiaoSen	(~Jura@2a05:5800:2c3:8c00:664b:f0ff:fe37:9ef) (Ping timeout: 260 seconds)
2023-10-11 13:11:12 +0200	vglfr	(~vglfr@88.155.190.13)
2023-10-11 13:11:57 +0200	danse-nr3__	(~francesco@151.37.199.183) (Ping timeout: 258 seconds)
2023-10-11 13:14:15 +0200	hugo-	(znc@verdigris.lysator.liu.se)
2023-10-11 13:14:47 +0200	tromp	(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-10-11 13:15:47 +0200	arahael	(~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net)
2023-10-11 13:17:08 +0200	Cajun	(~Cajun@user/cajun)
2023-10-11 13:17:17 +0200	smalltalkman	(uid545680@id-545680.hampstead.irccloud.com)
2023-10-11 13:18:35 +0200	__monty__	(~toonn@user/toonn)
2023-10-11 13:20:23 +0200	vglfr	(~vglfr@88.155.190.13) (Ping timeout: 258 seconds)
2023-10-11 13:21:55 +0200	gehmehgeh	(~user@user/gehmehgeh) (Remote host closed the connection)
2023-10-11 13:22:42 +0200	gehmehgeh	(~user@user/gehmehgeh)
2023-10-11 13:24:34 +0200	vglfr	(~vglfr@88.155.190.13)
2023-10-11 13:25:54 +0200	Luj	(~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) (Quit: The Lounge - https://thelounge.chat)
2023-10-11 13:27:48 +0200	Luj	(~Luj@2a01:e0a:5f9:9681:c367:ba44:42cf:91d7)
2023-10-11 13:29:33 +0200	fendor	(~fendor@2a02:8388:1640:be00:aab:1226:f274:5021) (Remote host closed the connection)
2023-10-11 13:30:09 +0200	lisbeths	(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2023-10-11 13:32:41 +0200	privacy	(~privacy@user/privacy) (Quit: Leaving)
2023-10-11 13:40:42 +0200	CiaoSen	(~Jura@2a05:5800:2c3:8c00:664b:f0ff:fe37:9ef)
2023-10-11 13:47:56 +0200	[itchyjunk]	(~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2023-10-11 13:52:11 +0200	diamond	(~user@89.223.35.3)
2023-10-11 14:05:14 +0200	kuribas	(~user@ip-188-118-57-242.reverse.destiny.be)
2023-10-11 14:07:04 +0200	vglfr	(~vglfr@88.155.190.13) (Ping timeout: 255 seconds)
2023-10-11 14:11:34 +0200	Cajun	(~Cajun@user/cajun) (Quit: Client closed)
2023-10-11 14:13:00 +0200	cods	(~fred@82-65-232-44.subs.proxad.net) (Ping timeout: 240 seconds)
2023-10-11 14:17:21 +0200	vglfr	(~vglfr@88.155.190.13)
2023-10-11 14:20:26 +0200	cods	(~fred@tuxee.net)
2023-10-11 14:34:27 +0200	sm	(~sm@plaintextaccounting/sm)
2023-10-11 14:36:26 +0200	sm	(~sm@plaintextaccounting/sm) (Client Quit)
2023-10-11 14:44:11 +0200	hugo-	hug
2023-10-11 14:46:47 +0200	wroathe	(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-10-11 14:46:47 +0200	wroathe	(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-10-11 14:46:47 +0200	wroathe	(~wroathe@user/wroathe)
2023-10-11 14:57:48 +0200	hug	(znc@verdigris.lysator.liu.se) (Ping timeout: 248 seconds)
2023-10-11 14:58:15 +0200	pounce	(~pounce@user/cute/pounce) (Remote host closed the connection)
2023-10-11 14:58:33 +0200	pounce	(~pounce@user/cute/pounce)
2023-10-11 15:00:05 +0200	lortabac	(~lortabac@2a01:e0a:541:b8f0:8b9c:51e3:d64a:72e4) (Quit: WeeChat 2.8)
2023-10-11 15:01:49 +0200	shriekingnoise	(~shrieking@186.137.175.87)
2023-10-11 15:02:21 +0200	YuutaW	(~YuutaW@mail.yuuta.moe) (Ping timeout: 258 seconds)
2023-10-11 15:03:33 +0200	YuutaW	(~YuutaW@mail.yuuta.moe)
2023-10-11 15:03:35 +0200	pounce	(~pounce@user/cute/pounce) (Remote host closed the connection)
2023-10-11 15:03:52 +0200	pounce	(~pounce@user/cute/pounce)
2023-10-11 15:04:53 +0200	billchenchina	(~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe)
2023-10-11 15:05:57 +0200	pounce	(~pounce@user/cute/pounce) (Remote host closed the connection)
2023-10-11 15:12:15 +0200	pounce	(~pounce@user/cute/pounce)
2023-10-11 15:12:42 +0200	hugo-	(znc@verdigris.lysator.liu.se)
2023-10-11 15:13:05 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 246 seconds)
2023-10-11 15:13:51 +0200	euleritian	(~euleritia@dynamic-046-114-206-159.46.114.pool.telefonica.de)
2023-10-11 15:17:51 +0200	wroathe	(~wroathe@user/wroathe) (Ping timeout: 240 seconds)
2023-10-11 15:19:11 +0200	pounce	(~pounce@user/cute/pounce) (Ping timeout: 260 seconds)
2023-10-11 15:20:11 +0200	danse-nr3	(~francesco@151.37.199.183)
2023-10-11 15:21:40 +0200	hiyori	(~hiyori@user/hiyori) (Quit: Client closed)
2023-10-11 15:22:22 +0200	fweht	(uid404746@id-404746.lymington.irccloud.com)
2023-10-11 15:23:17 +0200	euleritian	(~euleritia@dynamic-046-114-206-159.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-10-11 15:23:36 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-10-11 15:27:05 +0200	oo_miguel	(~Thunderbi@78-11-179-96.static.ip.netia.com.pl)
2023-10-11 15:27:40 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 248 seconds)
2023-10-11 15:28:00 +0200	euleritian	(~euleritia@dynamic-046-114-206-159.46.114.pool.telefonica.de)
2023-10-11 15:29:48 +0200	YuutaW	(~YuutaW@mail.yuuta.moe) (Ping timeout: 240 seconds)
2023-10-11 15:31:27 +0200	lena64t	(~lena64t@gateway/tor-sasl/hck) (Ping timeout: 252 seconds)
2023-10-11 15:32:04 +0200	shapr	(~user@2600:1700:c640:3100:fb57:2f19:4620:f3bb) (Remote host closed the connection)
2023-10-11 15:32:18 +0200	shapr	(~user@2600:1700:c640:3100:e8fe:9f19:d6ff:62f3)
2023-10-11 15:32:51 +0200	YuutaW	(~YuutaW@mail.yuuta.moe)
2023-10-11 15:35:06 +0200	robobub	(uid248673@id-248673.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-10-11 15:35:21 +0200	pounce	(~pounce@user/cute/pounce)
2023-10-11 15:35:38 +0200	lena64t	(~lena64t@gateway/tor-sasl/hck)
2023-10-11 15:36:05 +0200	pounce	(~pounce@user/cute/pounce) (Remote host closed the connection)
2023-10-11 15:36:23 +0200	euleritian	(~euleritia@dynamic-046-114-206-159.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-10-11 15:36:41 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-10-11 15:36:54 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed)
2023-10-11 15:37:10 +0200	pounce	(~pounce@user/cute/pounce)
2023-10-11 15:37:51 +0200	notzmv	(~zmv@user/notzmv) (Ping timeout: 260 seconds)
2023-10-11 15:46:57 +0200	jespada	(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net)
2023-10-11 15:48:28 +0200	hiyori	(~hiyori@user/hiyori)
2023-10-11 15:49:31 +0200	arahael	(~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) (Ping timeout: 264 seconds)
2023-10-11 15:49:40 +0200	__monty__	(~toonn@user/toonn) (Ping timeout: 255 seconds)
2023-10-11 15:51:05 +0200	__monty__	(~toonn@user/toonn)
2023-10-11 15:51:30 +0200	sm	(~sm@plaintextaccounting/sm)
2023-10-11 15:51:37 +0200	ec	(~ec@gateway/tor-sasl/ec) (Ping timeout: 252 seconds)
2023-10-11 15:53:30 +0200	ec	(~ec@gateway/tor-sasl/ec)
2023-10-11 15:54:06 +0200	lg188	(~lg188@82.18.98.230) (Quit: Ping timeout (120 seconds))
2023-10-11 15:54:59 +0200	lg188	(~lg188@82.18.98.230)
2023-10-11 15:55:28 +0200	lg188	(~lg188@82.18.98.230) (Remote host closed the connection)
2023-10-11 15:58:33 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2023-10-11 15:59:12 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-10-11 16:01:14 +0200	lg188	(~lg188@82.18.98.230)
2023-10-11 16:02:22 +0200	sm	(~sm@plaintextaccounting/sm) (Quit: sm)
2023-10-11 16:02:46 +0200	ames	(~amelia@offtopia/offtopian/amelia) (Quit: Ping timeout (120 seconds))
2023-10-11 16:03:19 +0200	alphacentauri	(alphacenta@gateway/vpn/protonvpn/alphacentauri) (Ping timeout: 255 seconds)
2023-10-11 16:03:50 +0200	Franciman	(~Franciman@mx1.fracta.dev) (Read error: Connection reset by peer)
2023-10-11 16:04:04 +0200	pierrot	(~pi@user/pierrot) (Quit: ZNC 1.8.2 - http://znc.in)
2023-10-11 16:05:17 +0200	grnman_	(~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net)
2023-10-11 16:05:27 +0200	sm	(~sm@plaintextaccounting/sm)
2023-10-11 16:11:46 +0200	simendsjo	(~user@84.211.91.241) (Ping timeout: 272 seconds)
2023-10-11 16:12:21 +0200	CiaoSen	(~Jura@2a05:5800:2c3:8c00:664b:f0ff:fe37:9ef) (Ping timeout: 260 seconds)
2023-10-11 16:19:35 +0200	Simikando	(~Simikando@adsl-dyn230.91-127-81.t-com.sk)
2023-10-11 16:26:26 +0200	hiyori	(~hiyori@user/hiyori) (Quit: Client closed)
2023-10-11 16:26:37 +0200	hiyori	(~hiyori@user/hiyori)
2023-10-11 16:27:06 +0200	thegeekinside	(~thegeekin@189.217.90.224)
2023-10-11 16:34:29 +0200	xigua	(~xigua@user/xigua) (Remote host closed the connection)
2023-10-11 16:35:02 +0200	xigua	(~xigua@user/xigua)
2023-10-11 16:38:56 +0200	Pozyomka	(~pyon@user/pyon) (Quit: Pozyomka, my beloved: https://i.imgur.com/BMmVfTq.png)
2023-10-11 16:39:23 +0200	xigua	(~xigua@user/xigua) (Remote host closed the connection)
2023-10-11 16:39:53 +0200	YuutaW	(~YuutaW@mail.yuuta.moe) (Ping timeout: 246 seconds)
2023-10-11 16:39:57 +0200	xigua	(~xigua@user/xigua)
2023-10-11 16:40:23 +0200	YuutaW	(~YuutaW@2404:f4c0:f9c3:502::100:17b7)
2023-10-11 16:41:02 +0200	jrm	(~jrm@user/jrm) (Quit: ciao)
2023-10-11 16:42:36 +0200	jrm	(~jrm@user/jrm)
2023-10-11 16:45:24 +0200	Simikando	(~Simikando@adsl-dyn230.91-127-81.t-com.sk) (Ping timeout: 240 seconds)
2023-10-11 16:50:41 +0200	jrm	(~jrm@user/jrm) (Quit: ciao)
2023-10-11 16:52:04 +0200	jrm	(~jrm@user/jrm)
2023-10-11 16:53:49 +0200	ames	(~amelia@offtopia/offtopian/amelia)
2023-10-11 16:55:14 +0200	Franciman	(~Franciman@mx1.fracta.dev)
2023-10-11 16:56:37 +0200	alphacentauri	(alphacenta@gateway/vpn/protonvpn/alphacentauri)
2023-10-11 16:58:20 +0200	<kuribas>	It looks like when throwing an error, the application is not return an proper error code (1)?
2023-10-11 16:58:54 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net)
2023-10-11 16:59:10 +0200	Simikando	(~Simikando@adsl-dyn230.91-127-81.t-com.sk)
2023-10-11 16:59:12 +0200	pierrot	(~pi@user/pierrot)
2023-10-11 16:59:16 +0200	<geekosaur>	?
2023-10-11 16:59:29 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-10-11 17:01:10 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 272 seconds)
2023-10-11 17:03:19 +0200	tzh	(~tzh@c-71-193-181-0.hsd1.or.comcast.net)
2023-10-11 17:03:47 +0200	Simikando	(~Simikando@adsl-dyn230.91-127-81.t-com.sk) (Ping timeout: 255 seconds)
2023-10-11 17:04:00 +0200	danse-nr3	(~francesco@151.37.199.183) (Read error: Connection reset by peer)
2023-10-11 17:04:15 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
2023-10-11 17:04:20 +0200	<geekosaur>	https://paste.tomsmeding.com/RWqFNwGR `error` seems to produce a nonzero error code from the program. if it's not, I'd check for `catch`es that don't re-throw properly
2023-10-11 17:04:37 +0200	danse-nr3	(~francesco@151.37.182.55)
2023-10-11 17:04:49 +0200	<haskellbridge>	<Inst> Here's something I don't get. How does `join` even work?
2023-10-11 17:05:02 +0200	<haskellbridge>	<Inst> (>>= id)
2023-10-11 17:05:07 +0200	<haskellbridge>	<Inst> id doesn't have the right type signature, no?
2023-10-11 17:05:20 +0200	<kuribas>	geekosaur: hmm right, I suppose something else is going on in my code then...
2023-10-11 17:05:25 +0200	<c_wraith>	Inst: sure it does. But expand it.
2023-10-11 17:05:43 +0200	<geekosaur>	`a` unifies with anything, as long as it's the same thing on both sides of the arrow
2023-10-11 17:05:52 +0200	<kuribas>	geekosaur: indeed, I am catching and collecting the errors elsewhere.
2023-10-11 17:05:55 +0200	<haskellbridge>	<Inst> (>>=) :: m a -> (a -> m b) -> m b
2023-10-11 17:06:05 +0200	<haskellbridge>	<Inst> id :: a -> a
2023-10-11 17:06:28 +0200	<c_wraith>	Inst: join x = x >>= id --- join x = x >>= \y -> y ---- join x = do {y <- x ; y}
2023-10-11 17:06:36 +0200	<haskellbridge>	<Inst> erm, id :: a2 -> a2
2023-10-11 17:06:46 +0200	shapr	(~user@2600:1700:c640:3100:e8fe:9f19:d6ff:62f3) (Remote host closed the connection)
2023-10-11 17:06:59 +0200	shapr	(~user@2600:1700:c640:3100:ae91:4ce3:990:5e2b)
2023-10-11 17:07:20 +0200	euleritian	(~euleritia@46.114.206.159)
2023-10-11 17:07:51 +0200	<haskellbridge>	<Inst> it's still freaky
2023-10-11 17:07:59 +0200	Simikando	(~Simikando@adsl-dyn230.91-127-81.t-com.sk)
2023-10-11 17:08:06 +0200	<geekosaur>	that's Hindley-Milner for you
2023-10-11 17:08:24 +0200	<EvanR>	Inst, pretend >>= is an operation on IO actions and followup callbacks that use the result
2023-10-11 17:08:30 +0200	<c_wraith>	Inst: now work on fix :: (IO a -> IO a) -> IO a
2023-10-11 17:08:50 +0200	<EvanR>	then join does the obvious
2023-10-11 17:10:25 +0200	<EvanR>	in the context of IO (IO a)
2023-10-11 17:11:15 +0200	<c_wraith>	Inst: in any case, going back purely to types. given what you wrote, you immediately derive a2 ~ a, a2 ~ m b. From those, you derived a ~ m b. Then the type of (>>=) is restricted to m (m b) -> (m b -> m b) -> m b
2023-10-11 17:11:24 +0200	<haskellbridge>	<Inst> I don't have the intellectual background / understanding of HM to understand how this is supposed to work, I just know it works, and is convenient in a few rare usecases
2023-10-11 17:11:40 +0200	<geekosaur>	see what c_wraith just wrote
2023-10-11 17:11:53 +0200	<haskellbridge>	<Inst> yeah, just saw it
2023-10-11 17:12:44 +0200	<[exa]>	Inst: a very little bit of prolog practice usually solves all problem with unification-heavy algorithms like HM
2023-10-11 17:13:29 +0200	<EvanR>	the identity function works for all types, that part shouldn't be confusing right
2023-10-11 17:13:43 +0200	<EvanR>	if it couldn't specialize to the appropriate type, how would it ever work
2023-10-11 17:13:51 +0200	<kuribas>	:t (>>=) id
2023-10-11 17:13:52 +0200	<lambdabot>	(a -> a -> b) -> a -> b
2023-10-11 17:14:06 +0200	<geekosaur>	but for most people prolog makes haskell look "normal" 😛
2023-10-11 17:14:26 +0200	<kuribas>	:t (>>= id)
2023-10-11 17:14:27 +0200	<lambdabot>	Monad m => m (m b) -> m b
2023-10-11 17:14:41 +0200	<[exa]>	geekosaur: true point
2023-10-11 17:14:45 +0200	<EvanR>	id 7 = 7, but Inst you should be surprised because id doesn't have the right ype?
2023-10-11 17:15:00 +0200	<haskellbridge>	<Inst> yeah, i know, the :t on (>>= id) makes sense and is understandable, but it's hard for me to grok the loopholes that somehow make (>>= id) work
2023-10-11 17:15:09 +0200	<kuribas>	id here is (m b -> m b)
2023-10-11 17:15:10 +0200	<dolio>	You don't need to understand Hindley-Milner. But you need to understand how to unify two types.
2023-10-11 17:15:35 +0200	YuutaW	(~YuutaW@2404:f4c0:f9c3:502::100:17b7) (Ping timeout: 246 seconds)
2023-10-11 17:15:56 +0200	<haskellbridge>	<Inst> yeah, tbh, implicitly this is a big problem, when i was very early on my Haskell journey, it was the type system that weirded me out
2023-10-11 17:15:59 +0200	<c_wraith>	yeah, I actually don't understand H-M. but I can do unification!
2023-10-11 17:16:28 +0200	<kuribas>	I don't even think you need to understand unification. Type variables are just variables, but at type level.
2023-10-11 17:16:38 +0200	<kuribas>	unification is only used to infer them automatically.
2023-10-11 17:17:08 +0200	<haskellbridge>	<Inst> m1 (m2 b) -> (m2 b -> m1 b) -> m1 b ?
2023-10-11 17:17:12 +0200	<EvanR>	id is the identity function, and it works at all argument/result types
2023-10-11 17:17:27 +0200	<haskellbridge>	<Inst> actually, i'm checking whether id is kind polymorphic in its type variables
2023-10-11 17:17:43 +0200	<haskellbridge>	<Inst> :t won't give me whether or not it's forall (a::k). a -> a
2023-10-11 17:17:53 +0200	YuutaW	(~YuutaW@2404:f4c0:f9c3:502::100:17b7)
2023-10-11 17:18:16 +0200	<dolio>	Well, you could say, "you need to figure out how to instantiate variables to make the types match." That is just a description of what it means to unify two types.
2023-10-11 17:18:29 +0200	<haskellbridge>	<Inst> @c_wraith is this correct?
2023-10-11 17:18:30 +0200	<haskellbridge>	<Inst> m1 (m2 b) -> (m2 b -> m1 b) -> m1 b ?
2023-10-11 17:18:37 +0200	<[exa]>	hm guys what's the easiest way now to run Haskell as javascript in a web app? say `interact :: Textarea -> Textarea` or so :D
2023-10-11 17:18:48 +0200	<kuribas>	haskellbridge: no, id takes a value, which always must have kind Type (aka *)
2023-10-11 17:18:49 +0200	<[exa]>	no need to manipulate DOM, just string to string
2023-10-11 17:18:53 +0200	<c_wraith>	Inst: where did two different m types come from?
2023-10-11 17:19:31 +0200	Simikando	(~Simikando@adsl-dyn230.91-127-81.t-com.sk) (Ping timeout: 264 seconds)
2023-10-11 17:19:52 +0200	<haskellbridge>	<Inst> "Then the type of (>>=) is restricted to m (m b) -> (m b -> m b) -> m b"
2023-10-11 17:19:59 +0200	<haskellbridge>	<Inst> so distinguishing them as m1 and m2
2023-10-11 17:20:20 +0200	<c_wraith>	Inst: but they're required to be the same. distinguishing them doesn't work
2023-10-11 17:20:24 +0200	fendor	(~fendor@2a02:8388:1640:be00:aab:1226:f274:5021)
2023-10-11 17:20:57 +0200	<EvanR>	code with one >>= introduces only one monad
2023-10-11 17:21:10 +0200	<c_wraith>	Inst: the only uses of m came from the type of (>>=), and all three uses of m are the same in it
2023-10-11 17:21:40 +0200	<haskellbridge>	<Inst> no, i mean, the inner m is treated as a separate m, for purposes of matching the m a -> (a -> m b) -> m b type signature
2023-10-11 17:21:59 +0200	<haskellbridge>	<Inst> i guess it's just that i don't understand unification
2023-10-11 17:22:10 +0200	<EvanR>	in HM everything can start out as different type variables but they will later get unified
2023-10-11 17:22:16 +0200	<haskellbridge>	<Inst> also, implicitly, you could also have implicit join via an (m a -> m b) function, no?
2023-10-11 17:22:25 +0200	<EvanR>	like solving a system of equations
2023-10-11 17:22:30 +0200	<EvanR>	and m1 = m2 comes out
2023-10-11 17:22:48 +0200	<kuribas>	haskellbridge: (>>=) :: forall a b. m a -> (a -> m b) -> m b You can assign anything to `a`, for example `m b`, which gives forall b. m (m b) -> (m b -> m b) -> m b
2023-10-11 17:22:52 +0200	<haskellbridge>	<Inst> Thanks EvanR for the response :)
2023-10-11 17:23:24 +0200	<ncf>	what's an implicit join?
2023-10-11 17:23:48 +0200	<haskellbridge>	<Inst> foo :: (Monad m) => m a -> m b
2023-10-11 17:24:12 +0200	<EvanR>	Inst that is where explicit foralls come in handy, so you don't get confused by quantified variables and singular unknowns
2023-10-11 17:24:26 +0200	<EvanR>	so that you don't confuse the two
2023-10-11 17:24:34 +0200	<c_wraith>	that's... not a join. the idea of join is to collapse nested type constructors into a single application
2023-10-11 17:24:37 +0200	<haskellbridge>	<Inst> then ((u :: m (m a)) >>= foo) :: m b
2023-10-11 17:24:53 +0200	<haskellbridge>	<Inst> i mean that's implicit, if foo is m a -> m b
2023-10-11 17:24:55 +0200	<haskellbridge>	<Inst> then you bind into it
2023-10-11 17:25:24 +0200	<haskellbridge>	<Inst> not sure if Haskell's type system would respect this
2023-10-11 17:25:32 +0200	<EvanR>	if >>= is defined in terms of join may that's implicit join
2023-10-11 17:25:40 +0200	<EvanR>	(but it's not)
2023-10-11 17:26:25 +0200	<haskellbridge>	<Inst> i guess i'll play around with some Maybe a -> Maybe b functions to see what happens
2023-10-11 17:26:30 +0200	<c_wraith>	ah, I think I see what you're going for. my starting analysis there wasn't a universal observation. it was for specifically the case of (>>= id)
2023-10-11 17:26:50 +0200	<c_wraith>	when you unify the types of id and the second argument of (>>=)
2023-10-11 17:27:42 +0200	lena64t	(~lena64t@gateway/tor-sasl/hck) (Quit: WeeChat 4.0.0-dev)
2023-10-11 17:27:50 +0200	<haskellbridge>	<Inst> http://localhost:20662/_matrix/media/v1/download/matrix.org/GPPAVIEZjhBCAGewKMAzqono
2023-10-11 17:28:00 +0200	<EvanR>	(forall a b .) Maybe a -> Maybe b functions won't get very far. They have to return Nothing
2023-10-11 17:28:15 +0200	cfricke	(~cfricke@user/cfricke) (Quit: WeeChat 4.0.4)
2023-10-11 17:29:15 +0200	<c_wraith>	um. wow, that link is useless. geekosaur, did the bridge convert it to localhost, or was that on Inst's matrix client?
2023-10-11 17:29:21 +0200	<ncf>	someone forgot to configure their matrix instance's base url
2023-10-11 17:29:51 +0200	<geekosaur>	the bridge isn';t accessible from outside so I can't expose the links created for images/media/etc. properly
2023-10-11 17:30:02 +0200	<geekosaur>	so it just uses localhost
2023-10-11 17:30:37 +0200	<geekosaur>	and Inst uses images instead of pastebins etc. so there's little to be done
2023-10-11 17:30:47 +0200	diamond	(~user@89.223.35.3) (Ping timeout: 255 seconds)
2023-10-11 17:31:03 +0200	<EvanR>	Inst, maybe post your content to twitter first and link that
2023-10-11 17:31:19 +0200	<haskellbridge>	<Inst> https://media.discordapp.net/attachments/968989726633779215/1161687327819710514/53db238e-f34c-49ec…
2023-10-11 17:31:52 +0200	<haskellbridge>	<Inst> I've boycotted twitter for a long time, would like to be able to boycott Discord eventually, but you have to be hooked into mainstream social media somehow
2023-10-11 17:32:04 +0200	<geekosaur>	(I can't make a tunnel through the building's firewall)
2023-10-11 17:32:32 +0200	<haskellbridge>	<Inst> Thanks for the answers, though. :)
2023-10-11 17:32:36 +0200	<EvanR>	Maybe a -> Maybe a has a few more options than Maybe a -> Maybe b
2023-10-11 17:33:14 +0200	<c_wraith>	it has one more option, if you're restricting yourself to total functions
2023-10-11 17:33:50 +0200	<c_wraith>	well. one more denotation. I suppose you could insert CPU-wasting code that wouldn't change the return value.
2023-10-11 17:34:49 +0200	<EvanR>	I'm embarrassed you even suggested such a thing. Extensional equality of course
2023-10-11 17:35:27 +0200	remexre	(~remexre@user/remexre) (Ping timeout: 240 seconds)
2023-10-11 17:35:53 +0200	<dolio>	Not into game semantics?
2023-10-11 17:43:35 +0200	<EvanR>	reads wikipedia real fast interesting
2023-10-11 17:44:08 +0200	<dolio>	Games are a relatively easy to understand intensional model of type theory.
2023-10-11 17:44:38 +0200	<c_wraith>	Conway's games?
2023-10-11 17:45:07 +0200	<dolio>	There's a difference between the `Maybe a -> Maybe b` game that just yields Nothing and the one that first challenges the opponent to provide their Maybe before yielding Nothing.
2023-10-11 17:45:28 +0200	<c_wraith>	nope. Conway's games are entirely different! glad to have that cleared up!
2023-10-11 17:45:41 +0200	<haskellbridge>	<Inst> Ah, since this isn't guaranteed to be a specialized id. It can just turn everything into Nothing.
2023-10-11 17:46:26 +0200	<danse-nr3>	[exa], wasm backend, javascript backend, purescript? There are other more exotic options
2023-10-11 17:46:59 +0200	_ht	(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-10-11 17:47:21 +0200	<geekosaur>	I think ghcjs is still the preferred ghc-based way, ghcjs is still a tech preview
2023-10-11 17:47:33 +0200	<geekosaur>	er. js backend is still a tech preview
2023-10-11 17:47:47 +0200	<geekosaur>	they're working on it but it'll take time
2023-10-11 17:47:56 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection)
2023-10-11 17:48:11 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34)
2023-10-11 17:48:18 +0200	<[exa]>	danse-nr3: is there some kind of howto? "I have this interact-only `main`, what to do now :D"
2023-10-11 17:48:49 +0200	<danse-nr3>	there is a wiki page about the "javascript problem" ... not sure how up to date
2023-10-11 17:49:40 +0200	<danse-nr3>	anyways it sounds like you want to write something relatively self-contained to be called from the javascript side. I think purescript was designed with this usecase in mind
2023-10-11 17:50:13 +0200	<[exa]>	hm does purescript have parsec
2023-10-11 17:50:39 +0200	<danse-nr3>	nope, it has a different ecosystem
2023-10-11 17:50:46 +0200	<EvanR>	the javascript problem. Specifically, it exists and there's nothing anyone can do about that
2023-10-11 17:50:53 +0200	<[exa]>	ah good it looks like there are parsecs for purescript
2023-10-11 17:51:00 +0200	<[exa]>	well I'll try purescript and see, thanks!
2023-10-11 17:51:28 +0200	<danse-nr3>	https://wiki.haskell.org/The_JavaScript_Problem
2023-10-11 17:51:46 +0200	notzmv	(~zmv@user/notzmv)
2023-10-11 17:51:56 +0200	<danse-nr3>	yeah i think purescript is one of the most practical approaches
2023-10-11 17:53:11 +0200	machinedgod	(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds)
2023-10-11 17:56:21 +0200	sm	(~sm@plaintextaccounting/sm) (Quit: sm)
2023-10-11 17:57:06 +0200	<EvanR>	quoting that page, we might not have time to teach people a new language, but people seem to have no problem inventing new languages at a rate that is borderline outlandish
2023-10-11 17:57:30 +0200	azimut	(~azimut@gateway/tor-sasl/azimut)
2023-10-11 17:57:47 +0200	<[exa]>	but wait purescript is eager??
2023-10-11 17:58:15 +0200	<yushyin>	yup
2023-10-11 18:00:03 +0200	<EvanR>	https://blog.drewolson.org/laziness-in-purescript
2023-10-11 18:01:27 +0200	<haskellbridge>	<Inst> wondering if it's possible to algorithmically generate all possible programming languages
2023-10-11 18:01:45 +0200	justsomeguy	(~justsomeg@user/justsomeguy) (Ping timeout: 258 seconds)
2023-10-11 18:02:02 +0200	<EvanR>	is that like generating a list of all real numbers
2023-10-11 18:02:09 +0200	sabino	(~sabino@user/sabino)
2023-10-11 18:02:10 +0200	<haskellbridge>	<Inst> feels like it
2023-10-11 18:02:13 +0200	<EvanR>	then no
2023-10-11 18:02:29 +0200	<haskellbridge>	<Inst> keywords are finite and countable
2023-10-11 18:02:36 +0200	<EvanR>	then yes
2023-10-11 18:02:37 +0200	<haskellbridge>	<Inst> number of keywords are also finite and countable
2023-10-11 18:03:19 +0200	<haskellbridge>	<Inst> number of possible design concepts probably aren't, though :(
2023-10-11 18:03:46 +0200	<EvanR>	[exa], on try.purescript.org I placed a division by zero in a tuple, then extracted the other component for one of the HTML elements output, and it didn't crash...
2023-10-11 18:04:00 +0200	shryke	(~shryke@2a00:4b00:13c:cc:b27b:25ff:fe18:efd) (Quit: WeeChat 4.0.5)
2023-10-11 18:04:14 +0200	_d0t	(~{-d0t-}@user/-d0t-/x-7915216) (Remote host closed the connection)
2023-10-11 18:04:33 +0200	_d0t	(~{-d0t-}@user/-d0t-/x-7915216)
2023-10-11 18:04:34 +0200	<EvanR>	maybe division by zero just isn't an error
2023-10-11 18:04:58 +0200	<[exa]>	division by zero in js is afaik Infinity
2023-10-11 18:05:18 +0200	<EvanR>	it's zero in purescript xD
2023-10-11 18:05:28 +0200	<EvanR>	so I learned nothing about the laziness
2023-10-11 18:05:29 +0200	<danse-nr3>	purescript is definitely strict
2023-10-11 18:05:41 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection)
2023-10-11 18:06:10 +0200	<haskellbridge>	<Inst> Elm, giggle
2023-10-11 18:06:33 +0200	<haskellbridge>	<Inst> _ / 0 = 0 in Elm
2023-10-11 18:06:54 +0200	econo_	(uid147250@id-147250.tinside.irccloud.com)
2023-10-11 18:06:56 +0200	Simikando	(~Simikando@adsl-dyn230.91-127-81.t-com.sk)
2023-10-11 18:07:27 +0200	<EvanR>	it's not an unreasonable definition if you want your page to load when the author is bad at math
2023-10-11 18:08:04 +0200	exarkun	(~exarkun@user/exarkun) (Excess Flood)
2023-10-11 18:08:36 +0200	<EvanR>	so to observe strictness we need an infinite loop probably...
2023-10-11 18:08:58 +0200	exarkun	(~exarkun@user/exarkun)
2023-10-11 18:09:30 +0200	<haskellbridge>	<Inst> Not sure if they copied that from Elm, Elm had a no exceptions promise, and they had to define _ / 0 as 0 to avoid exceptions
2023-10-11 18:09:32 +0200	<haskellbridge>	<Inst> it's an interesting problem
2023-10-11 18:09:59 +0200	<EvanR>	sure, did they also stop infinite loops
2023-10-11 18:11:43 +0200	danse-nr3	(~francesco@151.37.182.55) (Ping timeout: 264 seconds)
2023-10-11 18:11:59 +0200	fweht	(uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2023-10-11 18:12:00 +0200	<haskellbridge>	<Inst> i mean, that, if you _ / 0, you can easily do Knight Capital Mark 2: https://www.henricodolfing.com/2019/06/project-failure-case-study-knight-capital.html
2023-10-11 18:12:01 +0200	<geekosaur>	those don't throw exceptions
2023-10-11 18:13:03 +0200	<haskellbridge>	<Inst> i mean, that, if you div _ 0, you can easily do Knight Capital Mark 2: https://www.henricodolfing.com/2019/06/project-failure-case-study-knight-capital.html
2023-10-11 18:13:10 +0200	<EvanR>	I managed to put in an infinite loop and observe the strictness
2023-10-11 18:13:16 +0200	<EvanR>	no exceptions but nothing good either
2023-10-11 18:13:28 +0200	<[exa]>	I'll do with Elm
2023-10-11 18:13:40 +0200	<haskellbridge>	<Inst> how can you observe the strictness if the strictness is infinite?
2023-10-11 18:13:51 +0200	<geekosaur>	Injst, please don't do edits in here (see the Matrix-side topic)
2023-10-11 18:14:01 +0200	<geekosaur>	*Inst
2023-10-11 18:14:02 +0200	<[exa]>	infinite things are noticeably easy to observe due to size
2023-10-11 18:14:10 +0200	<haskellbridge>	<Inst> yeah, undersstood
2023-10-11 18:14:24 +0200	<haskellbridge>	<Inst> it was _ / 0, edited to div _ 0 defined as 0
2023-10-11 18:15:02 +0200	remexre	(~remexre@user/remexre)
2023-10-11 18:17:05 +0200	<geekosaur>	yes, and the bridge repeated the whole message because IRC doesn't support edits
2023-10-11 18:17:42 +0200	<geekosaur>	this is an IRC channel to which I have provided Matrix access, with some constraints. if those constraints are violated I can and will shut down the bridge
2023-10-11 18:18:29 +0200	danse-nr3	(~francesco@151.37.182.55)
2023-10-11 18:18:45 +0200	Guest22	(~Guest22@136.25.94.94)
2023-10-11 18:18:48 +0200	<haskellbridge>	<Inst> I see, understood, sorry, it's become habitual. And yeah, I usually use the IRC side, but trying to cut down on wasteful social media use.
2023-10-11 18:18:54 +0200	Guest22	(~Guest22@136.25.94.94) (Client Quit)
2023-10-11 18:18:56 +0200	ghoulguy	(g@libera/staff/glguy) (Quit: Quit)
2023-10-11 18:18:56 +0200	g	(g@libera/staff/glguy) (Remote host closed the connection)
2023-10-11 18:19:16 +0200	EitanCh	(~EitanCh@136.25.94.94)
2023-10-11 18:19:48 +0200	g	(g@libera/staff/glguy)
2023-10-11 18:20:18 +0200	justsomeguy	(~justsomeg@user/justsomeguy)
2023-10-11 18:20:48 +0200	glguy	(g@libera/staff/glguy)
2023-10-11 18:23:40 +0200	<EitanCh>	Hello, I'm trying to define an analog for the `many` Alternative combinator for Profunctors but when I try to use it it infinite loops on me. The definition involves mutual recursion. Am I missing something obvious that causes it to loop forever? Here's the code:
2023-10-11 18:23:41 +0200	<EitanCh>	several
2023-10-11 18:23:41 +0200	<EitanCh>	:: (Cons s s a a, Cons t t b b, Monoid t)
2023-10-11 18:23:42 +0200	<EitanCh>	=> p a b -> p s t
2023-10-11 18:23:42 +0200	<EitanCh>	several p = several_p where
2023-10-11 18:23:43 +0200	<EitanCh>	several_p = withIso _Stream $ \f g ->
2023-10-11 18:23:43 +0200	<EitanCh>	dimap f g (pure () >+< several1_p)
2023-10-11 18:23:43 +0200	EitanCh	(~EitanCh@136.25.94.94) (Killed (ozone (No Spam)))
2023-10-11 18:24:44 +0200	DemonDerg	(A_D@libera/staff/dragon)
2023-10-11 18:26:22 +0200	<geekosaur>	they are, but oh well
2023-10-11 18:27:13 +0200	<EvanR>	so the network is on spam alert high
2023-10-11 18:27:22 +0200	<EvanR>	spam alert elevateed
2023-10-11 18:27:42 +0200	<geekosaur>	well, yes. have you not noticed all the "just paste it" spam of late?
2023-10-11 18:27:47 +0200	<EvanR>	yes
2023-10-11 18:27:53 +0200	<geekosaur>	and we got spammed by supernets the other day too
2023-10-11 18:28:05 +0200	<DemonDerg>	was that a misban?
2023-10-11 18:28:19 +0200	<geekosaur>	yeh, just someone pasting a question into the channel
2023-10-11 18:28:24 +0200	<geekosaur>	which ozone didn't like
2023-10-11 18:28:41 +0200	<DemonDerg>	what was the nick?
2023-10-11 18:28:44 +0200	<geekosaur>	(we don't either, but first timers don't know that)
2023-10-11 18:28:47 +0200	<geekosaur>	EitanCh
2023-10-11 18:29:50 +0200	<DemonDerg>	removed
2023-10-11 18:29:56 +0200	<geekosaur>	thank you
2023-10-11 18:30:27 +0200	<ncf>	dolio: do you have a recommended resource for game semantics and type theory?
2023-10-11 18:31:14 +0200	danse-nr3	failing to "quickly reach out to them"
2023-10-11 18:31:34 +0200	<ncf>	i guess the nlab has two
2023-10-11 18:31:51 +0200	<geekosaur>	not sure they'd be trying again quickly after being klined
2023-10-11 18:32:01 +0200	<dolio>	Not really. This explains a little, though: https://www.youtube.com/watch?v=uY5LubwJ1Xo
2023-10-11 18:32:12 +0200	<DemonDerg>	unfortunately yeah
2023-10-11 18:33:05 +0200	<danse-nr3>	maybe we can leave a message through the bot?
2023-10-11 18:33:20 +0200	<ncf>	ah, that's the author of one of the papers i found (now "withdrawn" from arxiv, but you can still read it, wtf?)
2023-10-11 18:34:08 +0200	danse-nr3	(~francesco@151.37.182.55) (Remote host closed the connection)
2023-10-11 18:34:33 +0200	danse-nr3	(~francesco@151.37.182.55)
2023-10-11 18:34:43 +0200	Simikando	(~Simikando@adsl-dyn230.91-127-81.t-com.sk) (Ping timeout: 258 seconds)
2023-10-11 18:35:12 +0200	<DemonDerg>	also while Im looking about, you all seen any extra supernets spam or so today?
2023-10-11 18:36:54 +0200	chele	(~chele@user/chele) (Remote host closed the connection)
2023-10-11 18:38:06 +0200	hugo-	(znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds)
2023-10-11 18:38:12 +0200	<EvanR>	types are games and terms are strategies
2023-10-11 18:38:33 +0200	Square3	(~Square4@user/square)
2023-10-11 18:38:50 +0200	<dolio>	Yeah, I guess I should have said "strategy" above.
2023-10-11 18:39:46 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34)
2023-10-11 18:39:51 +0200	<dolio>	For the two distinct values of Maybe a -> Maybe b.
2023-10-11 18:42:16 +0200	<danse-nr3>	hum so i guess a term is what i used to call a type's "value"
2023-10-11 18:42:45 +0200	<dolio>	Well, terms are syntactic things.
2023-10-11 18:42:51 +0200	<dolio>	Terms denote strategies.
2023-10-11 18:44:04 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed)
2023-10-11 18:46:22 +0200	<danse-nr3>	i see, thanks
2023-10-11 18:47:25 +0200	<geekosaur>	DemonDerg, not today. had some jp.it last night but I didn't wake up to any this morning for a change
2023-10-11 18:48:01 +0200	<geekosaur>	btw there used to be some protocol for chanops to follow if ozone incorrectly klined someone, does that still exist?
2023-10-11 18:48:07 +0200	<DemonDerg>	it does
2023-10-11 18:48:17 +0200	<DemonDerg>	be opped and message it unkline $nick, IIRC
2023-10-11 18:48:40 +0200	<geekosaur>	thank you
2023-10-11 18:48:46 +0200	<DemonDerg>	https://libera.chat/guides/bots#ozone
2023-10-11 18:49:09 +0200	<DemonDerg>	should also op any bots you have in here
2023-10-11 18:49:12 +0200	<DemonDerg>	sorry, voice
2023-10-11 18:49:13 +0200	<DemonDerg>	not op
2023-10-11 18:49:18 +0200	<DemonDerg>	apologies, long day
2023-10-11 18:50:39 +0200	hugo	(znc@verdigris.lysator.liu.se)
2023-10-11 18:51:04 +0200	<geekosaur>	that one's not up to me, I'll mention it in the ops channel
2023-10-11 18:51:15 +0200	hiyori	(~hiyori@user/hiyori) (Quit: Client closed)
2023-10-11 18:52:01 +0200	stites	(~stites@130.44.147.204) (Ping timeout: 252 seconds)
2023-10-11 18:52:33 +0200	stites	(~stites@2607:fb91:dc8:e0e2:5656:70eb:8498:35ff)
2023-10-11 18:54:31 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net)
2023-10-11 19:03:40 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection)
2023-10-11 19:04:42 +0200	AlexNoo_	(~AlexNoo@94.233.241.173)
2023-10-11 19:05:06 +0200	euleritian	(~euleritia@46.114.206.159) (Read error: Connection reset by peer)
2023-10-11 19:05:23 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-10-11 19:06:47 +0200	justsomeguy	(~justsomeg@user/justsomeguy) (Ping timeout: 260 seconds)
2023-10-11 19:07:32 +0200	AlexZenon	(~alzenon@178.34.163.10) (Ping timeout: 255 seconds)
2023-10-11 19:07:49 +0200	Alex_test	(~al_test@178.34.163.10) (Ping timeout: 255 seconds)
2023-10-11 19:07:59 +0200	AlexNoo	(~AlexNoo@178.34.163.10) (Ping timeout: 245 seconds)
2023-10-11 19:08:15 +0200	AlexNoo_	AlexNoo
2023-10-11 19:08:20 +0200	emergence	(emergence@2607:5300:60:5910:dcad:beff:feef:5bc)
2023-10-11 19:09:50 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed)
2023-10-11 19:09:57 +0200	asivitz	(uid178348@id-178348.tinside.irccloud.com)
2023-10-11 19:10:41 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net)
2023-10-11 19:11:12 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34)
2023-10-11 19:12:28 +0200	ChanServ	+o monochrom
2023-10-11 19:12:31 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds)
2023-10-11 19:12:53 +0200	ChanServ	+v lambdabot
2023-10-11 19:13:06 +0200	ChanServ	+v yahb2
2023-10-11 19:13:07 +0200	Alex_test	(~al_test@94.233.241.173)
2023-10-11 19:13:22 +0200	ChanServ	+v haskellbridge
2023-10-11 19:13:30 +0200	monochrom	-o monochrom
2023-10-11 19:13:47 +0200	AlexZenon	(~alzenon@94.233.241.173)
2023-10-11 19:15:21 +0200	euleritian	(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-10-11 19:15:31 +0200	lg188	(~lg188@82.18.98.230) (Quit: Bye.)
2023-10-11 19:16:16 +0200	kuribas	(~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1))
2023-10-11 19:16:42 +0200	danse-nr3	(~francesco@151.37.182.55) (Ping timeout: 260 seconds)
2023-10-11 19:21:10 +0200	lg188	(~lg188@82.18.98.230)
2023-10-11 19:25:38 +0200	lg188	(~lg188@82.18.98.230) (Read error: Connection reset by peer)
2023-10-11 19:25:46 +0200	justsomeguy	(~justsomeg@user/justsomeguy)
2023-10-11 19:27:49 +0200	lg188	(~lg188@82.18.98.230)
2023-10-11 19:30:08 +0200	lg188	(~lg188@82.18.98.230) (Read error: Connection reset by peer)
2023-10-11 19:32:59 +0200	<EvanR>	Data.ByteString docs state that it is suitable for high performance, then it says it's implemented as a ForeignPtr. Does this mean ByteStrings have FFI overhead or is FFI not involved
2023-10-11 19:33:13 +0200	stites	(~stites@2607:fb91:dc8:e0e2:5656:70eb:8498:35ff) (Read error: Connection reset by peer)
2023-10-11 19:33:39 +0200	stites	(~stites@130.44.147.204)
2023-10-11 19:34:40 +0200	hugo	(znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds)
2023-10-11 19:34:49 +0200	simendsjo	(~user@84.211.91.241)
2023-10-11 19:36:52 +0200	<EvanR>	also when looking at how BS.takeWhile is implemented I noticed accursedUnutterablePerformIO, which I thought was considered unprofessional and renamed xD
2023-10-11 19:37:42 +0200	<EvanR>	which also answers the question because there's the FFI
2023-10-11 19:38:46 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:8c8d:37ea:f5b2:d34) (Remote host closed the connection)
2023-10-11 19:39:41 +0200	Simikando	(~Simikando@adsl-dyn230.91-127-81.t-com.sk)
2023-10-11 19:41:12 +0200	<geekosaur>	ByteString is what invented it… and discovered why it's a bad idea
2023-10-11 19:41:20 +0200	<geekosaur>	but they still use it for performance
2023-10-11 19:41:37 +0200	<geekosaur>	and yes, it FFIs again for performance
2023-10-11 19:41:57 +0200	ski	(~ski@88.131.7.247)
2023-10-11 19:42:23 +0200	<geekosaur>	I think they cheat there and use unsafe calls? which avoids the overhead but they have to be very careful with it
2023-10-11 19:42:55 +0200	<geekosaur>	then again they're looking for performance so they're avoiding anything that would block and thereby be unsafe from a FFI standpoint
2023-10-11 19:48:18 +0200	hugo	(znc@verdigris.lysator.liu.se)
2023-10-11 19:48:34 +0200	wootehfoot	(~wootehfoo@user/wootehfoot)
2023-10-11 19:51:14 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:24c5:ca27:9366:8391)
2023-10-11 19:53:50 +0200	Simikando	(~Simikando@adsl-dyn230.91-127-81.t-com.sk) (Remote host closed the connection)
2023-10-11 19:55:58 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:24c5:ca27:9366:8391) (Ping timeout: 272 seconds)
2023-10-11 19:56:55 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed)
2023-10-11 20:02:44 +0200	<EvanR>	FFI has more performance than what, using a primitive array?
2023-10-11 20:04:46 +0200	<[exa]>	ok so today I learned that Elm ain't very good for functional programming. :D
2023-10-11 20:05:10 +0200	<EvanR>	yeeeeeaahh....
2023-10-11 20:05:33 +0200	<[exa]>	"error: too much recursion" when trying elm/parser to do JSON, like, where are we
2023-10-11 20:05:49 +0200	<[exa]>	there's never enough recursion!
2023-10-11 20:06:22 +0200	<EvanR>	what a disgrace
2023-10-11 20:07:48 +0200	<[exa]>	somehow I tend to understand "compile to javascript" a bit more elaborately as "direct source-to-source homomorphism to javascript"
2023-10-11 20:07:58 +0200	<[exa]>	*than
2023-10-11 20:08:13 +0200	<[exa]>	ok nvm probably time to write my own language for this. :D
2023-10-11 20:13:14 +0200	<EvanR>	what made you go for Elm over purescript
2023-10-11 20:13:31 +0200	Square3	(~Square4@user/square) (Ping timeout: 264 seconds)
2023-10-11 20:15:22 +0200	rgw	(~R@2605:a601:a0df:5600:786b:f462:3e9c:5be6)
2023-10-11 20:15:26 +0200	<[exa]>	I somehow thought it's not eager.
2023-10-11 20:15:40 +0200	<[exa]>	;_;
2023-10-11 20:16:12 +0200	misterfish	(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 240 seconds)
2023-10-11 20:17:33 +0200	<mauke>	no warnings qw(recursion); # if this were perl ...
2023-10-11 20:17:43 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net)
2023-10-11 20:18:15 +0200	<monochrom>	haha
2023-10-11 20:18:55 +0200	<monochrom>	But yeah I'm disappointed. It is no longer rocket science to write a translator that does CPS and trampolining for you.
2023-10-11 20:19:03 +0200	tromp	(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-10-11 20:19:17 +0200	wootehfoot	(~wootehfoo@user/wootehfoot) (Quit: Leaving)
2023-10-11 20:20:24 +0200	<monochrom>	Then again there is a conflict between "translate to js but preserve semantics" and "translate to js but make it idiomatic js".
2023-10-11 20:20:40 +0200	<monochrom>	s/semantics/source-language semantics/ to be precise
2023-10-11 20:20:56 +0200	<mauke>	do you know a language that has explicit tail calls? i.e. where the programmer can say "jump to this function over there, no return"
2023-10-11 20:21:12 +0200	<monochrom>	Does iptables count? :)
2023-10-11 20:21:22 +0200	<mauke>	I was about to say, outside of asm
2023-10-11 20:21:45 +0200	<mauke>	iptables looks to me like a similar idea, just chains of instructions
2023-10-11 20:22:03 +0200	<monochrom>	I think Scheme counts, but perhaps indirectly.
2023-10-11 20:22:06 +0200	<geekosaur>	I feel like I've seen a language that has `goto <some function>` but I'm not recalling it
2023-10-11 20:22:12 +0200	<mauke>	that's perl
2023-10-11 20:22:18 +0200	<geekosaur>	oh, right
2023-10-11 20:22:45 +0200	<mauke>	I'm wondering if perl invented it or whether there's precedent elsewhere
2023-10-11 20:22:46 +0200	<geekosaur>	been too long
2023-10-11 20:22:49 +0200	<monochrom>	Scheme's definition makes it completely predictable which calls become tail calls and the others don't.
2023-10-11 20:22:55 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:acbe:e88a:3adf:3c7b)
2023-10-11 20:23:21 +0200	<mauke>	scheme is more on the side of guaranteed optimizations, I'd say
2023-10-11 20:23:27 +0200	<mauke>	along the lines of ApplicativeDo
2023-10-11 20:23:35 +0200	<monochrom>	Yeah that's true.
2023-10-11 20:24:41 +0200	<EvanR>	llvm has explicit tail calls, C--?
2023-10-11 20:25:00 +0200	<[exa]>	monochrom: "idiomatic js" and then people claim react+jsx outputs as good :D
2023-10-11 20:26:11 +0200	<mauke>	EvanR: ok, but those aren't meant to be written by humans
2023-10-11 20:26:26 +0200	<mauke>	I was looking for more high-level things :-)
2023-10-11 20:26:34 +0200	<monochrom>	llvm is too close to asm
2023-10-11 20:26:58 +0200	<[exa]>	mauke: does 'yield' count?
2023-10-11 20:27:12 +0200	<monochrom>	In fact, too close to ideal asm, too. You actually write single-assignments and phi nodes!
2023-10-11 20:27:46 +0200	<mauke>	[exa]: in a way, yield is the exact opposite
2023-10-11 20:27:48 +0200	<[exa]>	mauke: also maybe you were searching for........high level assembler, the gem of IBM!
2023-10-11 20:28:19 +0200	<mauke>	yield returns up instead of calling deeper, and it can return instead of making everything after it unreachable
2023-10-11 20:28:46 +0200	<ski>	"proper tail recursion" in Scheme is not an optimization (and doesn't need to be implemented via TCO), it's a language guarantee (about asymptotic space usage of a (conforming) implementation (that it can support an unbounded number of active tail calls in bounded space))
2023-10-11 20:29:12 +0200	danza	(~francesco@151.37.182.55)
2023-10-11 20:33:32 +0200	<EvanR>	llvm, portable assembly. Unlike C
2023-10-11 20:34:38 +0200	<EvanR>	is proper tail recursion the technical name in scheme?
2023-10-11 20:34:56 +0200	<ski>	yes
2023-10-11 20:35:01 +0200	<EvanR>	nice
2023-10-11 20:35:31 +0200	<ski>	in Prolog, the term is "Last Call" as opposed to "Tail Call" (the concept was discovered independently in LP)
2023-10-11 20:37:36 +0200	<ski>	(there's also TCMC, Tail-Call Modulo Cons(tructor), where you (e.g.) first construct the cons cell of the list, then pass the address of the tail field in the cell to the (usually) recursive call, to fill in (initialize/instantiate) the rest .. the Logic/Functional programming language Mercury can do this, and OCaml also has some support)
2023-10-11 20:38:32 +0200	sord937	(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2023-10-11 20:39:22 +0200	<ski>	(i recall reading somewhere that because Erlang doesn't have TCMC, a serialization framework for it decided to serialize the elements of lists in reverse order, so that when deserializing it can reconstruct the list with a tail recursion)
2023-10-11 20:41:05 +0200	<mauke>	should've had first-class lvalues :-D
2023-10-11 20:41:09 +0200	<EvanR>	to be clear, are we talking about construction an entire actual list in memory
2023-10-11 20:41:18 +0200	<ski>	yes
2023-10-11 20:41:23 +0200	<EvanR>	crazy
2023-10-11 20:41:35 +0200	<mauke>	the depravity
2023-10-11 20:42:55 +0200	<EvanR>	many languages, purescript included, seem to have a facility for doing lazy list processing in an otherwise non-lazy language. But I don't often see people in those languages enthusiastic about it
2023-10-11 20:43:09 +0200	<monochrom>	Well this being OCaml etc., "map f (x:xs) = f x : map f xs" is a bit sad until TCMC.
2023-10-11 20:43:09 +0200	<EvanR>	I wonder if it's just cargo culting xD
2023-10-11 20:44:10 +0200	<monochrom>	Well yeah most people aren't thrilled about lazy evaluation.
2023-10-11 20:45:08 +0200	<dolio>	Why use lazy evaluation when you can manually convolute your program so that things happen in the right order?
2023-10-11 20:45:29 +0200	<monochrom>	I like lazy evaluation because I see the half-full glass that offers "map f (x:xs) = f x : map f xs is already constant-space without doing anything special"
2023-10-11 20:46:00 +0200	<monochrom>	But other people see the half-empty glass that offers "foldl (+) 0 xs is linear space"
2023-10-11 20:46:29 +0200	<mauke>	map f xs = x <- await xs; yield (f x); map f xs
2023-10-11 20:48:20 +0200	ski	(~ski@88.131.7.247) (Ping timeout: 255 seconds)
2023-10-11 20:49:06 +0200	<EvanR>	foldl not prime on list is a fully empty glass, unless you're implementing last
2023-10-11 20:49:45 +0200	<EvanR>	why isn't your map example fully full ? xD
2023-10-11 20:50:04 +0200	<EvanR>	(also, fully empty? wtf)
2023-10-11 20:50:20 +0200	<monochrom>	Because lazy evaluation is a superposition of both :)
2023-10-11 20:53:21 +0200	alphacentauri	(alphacenta@gateway/vpn/protonvpn/alphacentauri) (Quit: WeeChat 4.0.5)
2023-10-11 20:53:59 +0200	hugo	(znc@verdigris.lysator.liu.se) (Ping timeout: 246 seconds)
2023-10-11 20:54:10 +0200	<EvanR>	is that why we don't want to redefine foldl to be strict, we want to be reminded of the flaws in our ways
2023-10-11 20:54:46 +0200	alphacentauri	(alphacenta@gateway/vpn/protonvpn/alphacentauri)
2023-10-11 20:55:06 +0200	<EvanR>	better to admit it than paper over it and hide the truth
2023-10-11 20:55:43 +0200	<mauke>	@src foldl'
2023-10-11 20:55:43 +0200	<lambdabot>	foldl' f a [] = a
2023-10-11 20:55:43 +0200	<lambdabot>	foldl' f a (x:xs) = let a' = f a x in a' `seq` foldl' f a' xs
2023-10-11 20:55:48 +0200	<nullie>	isn't lazy evaluation a leaky abstraction?
2023-10-11 20:56:00 +0200	<monochrom>	No, I think we are just too polite to change historical definitions, even those that were flawed.
2023-10-11 20:56:01 +0200	<mauke>	is foldl' guaranteed to work any better?
2023-10-11 20:56:24 +0200	<monochrom>	Just look at how people are too polite to actually delete things on the haskell wiki.
2023-10-11 20:56:52 +0200	<monochrom>	Yes.
2023-10-11 20:57:28 +0200	<EvanR>	foldl' arguably works worse when defining last
2023-10-11 20:57:35 +0200	<mauke>	why?
2023-10-11 20:57:35 +0200	<EvanR>	which no one ever does
2023-10-11 20:58:02 +0200	<dolio>	mauke: Because it blows up if any non-last elements are undefined.
2023-10-11 20:58:21 +0200	<dolio>	If I recall.
2023-10-11 20:58:52 +0200	<mauke>	no, why is foldl' guaranteed to work better for summing?
2023-10-11 20:59:07 +0200	lg188	(~lg188@82.18.98.230)
2023-10-11 20:59:41 +0200	<monochrom>	You have: let a'=a+x in seq a' (foldl' (+) a' xs)
2023-10-11 21:00:20 +0200	<mauke>	seq a b = seq b (seq a b)
2023-10-11 21:00:57 +0200	<monochrom>	Well OK, next we have to choose one of two paths.
2023-10-11 21:01:00 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-10-11 21:01:38 +0200	gehmehgeh	(~user@user/gehmehgeh) (Remote host closed the connection)
2023-10-11 21:02:01 +0200	<monochrom>	One path is: You say that the Haskell Report promises strictness only, but then a compiler adds optimizations based on strictness, so a+x is evaluated earlier.
2023-10-11 21:02:11 +0200	danza	(~francesco@151.37.182.55) (Ping timeout: 255 seconds)
2023-10-11 21:02:19 +0200	gehmehgeh	(~user@user/gehmehgeh)
2023-10-11 21:02:23 +0200	<monochrom>	The other path is: I say that seq promises evaluation order in the context of lazy evaluation.
2023-10-11 21:03:05 +0200	<monochrom>	I know, neither path is actually completely guaranteed by any signed rubber-stamped documents.
2023-10-11 21:05:11 +0200	<monochrom>	But what else is guaranteed by the Haskell Report anyway apart from syntax? :)
2023-10-11 21:05:43 +0200	nate2	(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
2023-10-11 21:05:45 +0200	<dolio>	It would take extra work to provide the right semantics without making the sum cases better, I think.
2023-10-11 21:06:26 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:acbe:e88a:3adf:3c7b) (Remote host closed the connection)
2023-10-11 21:06:41 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:acbe:e88a:3adf:3c7b)
2023-10-11 21:07:46 +0200	<monochrom>	I raise two points outside the signed rubber-stamped documents.
2023-10-11 21:08:51 +0200	<monochrom>	1. Consider why it ends up being named "seq" rather than, say, "strict". (In fact, an old textbook of Bird called it "strict". (And went on to show the confusion between strict/non-strict and eager/lazy.))
2023-10-11 21:09:23 +0200	privacy	(~privacy@user/privacy)
2023-10-11 21:10:46 +0200	<monochrom>	2. John Hughes in an interview said: His contribution was adding a way to disable laziness to solve the space problem.
2023-10-11 21:10:50 +0200	lg188	(~lg188@82.18.98.230) (Ping timeout: 255 seconds)
2023-10-11 21:11:33 +0200	<EvanR>	also language gains meaning through use, and that's how/why it's used
2023-10-11 21:11:43 +0200	<monochrom>	The intention of seq is very much eagerness, despite how the committee was too afraid to put in black on white.
2023-10-11 21:13:45 +0200	<mauke>	seq (error "a") (error "b")
2023-10-11 21:14:07 +0200	<EvanR>	> seq (error "a") (error "b")
2023-10-11 21:14:09 +0200	<lambdabot>	*Exception: a
2023-10-11 21:14:18 +0200	<mauke>	I don't think ghc guarantees "a"
2023-10-11 21:14:18 +0200	<EvanR>	cromulent
2023-10-11 21:14:43 +0200	<EvanR>	at least that test doesn't contradict the arguments made by monochrom
2023-10-11 21:14:52 +0200	<monochrom>	You are right about that. When there are two errors to choose from, GHC optimizations can end up choosing the unexpected one.
2023-10-11 21:14:54 +0200	<mauke>	true, but why does pseq exist?
2023-10-11 21:14:56 +0200	<dolio>	It's not about "afraid." Imposing an exact evaluation order is less useful.
2023-10-11 21:15:08 +0200	<EvanR>	but not I kind of see the value in rubber stamped documents "guaranteeing" something, it makes this entire discussion miraculously unnecessary
2023-10-11 21:15:20 +0200	<EvanR>	now*
2023-10-11 21:16:07 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:acbe:e88a:3adf:3c7b) (Remote host closed the connection)
2023-10-11 21:16:15 +0200	<monochrom>	But foldl' (+) 0 [1..10000] contains no errors. The same strictness analysis and optimizations will keep it constant space.
2023-10-11 21:17:08 +0200	<dolio>	You want to enable the compiler to make good decisions about the exact evaluation order given the local context it has. For sum, the compiler knows what to do as long as it isn't required to give the non-strict semantics.
2023-10-11 21:17:32 +0200	<dolio>	That you can be a pedantic dipshit and say, "technically it could do something really bad instead," is irrelevant.
2023-10-11 21:18:05 +0200	mc47	(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2023-10-11 21:21:39 +0200	<monochrom>	pseq exists because, hell, even today, GHC optimizer isn't quite aware of parallelization.
2023-10-11 21:25:29 +0200	Unicorn_Princess	(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2023-10-11 21:27:42 +0200	phma_	(~phma@host-67-44-208-58.hnremote.net)
2023-10-11 21:31:11 +0200	<monochrom>	You know what, I don't think even standard C states that "x = 0;" takes constant space or constant time. :)
2023-10-11 21:31:13 +0200	phma	(~phma@host-67-44-208-58.hnremote.net) (Ping timeout: 255 seconds)
2023-10-11 21:31:59 +0200	YuutaW	(~YuutaW@2404:f4c0:f9c3:502::100:17b7) (Read error: Connection reset by peer)
2023-10-11 21:32:07 +0200	<mauke>	I wonder if C even has time
2023-10-11 21:32:14 +0200	YuutaW	(~YuutaW@2404:f4c0:f9c3:502::100:17b7)
2023-10-11 21:44:10 +0200	<EvanR>	as you approach C time comes to a stop so no
2023-10-11 21:46:55 +0200	<monochrom>	haha
2023-10-11 21:47:05 +0200	<monochrom>	@quote monochrom einstein
2023-10-11 21:47:06 +0200	<lambdabot>	monochrom says: einstein's theory implies that haskell cannot be faster than c
2023-10-11 21:47:30 +0200	alphacentauri	(alphacenta@gateway/vpn/protonvpn/alphacentauri) (Quit: WeeChat 4.0.5)
2023-10-11 21:48:33 +0200	eggplantade	(~Eggplanta@2600:1700:38c5:d800:5d3c:fd45:6dba:f35a)
2023-10-11 21:49:05 +0200	iteratee	(~kyle@162.218.222.207) (Ping timeout: 255 seconds)
2023-10-11 21:49:30 +0200	iteratee	(~kyle@162.218.222.207)
2023-10-11 21:49:54 +0200	alphacentauri	(alphacenta@gateway/vpn/protonvpn/alphacentauri)
2023-10-11 21:50:47 +0200	<EvanR>	right now I'm trying to write a haskell version of a tool script in the zig codebase. Right now with optimizations I'm at .043ms while the zig version is .005ms
2023-10-11 21:52:05 +0200	<EvanR>	11% zig
2023-10-11 21:53:00 +0200	<mauke>	move `zig`
2023-10-11 21:54:15 +0200	<EvanR>	hopefully I can pick up some time by going through ByteString instead of String I/O
2023-10-11 21:55:51 +0200	<mauke>	what does the tool do?
2023-10-11 21:56:17 +0200	iteratee	(~kyle@162.218.222.207) (Ping timeout: 255 seconds)
2023-10-11 21:56:29 +0200	lg188	(~lg188@82.18.98.230)
2023-10-11 21:56:33 +0200	iteratee	(~kyle@162.218.222.207)
2023-10-11 21:57:49 +0200	Tuplanolla	(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
2023-10-11 21:58:25 +0200	<EvanR>	it extracts syscall numbers from linux source code from various files and creates a zig file
2023-10-11 21:58:39 +0200	dcoutts	(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 240 seconds)
2023-10-11 21:59:36 +0200	<EvanR>	well the product just goes to stdout
2023-10-11 21:59:54 +0200	<mauke>	ah, like h2ph / syscall.ph
2023-10-11 22:03:26 +0200	hrberg	(~quassel@171.79-160-161.customer.lyse.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2023-10-11 22:05:16 +0200	hugo-	(znc@verdigris.lysator.liu.se)
2023-10-11 22:06:01 +0200	hrberg	(~quassel@171.79-160-161.customer.lyse.net)
2023-10-11 22:09:35 +0200	machinedgod	(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-10-11 22:11:48 +0200	takuan	(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-10-11 22:12:58 +0200	ft	(~ft@p3e9bc680.dip0.t-ipconnect.de)
2023-10-11 22:15:58 +0200	_ht	(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-10-11 22:28:01 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed)
2023-10-11 22:37:12 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net)
2023-10-11 22:39:23 +0200	__monty__	(~toonn@user/toonn) (Ping timeout: 255 seconds)
2023-10-11 22:39:45 +0200	__monty__	(~toonn@user/toonn)
2023-10-11 22:41:57 +0200	wroathe	(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-10-11 22:41:57 +0200	wroathe	(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-10-11 22:41:57 +0200	wroathe	(~wroathe@user/wroathe)
2023-10-11 22:47:27 +0200	wroathe	(~wroathe@user/wroathe) (Ping timeout: 240 seconds)
2023-10-11 22:53:41 +0200	jmdaemon	(~jmdaemon@user/jmdaemon)
2023-10-11 22:58:32 +0200	michalz	(~michalz@185.246.207.200) (Remote host closed the connection)
2023-10-11 23:01:13 +0200	pavonia	(~user@user/siracusa)
2023-10-11 23:05:28 +0200	phma_	phma
2023-10-11 23:06:03 +0200	myxos	(~myxos@cpe-65-28-251-121.cinci.res.rr.com)
2023-10-11 23:10:22 +0200	simendsjo	(~user@84.211.91.241) (Ping timeout: 255 seconds)
2023-10-11 23:13:05 +0200	dcoutts	(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net)
2023-10-11 23:14:49 +0200	billchenchina	(~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Quit: Leaving)
2023-10-11 23:18:23 +0200	fendor	(~fendor@2a02:8388:1640:be00:aab:1226:f274:5021) (Remote host closed the connection)
2023-10-11 23:22:20 +0200	[itchyjunk]	(~itchyjunk@user/itchyjunk/x-7353470)
2023-10-11 23:24:02 +0200	cpressey	(~cpressey@host-2-102-11-74.as13285.net) (Quit: Client closed)
2023-10-11 23:27:27 +0200	wroathe	(~wroathe@user/wroathe)
2023-10-11 23:30:04 +0200	acidjnk	(~acidjnk@p200300d6e7072f8019cae40178150491.dip0.t-ipconnect.de) (Ping timeout: 245 seconds)
2023-10-11 23:32:05 +0200	dcoutts	(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 240 seconds)
2023-10-11 23:42:05 +0200	Jackneill	(~Jackneill@20014C4E1E021C00E4226B7959631CE0.dsl.pool.telekom.hu) (Ping timeout: 240 seconds)
2023-10-11 23:42:12 +0200	Inst	(~Inst@120.244.192.250)
2023-10-11 23:42:35 +0200	<Inst>	what are the efficiency advantages of a list comprehension vs filter?
2023-10-11 23:44:01 +0200	__monty__	(~toonn@user/toonn) (Quit: leaving)
2023-10-11 23:45:18 +0200	<davean>	Inst: I mean list comprehensions are far more powerful than filter.
2023-10-11 23:45:57 +0200	<davean>	You're comparing a helicopter to a ski lift. Thy can both get you up the mountain. Whats the efficiency difference? For doing what filter can do?
2023-10-11 23:46:07 +0200	<Inst>	i guess it's more easy to extend, I'm discussing code in cabal, and I'm surprised this is being done via a list comprehension instead of a filter, but I'm called a point-free addict sometimes
2023-10-11 23:46:10 +0200	<haskellbridge>	<sm> did you mean list comprehensions vs standard function composition ? no difference I think
2023-10-11 23:46:39 +0200	<haskellbridge>	<sm> it's a readability choice
2023-10-11 23:46:55 +0200	<Inst>	[ cmd \| cmd@(Command cname' _ _ _) <- commands', cname' == cname] vs
2023-10-11 23:47:13 +0200	<Inst>	filter (\(Command cname' _ _ _) -> cname' == cname)
2023-10-11 23:47:16 +0200	<geekosaur>	@undo [ cmd \| cmd@(Command cname' _ _ _) <- commands', cname' == cname]
2023-10-11 23:47:16 +0200	<lambdabot>	concatMap (\ a -> case a of { cmd@(Command cname' _ _ _) -> if cname' == cname then [cmd] else []; _ -> []}) commands'
2023-10-11 23:47:47 +0200	<davean>	geekosaur: that is the worst undo of that ...
2023-10-11 23:47:52 +0200	<geekosaur>	yeh
2023-10-11 23:47:59 +0200	<davean>	I'd be hard pressed to write a worse version of undoing it.
2023-10-11 23:47:59 +0200	<geekosaur>	thought it used map and filter these days
2023-10-11 23:48:19 +0200	jmdaemon	(~jmdaemon@user/jmdaemon) (Ping timeout: 264 seconds)
2023-10-11 23:49:00 +0200	<Inst>	iirc list comprehensions desugar to concatmap
2023-10-11 23:49:18 +0200	<geekosaur>	they only do if MonadComprehensions is in effect, I think
2023-10-11 23:51:12 +0200	ChanServ	+o litharge
2023-10-11 23:51:13 +0200	litharge	-bo !@190.123.41.211 litharge
2023-10-11 23:52:17 +0200	<monochrom>	I think there are two points. 1. List comprehension and filter go through different pathways in GHC. 2. But end up being the same asm code.
2023-10-11 23:52:19 +0200	<geekosaur>	yeh, 0-ddump-ds shows no use of concatMap
2023-10-11 23:56:46 +0200	jmdaemon	(~jmdaemon@user/jmdaemon)
2023-10-11 23:57:19 +0200	privacy	(~privacy@user/privacy) (Quit: Leaving)