2023-03-09 00:05:41 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) |
2023-03-09 00:10:26 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
2023-03-09 00:11:55 +0100 | NiceBird | (~NiceBird@185.133.111.196) (Quit: Leaving) |
2023-03-09 00:14:38 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) (Quit: Leaving.) |
2023-03-09 00:19:23 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
2023-03-09 00:23:03 +0100 | euandreh | (~Thunderbi@189.6.18.7) |
2023-03-09 00:29:14 +0100 | zeenk | (~zeenk@2a02:2f04:a20d:f900::7fe) (Quit: Konversation terminated!) |
2023-03-09 00:33:45 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
2023-03-09 00:41:31 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 248 seconds) |
2023-03-09 00:47:54 +0100 | talismanick | (~talismani@campus-007-052.ucdavis.edu) |
2023-03-09 00:50:14 +0100 | meinside | (uid24933@id-24933.helmsley.irccloud.com) |
2023-03-09 00:53:45 +0100 | gurkenglas | (~gurkengla@dynamic-046-114-178-105.46.114.pool.telefonica.de) (Ping timeout: 255 seconds) |
2023-03-09 00:54:27 +0100 | offtherock | (~blurb@96.45.2.121) (Remote host closed the connection) |
2023-03-09 00:57:10 +0100 | stackdroid18 | (14094@de1.hashbang.sh) |
2023-03-09 00:57:36 +0100 | stackdroid18 | (14094@de1.hashbang.sh) (Client Quit) |
2023-03-09 00:57:59 +0100 | talismanick | (~talismani@campus-007-052.ucdavis.edu) (Remote host closed the connection) |
2023-03-09 01:05:21 +0100 | mauke_ | (~mauke@user/mauke) |
2023-03-09 01:05:49 +0100 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:4147:a345:6569:5bc8) |
2023-03-09 01:07:07 +0100 | mauke | (~mauke@user/mauke) (Ping timeout: 248 seconds) |
2023-03-09 01:07:07 +0100 | mauke_ | mauke |
2023-03-09 01:10:58 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
2023-03-09 01:30:06 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
2023-03-09 01:30:06 +0100 | tusko | (~yeurt@user/tusko) (Remote host closed the connection) |
2023-03-09 01:30:22 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
2023-03-09 01:30:39 +0100 | tusko | (~yeurt@user/tusko) |
2023-03-09 01:44:28 +0100 | jarkad | (~u@188.163.45.157) (Ping timeout: 252 seconds) |
2023-03-09 01:45:31 +0100 | _xor | (~xor@72.49.195.228) (Ping timeout: 246 seconds) |
2023-03-09 01:52:21 +0100 | fnurglewitz | (uid263868@id-263868.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
2023-03-09 01:54:30 +0100 | remedan | (~remedan@ip-94-112-0-18.bb.vodafone.cz) (Ping timeout: 255 seconds) |
2023-03-09 01:54:46 +0100 | kimiamania8 | (~65804703@user/kimiamania) |
2023-03-09 01:55:09 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
2023-03-09 01:55:09 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
2023-03-09 01:55:09 +0100 | wroathe | (~wroathe@user/wroathe) |
2023-03-09 01:55:51 +0100 | tdammers | (~tdammers@219-131-178-143.ftth.glasoperator.nl) (Ping timeout: 255 seconds) |
2023-03-09 01:56:01 +0100 | remedan | (~remedan@ip-94-112-0-18.bb.vodafone.cz) |
2023-03-09 01:56:16 +0100 | tdammers | (~tdammers@219-131-178-143.ftth.glasoperator.nl) |
2023-03-09 01:56:18 +0100 | kimiamania | (~65804703@user/kimiamania) (Ping timeout: 255 seconds) |
2023-03-09 01:56:18 +0100 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 255 seconds) |
2023-03-09 01:56:18 +0100 | Cheery | (~cheery@server-239-7.tentacle.cloud) (Ping timeout: 255 seconds) |
2023-03-09 01:56:19 +0100 | tessier | (~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 255 seconds) |
2023-03-09 01:56:19 +0100 | typedfern_ | (~Typedfern@60.red-83-37-32.dynamicip.rima-tde.net) (Ping timeout: 255 seconds) |
2023-03-09 01:56:21 +0100 | kimiamania8 | kimiamania |
2023-03-09 01:56:27 +0100 | Cheery | (~cheery@server-239-7.tentacle.cloud) |
2023-03-09 01:56:45 +0100 | turlando | (~turlando@user/turlando) (Ping timeout: 255 seconds) |
2023-03-09 01:57:09 +0100 | turlando | (~turlando@user/turlando) |
2023-03-09 01:58:04 +0100 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
2023-03-09 01:58:19 +0100 | tessier | (~treed@ec2-184-72-149-67.compute-1.amazonaws.com) |
2023-03-09 02:02:09 +0100 | marienz | (~marienz@libera/staff/marienz) (Ping timeout: 624 seconds) |
2023-03-09 02:03:07 +0100 | polyphem_ | (~rod@2a02:810d:840:8754:224e:f6ff:fe5e:bc17) (Ping timeout: 248 seconds) |
2023-03-09 02:08:58 +0100 | shriekingnoise | (~shrieking@186.137.175.87) |
2023-03-09 02:09:19 +0100 | typedfern_ | (~Typedfern@60.red-83-37-32.dynamicip.rima-tde.net) |
2023-03-09 02:09:41 +0100 | marienz | (~marienz@libera/staff/marienz) |
2023-03-09 02:10:25 +0100 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
2023-03-09 02:10:43 +0100 | polyphem_ | (~rod@2a02:810d:840:8754:224e:f6ff:fe5e:bc17) |
2023-03-09 02:11:16 +0100 | dsrt^ | (~dsrt@c-24-30-76-89.hsd1.ga.comcast.net) |
2023-03-09 02:11:52 +0100 | zaquest | (~notzaques@5.130.79.72) |
2023-03-09 02:35:38 +0100 | statusbot5 | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) (Remote host closed the connection) |
2023-03-09 02:35:51 +0100 | statusbot | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) |
2023-03-09 02:38:19 +0100 | dcoutts | (~duncan@host81-156-211-236.range81-156.btcentralplus.com) (Ping timeout: 248 seconds) |
2023-03-09 02:49:24 +0100 | xff0x | (~xff0x@ai098135.d.east.v6connect.net) (Ping timeout: 255 seconds) |
2023-03-09 02:55:47 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
2023-03-09 02:58:24 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
2023-03-09 03:00:59 +0100 | esph | (~weechat@user/esph) (Ping timeout: 255 seconds) |
2023-03-09 03:01:35 +0100 | esph | (~weechat@user/esph) |
2023-03-09 03:02:54 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 255 seconds) |
2023-03-09 03:04:48 +0100 | pieguy128 | (~pieguy128@bras-base-mtrlpq5031w-grc-43-67-70-144-160.dsl.bell.ca) (Ping timeout: 248 seconds) |
2023-03-09 03:05:01 +0100 | razetime | (~Thunderbi@117.193.7.18) |
2023-03-09 03:07:47 +0100 | esph | (~weechat@user/esph) (Read error: Connection reset by peer) |
2023-03-09 03:08:11 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 248 seconds) |
2023-03-09 03:12:12 +0100 | ix | (~ix@213.205.192.69) (Ping timeout: 268 seconds) |
2023-03-09 03:18:50 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
2023-03-09 03:21:05 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
2023-03-09 03:22:13 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
2023-03-09 03:24:34 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 252 seconds) |
2023-03-09 03:27:10 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
2023-03-09 03:27:57 +0100 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) |
2023-03-09 03:34:19 +0100 | vglfr | (~vglfr@209.198.138.162) (Ping timeout: 248 seconds) |
2023-03-09 03:34:39 +0100 | vglfr | (~vglfr@209.198.138.162) |
2023-03-09 03:35:38 +0100 | johnjaye | (~pi@173.209.64.74) (Ping timeout: 268 seconds) |
2023-03-09 03:37:27 +0100 | johnjaye | (~pi@173.209.64.74) |
2023-03-09 03:37:27 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
2023-03-09 03:43:36 +0100 | mbuf | (~Shakthi@49.207.178.186) |
2023-03-09 03:49:24 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
2023-03-09 03:52:39 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
2023-03-09 03:54:28 +0100 | codaraxis | (~codaraxis@user/codaraxis) (Ping timeout: 276 seconds) |
2023-03-09 03:58:23 +0100 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection) |
2023-03-09 04:01:37 +0100 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 276 seconds) |
2023-03-09 04:03:20 +0100 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
2023-03-09 04:03:53 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
2023-03-09 04:03:53 +0100 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
2023-03-09 04:03:53 +0100 | finn_elija | FinnElija |
2023-03-09 04:17:33 +0100 | <sm> | hey all |
2023-03-09 04:17:35 +0100 | gastus_ | (~gastus@185.6.123.209) |
2023-03-09 04:18:16 +0100 | <sm> | forM_ :: (Foldable t, Monad m) => t a -> (a -> m b) -> m () |
2023-03-09 04:18:16 +0100 | <sm> | forM :: (Traversable t, Monad m) => t a -> (a -> m b) -> m (t b) |
2023-03-09 04:18:16 +0100 | <sm> | Am I wrong to think forM is forM_ but preserving the return value ? Is their combining behaviour different ? |
2023-03-09 04:20:43 +0100 | gastus | (~gastus@185.6.123.242) (Ping timeout: 248 seconds) |
2023-03-09 04:27:52 +0100 | <dibblego> | not wrong, but forM_ is the specialisation of forM, not the other way around |
2023-03-09 04:28:31 +0100 | td_ | (~td@i53870915.versanet.de) (Ping timeout: 248 seconds) |
2023-03-09 04:28:41 +0100 | <sm> | thanks |
2023-03-09 04:28:52 +0100 | codaraxis | (~codaraxis@user/codaraxis) |
2023-03-09 04:28:55 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 276 seconds) |
2023-03-09 04:30:21 +0100 | td_ | (~td@i53870909.versanet.de) |
2023-03-09 04:32:10 +0100 | malte | (~malte@mal.tc) (Ping timeout: 276 seconds) |
2023-03-09 04:37:32 +0100 | malte | (~malte@mal.tc) |
2023-03-09 04:39:27 +0100 | pieguy128 | (~pieguy128@bas1-quebec14-67-70-103-117.dsl.bell.ca) |
2023-03-09 04:42:34 +0100 | malte | (~malte@mal.tc) (Ping timeout: 276 seconds) |
2023-03-09 04:42:56 +0100 | nattiestnate | (~nate@202.138.250.46) (Ping timeout: 248 seconds) |
2023-03-09 04:48:37 +0100 | bilegeek | (~bilegeek@2600:1008:b08e:25d7:448b:af41:2606:865f) |
2023-03-09 04:56:10 +0100 | malte | (~malte@mal.tc) |
2023-03-09 05:08:05 +0100 | cheater | (~Username@user/cheater) (Remote host closed the connection) |
2023-03-09 05:10:51 +0100 | vglfr | (~vglfr@209.198.138.162) (Ping timeout: 248 seconds) |
2023-03-09 05:11:05 +0100 | cheater | (~Username@user/cheater) |
2023-03-09 05:12:25 +0100 | polyphem_ | (~rod@2a02:810d:840:8754:224e:f6ff:fe5e:bc17) (Ping timeout: 260 seconds) |
2023-03-09 05:17:00 +0100 | razetime | (~Thunderbi@117.193.7.18) (Ping timeout: 255 seconds) |
2023-03-09 05:26:17 +0100 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in) |
2023-03-09 05:26:17 +0100 | jwiegley | (~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in) |
2023-03-09 05:35:42 +0100 | razetime | (~Thunderbi@117.193.7.18) |
2023-03-09 05:37:45 +0100 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
2023-03-09 05:40:22 +0100 | wroathe | (~wroathe@user/wroathe) (Quit: leaving) |
2023-03-09 05:42:19 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
2023-03-09 05:42:20 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
2023-03-09 05:42:20 +0100 | wroathe | (~wroathe@user/wroathe) |
2023-03-09 05:42:42 +0100 | wroathe | (~wroathe@user/wroathe) (Client Quit) |
2023-03-09 06:03:20 +0100 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
2023-03-09 06:12:22 +0100 | _xor | (~xor@74.215.46.17) |
2023-03-09 06:18:56 +0100 | stef204 | (~stef204@user/stef204) (Ping timeout: 248 seconds) |
2023-03-09 06:19:25 +0100 | Square2 | (~Square4@user/square) |
2023-03-09 06:22:26 +0100 | koz | (~koz@121.99.240.58) (Quit: ZNC 1.8.2 - https://znc.in) |
2023-03-09 06:23:24 +0100 | razetime | (~Thunderbi@117.193.7.18) (Quit: See You Space Cowboy) |
2023-03-09 06:23:43 +0100 | koz | (~koz@121.99.240.58) |
2023-03-09 06:25:20 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 248 seconds) |
2023-03-09 06:26:21 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
2023-03-09 06:27:31 +0100 | trev | (~trev@user/trev) |
2023-03-09 06:29:28 +0100 | koz | (~koz@121.99.240.58) (Quit: ZNC 1.8.2 - https://znc.in) |
2023-03-09 06:30:09 +0100 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 268 seconds) |
2023-03-09 06:31:45 +0100 | koz | (~koz@121.99.240.58) |
2023-03-09 06:38:29 +0100 | phma_ | (~phma@2001:5b0:210f:3ec8:b53b:9627:f50b:d3ea) |
2023-03-09 06:39:06 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
2023-03-09 06:39:39 +0100 | cheater_ | (~Username@user/cheater) |
2023-03-09 06:40:48 +0100 | phma | (phma@2001:5b0:215d:c698:2a3:1662:71f8:9a54) (Ping timeout: 248 seconds) |
2023-03-09 06:42:03 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 248 seconds) |
2023-03-09 06:42:04 +0100 | cheater_ | cheater |
2023-03-09 06:46:39 +0100 | cheater_ | (~Username@user/cheater) |
2023-03-09 06:47:37 +0100 | brettgilio | (~brettgili@x-irc.gq) (Read error: Connection reset by peer) |
2023-03-09 06:50:09 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
2023-03-09 06:50:15 +0100 | cheater_ | cheater |
2023-03-09 06:54:02 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
2023-03-09 06:56:36 +0100 | mechap | (~mechap@user/mechap) |
2023-03-09 06:58:15 +0100 | phma | (~phma@host-67-44-208-56.hnremote.net) |
2023-03-09 06:58:37 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
2023-03-09 07:00:31 +0100 | phma_ | (~phma@2001:5b0:210f:3ec8:b53b:9627:f50b:d3ea) (Ping timeout: 246 seconds) |
2023-03-09 07:00:59 +0100 | falafel | (~falafel@75.161.218.9) |
2023-03-09 07:03:23 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 248 seconds) |
2023-03-09 07:06:04 +0100 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) (Read error: Connection reset by peer) |
2023-03-09 07:09:10 +0100 | kenran | (~user@user/kenran) |
2023-03-09 07:11:56 +0100 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) |
2023-03-09 07:14:25 +0100 | xiliuya | (~xiliuya@user/xiliuya) |
2023-03-09 07:19:23 +0100 | freeside | (~mengwong@103.252.202.85) (Ping timeout: 264 seconds) |
2023-03-09 07:23:21 +0100 | chomwitt | (~chomwitt@2a02:587:7a18:6d00:1ac0:4dff:fedb:a3f1) |
2023-03-09 07:28:58 +0100 | shriekingnoise | (~shrieking@186.137.175.87) (Ping timeout: 276 seconds) |
2023-03-09 07:31:59 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds) |
2023-03-09 07:33:02 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
2023-03-09 07:33:09 +0100 | Goodbye_Vincent | (cyvahl@freakshells.net) (Quit: Ping timeout (120 seconds)) |
2023-03-09 07:33:22 +0100 | Goodbye_Vincent | (cyvahl@freakshells.net) |
2023-03-09 07:33:26 +0100 | freeside | (~mengwong@103.252.202.85) |
2023-03-09 07:34:03 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
2023-03-09 07:34:41 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
2023-03-09 07:35:02 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
2023-03-09 07:41:17 +0100 | vglfr | (~vglfr@209.198.138.7) |
2023-03-09 07:46:17 +0100 | phma | (~phma@host-67-44-208-56.hnremote.net) (Quit: Konversation terminated!) |
2023-03-09 07:46:18 +0100 | falafel | (~falafel@75.161.218.9) (Remote host closed the connection) |
2023-03-09 07:46:24 +0100 | <Inst_> | is anyone interested in helping me with what appears to be a cool GHCI bug? |
2023-03-09 07:46:39 +0100 | <Inst_> | https://media.discordapp.net/attachments/280033776820813825/1083277713877516298/image.png?width=11… |
2023-03-09 07:47:21 +0100 | phma | (phma@2001:5b0:2144:2188:ce75:d293:d13a:b375) |
2023-03-09 07:49:05 +0100 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
2023-03-09 07:49:35 +0100 | jwiegley | (~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
2023-03-09 07:49:59 +0100 | razetime | (~Thunderbi@117.193.7.18) |
2023-03-09 07:52:24 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
2023-03-09 07:57:18 +0100 | <Inst_> | got it explained |
2023-03-09 07:57:22 +0100 | <Inst_> | I was defining the minus operator |
2023-03-09 08:09:11 +0100 | YoungFrog | (~youngfrog@2a02:a03f:ca07:f900:a8be:2d7b:23bb:d884) (Quit: ZNC 1.7.x-git-3-96481995 - https://znc.in) |
2023-03-09 08:09:31 +0100 | YoungFrog | (~youngfrog@2a02:a03f:ca07:f900:9c2d:58ba:f0b6:128f) |
2023-03-09 08:22:16 +0100 | vglfr | (~vglfr@209.198.138.7) (Ping timeout: 276 seconds) |
2023-03-09 08:22:39 +0100 | vglfr | (~vglfr@209.198.138.7) |
2023-03-09 08:31:38 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
2023-03-09 08:34:15 +0100 | bilegeek | (~bilegeek@2600:1008:b08e:25d7:448b:af41:2606:865f) (Quit: Leaving) |
2023-03-09 08:35:21 +0100 | <dminuoso> | int-e: Ah I see, thanks |
2023-03-09 08:35:32 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:fc2c:23ef:a0df:9b5f) |
2023-03-09 08:43:09 +0100 | _xor | (~xor@74.215.46.17) (Quit: brb) |
2023-03-09 08:44:42 +0100 | xiliuya | (~xiliuya@user/xiliuya) (Quit: Lost terminal) |
2023-03-09 08:46:01 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
2023-03-09 08:46:10 +0100 | nattiestnate | (~nate@167.205.0.251) |
2023-03-09 08:47:35 +0100 | gurkenglas | (~gurkengla@dynamic-046-114-178-105.46.114.pool.telefonica.de) |
2023-03-09 08:48:48 +0100 | qhong_ | qhong |
2023-03-09 08:49:30 +0100 | nattiestnate | (~nate@167.205.0.251) (Client Quit) |
2023-03-09 08:58:59 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
2023-03-09 09:00:37 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
2023-03-09 09:02:23 +0100 | MajorBiscuit | (~MajorBisc@c-001-001-058.client.tudelft.eduvpn.nl) |
2023-03-09 09:05:14 +0100 | MajorBiscuit | (~MajorBisc@c-001-001-058.client.tudelft.eduvpn.nl) (Client Quit) |
2023-03-09 09:06:43 +0100 | codaraxis | (~codaraxis@user/codaraxis) (Quit: Leaving) |
2023-03-09 09:07:36 +0100 | MajorBiscuit | (~MajorBisc@c-001-001-058.client.tudelft.eduvpn.nl) |
2023-03-09 09:07:46 +0100 | razetime | (~Thunderbi@117.193.7.18) (Ping timeout: 276 seconds) |
2023-03-09 09:08:18 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 255 seconds) |
2023-03-09 09:10:50 +0100 | thegeekinside | (~thegeekin@189.141.115.134) (Remote host closed the connection) |
2023-03-09 09:13:14 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
2023-03-09 09:13:18 +0100 | coot | (~coot@213.134.171.3) |
2023-03-09 09:13:28 +0100 | califax | (~califax@user/califx) |
2023-03-09 09:17:05 +0100 | fnurglewitz | (uid263868@id-263868.lymington.irccloud.com) |
2023-03-09 09:18:38 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
2023-03-09 09:20:28 +0100 | razetime | (~Thunderbi@117.193.7.18) |
2023-03-09 09:20:57 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
2023-03-09 09:26:17 +0100 | acidjnk | (~acidjnk@p200300d6e715c49459520d9465f62029.dip0.t-ipconnect.de) |
2023-03-09 09:30:04 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) (Remote host closed the connection) |
2023-03-09 09:30:08 +0100 | akegalj | (~akegalj@78.3.82.42) |
2023-03-09 09:35:48 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
2023-03-09 09:39:37 +0100 | vglfr | (~vglfr@209.198.138.7) (Ping timeout: 276 seconds) |
2023-03-09 09:40:00 +0100 | vglfr | (~vglfr@145.224.100.102) |
2023-03-09 09:53:01 +0100 | michalz | (~michalz@185.246.204.125) |
2023-03-09 09:55:27 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
2023-03-09 10:00:27 +0100 | gurkenglas | (~gurkengla@dynamic-046-114-178-105.46.114.pool.telefonica.de) (Ping timeout: 248 seconds) |
2023-03-09 10:02:20 +0100 | gurkenglas | (~gurkengla@dynamic-046-114-178-105.46.114.pool.telefonica.de) |
2023-03-09 10:04:33 +0100 | zeenk | (~zeenk@2a02:2f04:a20d:f900::7fe) |
2023-03-09 10:11:34 +0100 | ft | (~ft@p3e9bc443.dip0.t-ipconnect.de) (Quit: leaving) |
2023-03-09 10:17:16 +0100 | jtmar | (~james@jtmar.me) (Ping timeout: 265 seconds) |
2023-03-09 10:18:03 +0100 | jamestmartin | (~james@jtmar.me) |
2023-03-09 10:29:40 +0100 | _xor | (~xor@74.215.46.17) |
2023-03-09 10:30:32 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) |
2023-03-09 10:33:31 +0100 | freeside | (~mengwong@103.252.202.85) (Ping timeout: 248 seconds) |
2023-03-09 10:35:07 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) (Ping timeout: 248 seconds) |
2023-03-09 10:36:49 +0100 | vglfr | (~vglfr@145.224.100.102) (Ping timeout: 276 seconds) |
2023-03-09 10:38:08 +0100 | CiaoSen | (~Jura@p200300c9570e91002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
2023-03-09 10:39:00 +0100 | vglfr | (~vglfr@145.224.100.102) |
2023-03-09 10:49:10 +0100 | vglfr | (~vglfr@145.224.100.102) (Ping timeout: 276 seconds) |
2023-03-09 10:49:52 +0100 | vglfr | (~vglfr@209.198.138.7) |
2023-03-09 10:50:39 +0100 | __monty__ | (~toonn@user/toonn) |
2023-03-09 10:52:30 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
2023-03-09 10:53:51 +0100 | thegeekinside | (~thegeekin@189.141.115.134) |
2023-03-09 10:54:23 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
2023-03-09 10:55:11 +0100 | gmg | (~user@user/gehmehgeh) |
2023-03-09 10:59:20 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
2023-03-09 11:01:35 +0100 | zeenk | (~zeenk@2a02:2f04:a20d:f900::7fe) (Remote host closed the connection) |
2023-03-09 11:01:57 +0100 | zeenk | (~zeenk@2a02:2f04:a20d:f900::fba) |
2023-03-09 11:02:19 +0100 | thegeekinside | (~thegeekin@189.141.115.134) (Ping timeout: 248 seconds) |
2023-03-09 11:08:43 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 248 seconds) |
2023-03-09 11:09:35 +0100 | acidjnk | (~acidjnk@p200300d6e715c49459520d9465f62029.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
2023-03-09 11:13:58 +0100 | sayola | (~sayola@ipservice-092-213-087-211.092.213.pools.vodafone-ip.de) (Read error: Connection reset by peer) |
2023-03-09 11:17:35 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
2023-03-09 11:26:51 +0100 | ph88 | (~ph88@ip5b426553.dynamic.kabel-deutschland.de) (Ping timeout: 248 seconds) |
2023-03-09 11:32:13 +0100 | MajorBiscuit | (~MajorBisc@c-001-001-058.client.tudelft.eduvpn.nl) (Quit: WeeChat 3.6) |
2023-03-09 11:33:13 +0100 | Lycurgus | (~juan@user/Lycurgus) |
2023-03-09 11:36:59 +0100 | PhilipKaludercic | (~oj14ozunf@2001:470:69fc:105::3:2913) |
2023-03-09 11:42:03 +0100 | mmhat | (~mmh@p200300f1c701ed74ee086bfffe095315.dip0.t-ipconnect.de) |
2023-03-09 11:46:03 +0100 | chomwitt | (~chomwitt@2a02:587:7a18:6d00:1ac0:4dff:fedb:a3f1) (Ping timeout: 248 seconds) |
2023-03-09 11:46:50 +0100 | razetime | (~Thunderbi@117.193.7.18) (Remote host closed the connection) |
2023-03-09 11:47:05 +0100 | phma_ | (~phma@host-67-44-208-90.hnremote.net) |
2023-03-09 11:48:58 +0100 | <mmhat> | -quit |
2023-03-09 11:49:06 +0100 | mmhat | (~mmh@p200300f1c701ed74ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.8) |
2023-03-09 11:50:08 +0100 | phma | (phma@2001:5b0:2144:2188:ce75:d293:d13a:b375) (Ping timeout: 248 seconds) |
2023-03-09 11:50:55 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 276 seconds) |
2023-03-09 11:55:09 +0100 | phma | (~phma@host-67-44-208-94.hnremote.net) |
2023-03-09 11:56:59 +0100 | phma_ | (~phma@host-67-44-208-90.hnremote.net) (Ping timeout: 268 seconds) |
2023-03-09 11:57:24 +0100 | CiaoSen | (~Jura@p200300c9570e91002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
2023-03-09 11:58:26 +0100 | acidjnk | (~acidjnk@p200300d6e715c494181d60e4bd1f4f9f.dip0.t-ipconnect.de) |
2023-03-09 11:59:29 +0100 | phma_ | (~phma@host-67-44-208-94.hnremote.net) |
2023-03-09 12:00:41 +0100 | phma | (~phma@host-67-44-208-94.hnremote.net) (Ping timeout: 268 seconds) |
2023-03-09 12:01:19 +0100 | <kuribas> | nobody quits haskell, it's for life :) |
2023-03-09 12:06:42 +0100 | mastarija | (~mastarija@188.252.198.83) |
2023-03-09 12:09:08 +0100 | freeside | (~mengwong@103.252.202.85) |
2023-03-09 12:09:55 +0100 | MajorBiscuit | (~MajorBisc@c-001-001-058.client.tudelft.eduvpn.nl) |
2023-03-09 12:10:18 +0100 | phma_ | phma |
2023-03-09 12:14:46 +0100 | xff0x | (~xff0x@2405:6580:b080:900:a142:fa3c:5d94:d75c) |
2023-03-09 12:15:10 +0100 | <sm> | right |
2023-03-09 12:15:18 +0100 | <sm> | you can check in any time you want... |
2023-03-09 12:20:05 +0100 | <kenran> | for you opticians, can I do the following "just with optics"? if view #foo x == Blub then Just (view #bar x) else Nothing |
2023-03-09 12:21:22 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
2023-03-09 12:21:27 +0100 | <dminuoso> | kenran: Exactly like that? |
2023-03-09 12:21:39 +0100 | <dminuoso> | Just give it a try. :) |
2023-03-09 12:22:31 +0100 | <kenran> | uhm, I'm probably lacking "vocabulary" here. I don't know how to get the conditional "into" the lens world, if that makes sense |
2023-03-09 12:24:26 +0100 | <kenran> | I know I can use something like preview (#foo . #_Blub) x to get either a Just () if it matches Blub, or Nothing otherwise. hum, maybe that leads somewhere |
2023-03-09 12:24:32 +0100 | phma | (~phma@host-67-44-208-94.hnremote.net) (Read error: Connection reset by peer) |
2023-03-09 12:25:18 +0100 | phma | (~phma@2001:5b0:210f:6d68:df04:da38:ad7:41b3) |
2023-03-09 12:25:45 +0100 | <kenran> | but then I "went down too far" into x to somehow append the #foo to the chain, haven't I? |
2023-03-09 12:34:48 +0100 | pdw | (~user@215.156.62.185.bridgefibre.net) |
2023-03-09 12:35:21 +0100 | akegalj | (~akegalj@78.3.82.42) (Quit: leaving) |
2023-03-09 12:40:47 +0100 | <jackdk> | you can shove it into the indexed part of an optic using selfIndex and pull it back out using asIndex, but I forget exactly how |
2023-03-09 12:43:59 +0100 | xff0x | (~xff0x@2405:6580:b080:900:a142:fa3c:5d94:d75c) (Ping timeout: 248 seconds) |
2023-03-09 12:44:22 +0100 | xff0x | (~xff0x@ai098135.d.east.v6connect.net) |
2023-03-09 13:01:51 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
2023-03-09 13:02:07 +0100 | NiceBird | (~NiceBird@185.133.111.196) |
2023-03-09 13:02:14 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) |
2023-03-09 13:04:10 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
2023-03-09 13:10:51 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Ping timeout: 255 seconds) |
2023-03-09 13:11:15 +0100 | <dminuoso> | kenran: You can use filtered or filteredBy |
2023-03-09 13:11:33 +0100 | <dminuoso> | (Or unsafe equivalents if needed)_ |
2023-03-09 13:11:59 +0100 | <dminuoso> | Note, that this is even possible in lens (though in lens the unsafe behavior is mixed into the filteredBy) |
2023-03-09 13:12:21 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
2023-03-09 13:16:42 +0100 | chele | (~chele@user/chele) |
2023-03-09 13:32:56 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2023-03-09 13:34:16 +0100 | xff0x | (~xff0x@ai098135.d.east.v6connect.net) (Ping timeout: 276 seconds) |
2023-03-09 13:34:55 +0100 | Lycurgus | (~juan@user/Lycurgus) (Ping timeout: 276 seconds) |
2023-03-09 13:35:40 +0100 | xff0x | (~xff0x@178.255.149.135) |
2023-03-09 13:45:19 +0100 | xff0x | (~xff0x@178.255.149.135) (Ping timeout: 276 seconds) |
2023-03-09 13:46:53 +0100 | xff0x | (~xff0x@2405:6580:b080:900:a142:fa3c:5d94:d75c) |
2023-03-09 13:48:43 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
2023-03-09 13:54:38 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
2023-03-09 13:55:00 +0100 | <kuribas> | Is there something you can do with linear types, that you cannot do with the ST monad? |
2023-03-09 13:55:30 +0100 | <kuribas> | Many of the usecases I see can be done with the ST monad, like resource usage, or even better than with linear types. |
2023-03-09 13:56:36 +0100 | <kuribas> | for example: https://hackage.haskell.org/package/text-builder-linear-0.1/docs/Data-Text-Builder-Linear.html |
2023-03-09 13:57:12 +0100 | <kuribas> | What is different from using "Builder s -> ST s (Builder s)" instead of Buffer ⊸ Buffer |
2023-03-09 13:57:16 +0100 | <kuribas> | ? |
2023-03-09 13:58:19 +0100 | gurkenglas | (~gurkengla@dynamic-046-114-178-105.46.114.pool.telefonica.de) (Ping timeout: 276 seconds) |
2023-03-09 13:58:19 +0100 | acidjnk | (~acidjnk@p200300d6e715c494181d60e4bd1f4f9f.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
2023-03-09 13:58:29 +0100 | <kuribas> | I have seen examples where the linear types actually can leak the resource. |
2023-03-09 13:59:08 +0100 | lyle | (~lyle@104.246.145.237) |
2023-03-09 13:59:16 +0100 | <lortabac> | kuribas: I'm not the right person to answer this question, but *as far as I understand* linear types are not about enabling new functionality, but tracking more information in the types |
2023-03-09 13:59:50 +0100 | <merijn> | kuribas: The former can be further mutated later |
2023-03-09 13:59:56 +0100 | <merijn> | oh, wait |
2023-03-09 14:00:03 +0100 | <merijn> | the 2nd one is linear arrow |
2023-03-09 14:00:10 +0100 | <merijn> | Then no fucking clue :p |
2023-03-09 14:00:51 +0100 | <aforemny> | kuribas: the paper on linear types has a section about that |
2023-03-09 14:02:55 +0100 | stef204 | (~stef204@user/stef204) |
2023-03-09 14:04:36 +0100 | gurkenglas | (~gurkengla@dynamic-046-114-177-189.46.114.pool.telefonica.de) |
2023-03-09 14:05:27 +0100 | <aforemny> | kuribas: i think specifically section 5.1 is an example, but maybe also 2.2, 2.3 i don't remember off the top of my head |
2023-03-09 14:05:36 +0100 | <aforemny> | kuribas: https://arxiv.org/abs/1710.09756 |
2023-03-09 14:05:48 +0100 | <int-e> | kuribas: Linear types can express DAGs of dependencies, where the ST monad forces you to write linear computations (or to use unsafeInterleaveST) |
2023-03-09 14:06:09 +0100 | <int-e> | err, sequential, I should say |
2023-03-09 14:07:21 +0100 | <ncf> | what do linear types have to do with ST? |
2023-03-09 14:07:23 +0100 | <int-e> | Stemming from the fact that there's only one linearly restricted thing inside the ST monad (the encapsulated state token). |
2023-03-09 14:07:48 +0100 | <ncf> | Builder s -> ST s (Builder s) doesn't have to be linear in its argument, does it? |
2023-03-09 14:08:42 +0100 | <int-e> | ncf: I think I just accidentally answered this. |
2023-03-09 14:08:57 +0100 | lechner | (~lechner@debian/lechner) (Using Circe, the loveliest of all IRC clients) |
2023-03-09 14:09:19 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
2023-03-09 14:10:52 +0100 | <int-e> | (In a slogan, `forall s. ST s a` provides linearity without linear types.) |
2023-03-09 14:11:15 +0100 | <int-e> | (But it's less flexible.) |
2023-03-09 14:11:34 +0100 | <ncf> | i don't see how |
2023-03-09 14:11:45 +0100 | <ncf> | it provides linearity |
2023-03-09 14:12:42 +0100 | <int-e> | Oh, the type Builder s -> ST s (Builder s) is wrong of course. |
2023-03-09 14:12:59 +0100 | stef204 | (~stef204@user/stef204) (Quit: WeeChat 3.8) |
2023-03-09 14:13:27 +0100 | <int-e> | Instead you'd need a reference-like interface, Builder s -> Input -> ST s () |
2023-03-09 14:14:04 +0100 | <int-e> | (for appending to te builder) |
2023-03-09 14:14:18 +0100 | <ncf> | so references provide linearity, is what we're saying? |
2023-03-09 14:14:36 +0100 | <int-e> | No. I'm saying that ST s a *embeds* a linear thing. |
2023-03-09 14:17:08 +0100 | <int-e> | You'll never see that thing (the state token) because without linear types to enforce that it's used only once, exposing it would break that linearity. |
2023-03-09 14:18:15 +0100 | <kuribas> | int-e: I don't know about less flexible. There was a leak in an idris library of mutable arrays. |
2023-03-09 14:18:28 +0100 | <ncf> | hmm so ST s a would be equivalent to s ⊸ (a, s) ? |
2023-03-09 14:18:29 +0100 | <kuribas> | int-e: whereas the ST monad didn't have a leak. |
2023-03-09 14:18:32 +0100 | cfricke | (~cfricke@user/cfricke) |
2023-03-09 14:18:42 +0100 | <int-e> | kuribas: apples, oranges |
2023-03-09 14:19:20 +0100 | PhilipKaludercic | (~oj14ozunf@2001:470:69fc:105::3:2913) () |
2023-03-09 14:19:37 +0100 | <kuribas> | why? This was literally an advacated usecase for linear types, where the ST version worked fine. |
2023-03-09 14:19:49 +0100 | <int-e> | ncf: Pretty much. |
2023-03-09 14:19:59 +0100 | <kuribas> | And in the end there was a complicated construction that was supposed to be working. |
2023-03-09 14:21:02 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds) |
2023-03-09 14:21:11 +0100 | <int-e> | kuribas: I know nothing about that leak but I imagine that if you don't fully specify the order of evaluations, some part of the computation can be delayed forever. |
2023-03-09 14:21:37 +0100 | <int-e> | But foremost, I don't know about that leak so I probably shouldn't even speculate. |
2023-03-09 14:21:46 +0100 | <kuribas> | ncf: no, because there is nothing that specifies the values of type "s" have to be the same. |
2023-03-09 14:22:47 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
2023-03-09 14:23:10 +0100 | <kuribas> | erm, if the s is always hidden I guess it's the same... |
2023-03-09 14:23:56 +0100 | <kuribas> | Isn't the "s" in "ST s a" a phantom type? |
2023-03-09 14:24:37 +0100 | <int-e> | Yes, the underlying type will be State# s -> (a, State# s) |
2023-03-09 14:24:51 +0100 | Square2 | (~Square4@user/square) |
2023-03-09 14:24:53 +0100 | <int-e> | But that's not essential for the analogy, I think. |
2023-03-09 14:26:10 +0100 | <kuribas> | int-e: leak: https://github.com/idris-lang/Idris2/issues/613 |
2023-03-09 14:26:20 +0100 | cheater_ | (~Username@user/cheater) |
2023-03-09 14:26:31 +0100 | <mauke> | that doesn't look phantom |
2023-03-09 14:28:15 +0100 | <mauke> | that's less of a leak and more just outright unsafe |
2023-03-09 14:28:42 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
2023-03-09 14:29:00 +0100 | <int-e> | Oh, contributed code... so it's more like early ByteString using inlinePerformIO everywhere. |
2023-03-09 14:30:33 +0100 | <int-e> | (Leading to mutable arrays being potentially shared across several bytestring creations... that's analogous, isn't it?) |
2023-03-09 14:31:08 +0100 | <kuribas> | mauke: right, it allows you to mutate an immutable array. |
2023-03-09 14:31:51 +0100 | cheater_ | (~Username@user/cheater) (Ping timeout: 255 seconds) |
2023-03-09 14:33:50 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) |
2023-03-09 14:34:02 +0100 | <kuribas> | int-e: so "Buffer s -> ST s ()" should give the same performance benifits as "Buffer ⊸ Buffer", right? |
2023-03-09 14:34:20 +0100 | <kuribas> | assuming the monad gets elimited by GHC. |
2023-03-09 14:34:35 +0100 | cheater_ | (~Username@user/cheater) |
2023-03-09 14:34:35 +0100 | cheater_ | cheater |
2023-03-09 14:34:59 +0100 | <int-e> | It gives you mutation. |
2023-03-09 14:35:04 +0100 | <mauke> | .oO( elimited ontinuations ) |
2023-03-09 14:35:37 +0100 | <kuribas> | int-e: which I don't care, because this type is an implementation detail, right? |
2023-03-09 14:35:39 +0100 | <int-e> | "same"... depends on the underlying primitives, I won't speculate. |
2023-03-09 14:35:52 +0100 | <ncf> | i think the paper also touches on performance |
2023-03-09 14:36:38 +0100 | cheater_ | (~Username@user/cheater) |
2023-03-09 14:38:15 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) (Ping timeout: 260 seconds) |
2023-03-09 14:38:59 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 246 seconds) |
2023-03-09 14:39:05 +0100 | cheater_ | cheater |
2023-03-09 14:39:06 +0100 | <kuribas> | So linear types can be useful to track state changes in the type using phantom variables. |
2023-03-09 14:39:12 +0100 | <int-e> | Anyway, ultimately that ticket seems to be more about actually working with linear types; I'll take away that constructors for mutable data can be tricky to express. |
2023-03-09 14:39:57 +0100 | <int-e> | It's a user error. :-P |
2023-03-09 14:40:10 +0100 | <kuribas> | That ticket solves a problem using linear types, that was actually already solved with ST monad. |
2023-03-09 14:41:12 +0100 | <int-e> | And I'm still very amused by the fact that we got *exactly* this phenomonon (sharing mutable arrays) in a completely different way in early bytestring. |
2023-03-09 14:41:45 +0100 | <kuribas> | And that was a bug in the implementation? |
2023-03-09 14:42:22 +0100 | <int-e> | Basically, `inlinePerformIO` exposes the state token so the compiler feels free to use it more than once. |
2023-03-09 14:43:56 +0100 | <kuribas> | Could I make a linear mutable array by tracking the version? |
2023-03-09 14:44:41 +0100 | <kuribas> | Like update :: Int -> a -> (Array a 1) ⊸ (Array 2) |
2023-03-09 14:44:52 +0100 | <int-e> | `unsafePerformIO` very much relies on blinding the compiler about the fact that the same state token is used every single time. This is achieved largely through cleverly *not* inlining it until the last possible moment. |
2023-03-09 14:45:18 +0100 | <int-e> | kuribas: What's preventing you from using version 1 more than once? |
2023-03-09 14:45:27 +0100 | <kuribas> | the linear arrow? |
2023-03-09 14:46:15 +0100 | <int-e> | [unsafePerformIO] and `inlinePerformIO` broke this careful balance by inlining immediately, opening IO actions up to common subexpression elimination and hence sharing. |
2023-03-09 14:46:36 +0100 | <int-e> | kuribas: then what do you need the version for? |
2023-03-09 14:46:47 +0100 | dsrt^ | (~dsrt@c-24-30-76-89.hsd1.ga.comcast.net) (Remote host closed the connection) |
2023-03-09 14:46:58 +0100 | <kuribas> | int-e: to avoid accessing a previous version? |
2023-03-09 14:47:12 +0100 | <int-e> | kuribas: you just said that that's what the linear arrow is for |
2023-03-09 14:47:28 +0100 | <int-e> | At least one of us is confused here. |
2023-03-09 14:47:34 +0100 | <kuribas> | me probably :) |
2023-03-09 14:47:54 +0100 | <kuribas> | Well, without the linear arrow, you could still access the old version. |
2023-03-09 14:48:54 +0100 | <int-e> | Sure, but what do you can compared to ... Array a -o Array a? |
2023-03-09 14:49:45 +0100 | chomwitt | (~chomwitt@2a02:587:7a18:6d00:1ac0:4dff:fedb:a3f1) |
2023-03-09 14:49:52 +0100 | <kuribas> | hmm... |
2023-03-09 14:50:11 +0100 | <int-e> | can? gain. |
2023-03-09 15:01:21 +0100 | <kuribas> | yeah this doesn't work. |
2023-03-09 15:03:27 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
2023-03-09 15:03:46 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
2023-03-09 15:04:50 +0100 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) |
2023-03-09 15:06:02 +0100 | <kuribas> | int-e: you need a linear continuation, which is where the bug occurs. |
2023-03-09 15:06:48 +0100 | <kuribas> | Because if the return value of the continuation is a type variables, you can return the mutable array. |
2023-03-09 15:07:00 +0100 | <kuribas> | I don't see an easy fix. |
2023-03-09 15:08:31 +0100 | gurkenglas | (~gurkengla@dynamic-046-114-177-189.46.114.pool.telefonica.de) (Ping timeout: 276 seconds) |
2023-03-09 15:18:27 +0100 | thegeekinside | (~thegeekin@189.141.115.134) |
2023-03-09 15:22:05 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
2023-03-09 15:23:43 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
2023-03-09 15:24:27 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
2023-03-09 15:28:12 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
2023-03-09 15:33:30 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
2023-03-09 15:34:31 +0100 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 3.8) |
2023-03-09 15:36:01 +0100 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) |
2023-03-09 15:38:31 +0100 | MacSlow | (~MacSlow@p57bb2fc5.dip0.t-ipconnect.de) |
2023-03-09 15:38:41 +0100 | <MacSlow> | Greetings everybody! |
2023-03-09 15:41:39 +0100 | <MacSlow> | Am I meant to be able to compile/install split 0.2.3.5 using ghc 8.8.4 and cabal 3.0.1.0? While it compiles (library and tests) the command 'cabal install' fails with: 'cabal: Cannot build the executables in the package split because it does not contain any executables.' |
2023-03-09 15:42:32 +0100 | <MacSlow> | I have no idea what that means and searching for hints on this error using the usual search engines yield links to unrelated errors. |
2023-03-09 15:42:49 +0100 | <MacSlow> | Any advice is greatly appreciated... thanks in advance! |
2023-03-09 15:45:01 +0100 | <geekosaur> | you don't install libraries directly, you let cabal (or stack) manage them |
2023-03-09 15:45:21 +0100 | Lycurgus | (~juan@98.4.112.204) |
2023-03-09 15:45:21 +0100 | Lycurgus | (~juan@98.4.112.204) (Changing host) |
2023-03-09 15:45:21 +0100 | Lycurgus | (~juan@user/Lycurgus) |
2023-03-09 15:45:41 +0100 | <geekosaur> | if you have some project that uses that package, you declare a dependency on it and cabal will expose it as needed |
2023-03-09 15:45:49 +0100 | <MacSlow> | geekosaur: isn't that what I did via cabal_ |
2023-03-09 15:45:52 +0100 | <MacSlow> | ? |
2023-03-09 15:46:13 +0100 | vglfr | (~vglfr@209.198.138.7) (Ping timeout: 276 seconds) |
2023-03-09 15:46:17 +0100 | <geekosaur> | this avoids having multiple versions of a library installed and making ghc get confused about which one to use |
2023-03-09 15:46:29 +0100 | <MacSlow> | geekosaur: I git cloned split and then followed the readme file about how to build/install it via cabal. |
2023-03-09 15:46:48 +0100 | <int-e> | If you want to keep the old workflow for a bit longer, use `cabal v1-install`, but this command is going to disappear. |
2023-03-09 15:46:48 +0100 | <geekosaur> | most things like that have instructions for the old version of cabal |
2023-03-09 15:47:53 +0100 | int-e | wonders how terrible v2-install --lib is. |
2023-03-09 15:48:26 +0100 | <MacSlow> | geekosaur: hm... I just wend outside of the git cloned directory of split and did 'cabal install split --lib' and that seemed to have worked. |
2023-03-09 15:48:49 +0100 | <geekosaur> | right, but it invites problems later |
2023-03-09 15:49:07 +0100 | <geekosaur> | we stopped using v1-install (and --lib which simulates it) for a reason |
2023-03-09 15:50:05 +0100 | <int-e> | fsvo "we" |
2023-03-09 15:51:33 +0100 | <int-e> | (I realize this is an outlier but I still like cabal sandboxes) |
2023-03-09 15:52:17 +0100 | <geekosaur> | I do too, actually, and am somewhat surprised someone hasn't hacked up an external solution to bring them back |
2023-03-09 15:52:33 +0100 | <geekosaur> | but I've been getting used to the new workflow |
2023-03-09 15:52:35 +0100 | <mastarija> | Do we have something in base to check if type level list is a subset of another? |
2023-03-09 15:52:53 +0100 | <geekosaur> | afaik base has nothing for type level lists |
2023-03-09 15:53:34 +0100 | <mastarija> | any good package? |
2023-03-09 15:53:37 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
2023-03-09 15:54:12 +0100 | <geekosaur> | re --lib: it can be bad news if you use the default package env, but if you use a local one it's fine |
2023-03-09 15:54:36 +0100 | <geekosaur> | (and is not so different from sandboxes) |
2023-03-09 15:55:18 +0100 | <kuribas> | int-e: You need to use an explicit continuation, like (mkResource : (Res ⊸ ()) -> ()), but that means I cannot return something meaningful. |
2023-03-09 15:55:32 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2023-03-09 15:55:44 +0100 | <kuribas> | int-e: If I use (mkResource : (Res ⊸ a) -> a), I can leak the resource. |
2023-03-09 15:55:56 +0100 | shriekingnoise | (~shrieking@186.137.175.87) |
2023-03-09 15:56:36 +0100 | <geekosaur> | maybe you want something ST-ish with the resource tagged? |
2023-03-09 15:57:03 +0100 | <kuribas> | geekosaur: yeah, I was arguing that the ST monad solves many of the problem that linear types are supposed to solve. |
2023-03-09 15:57:20 +0100 | <MacSlow> | geekosaur: cls |
2023-03-09 15:57:24 +0100 | <MacSlow> | ups :) |
2023-03-09 15:57:33 +0100 | <MacSlow> | wrong window |
2023-03-09 15:58:04 +0100 | <MacSlow> | cls |
2023-03-09 15:58:12 +0100 | <MacSlow> | gee... *sigh* |
2023-03-09 16:01:12 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt: personae.ai-integration.biz) |
2023-03-09 16:01:59 +0100 | Lycurgus | (~juan@user/Lycurgus) |
2023-03-09 16:05:16 +0100 | <int-e> | kuribas: It's funny that the first comment on that ticket is "let's just do what ST does". |
2023-03-09 16:05:27 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:fc2c:23ef:a0df:9b5f) (Quit: WeeChat 2.8) |
2023-03-09 16:06:26 +0100 | <int-e> | kuribas: with less clutter: ((forall s. Res s) -o a) -> a |
2023-03-09 16:06:53 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2023-03-09 16:08:17 +0100 | <int-e> | kuribas: But I guess you'd have to carry that over to updates too? So every update will be (forall s. Res s) -> Res s? I don't know. I've never thought about this before. |
2023-03-09 16:09:53 +0100 | <int-e> | kuribas: surry, that should be (forall s. Res s -o a) -> a instead. The point being, you get to 'leak' the resource, but the 's' will become fixed. |
2023-03-09 16:10:19 +0100 | <int-e> | hmm |
2023-03-09 16:10:23 +0100 | <int-e> | Nah, it just doesn't work. |
2023-03-09 16:11:28 +0100 | <int-e> | Funny. The linear types story is so neat for updates. |
2023-03-09 16:11:55 +0100 | <kuribas> | What if I want to create two arrays? |
2023-03-09 16:12:01 +0100 | <kuribas> | Can I mix the s'es? |
2023-03-09 16:12:48 +0100 | <int-e> | Your resource can be a root of linearity... once you have that you can have createArray :: Res s -o (Res s, Array s a) |
2023-03-09 16:12:49 +0100 | cheater_ | (~Username@user/cheater) |
2023-03-09 16:13:16 +0100 | <kuribas> | right |
2023-03-09 16:13:20 +0100 | <kuribas> | so the ST monad basically :) |
2023-03-09 16:13:50 +0100 | <kuribas> | I could make a linear indexed monads in idris with overloaded do. |
2023-03-09 16:14:08 +0100 | <kuribas> | But then, it works fine with the normal ST monad. |
2023-03-09 16:15:17 +0100 | <kuribas> | Well, maybe the advantage is that I can store the linear resource in a datatype. |
2023-03-09 16:15:23 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 248 seconds) |
2023-03-09 16:15:25 +0100 | cheater_ | cheater |
2023-03-09 16:15:44 +0100 | <kuribas> | With an existential. |
2023-03-09 16:17:07 +0100 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) |
2023-03-09 16:18:45 +0100 | vglfr | (~vglfr@209.198.138.7) |
2023-03-09 16:21:06 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
2023-03-09 16:27:46 +0100 | chomwitt | (~chomwitt@2a02:587:7a18:6d00:1ac0:4dff:fedb:a3f1) (Ping timeout: 252 seconds) |
2023-03-09 16:28:37 +0100 | polyphem_ | (~rod@2a02:810d:840:8754:8192:31bf:f6c3:eb7e) |
2023-03-09 16:30:39 +0100 | Sgeo | (~Sgeo@user/sgeo) |
2023-03-09 16:33:40 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
2023-03-09 16:34:10 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
2023-03-09 16:35:53 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Read error: Connection reset by peer) |
2023-03-09 16:37:04 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
2023-03-09 16:37:29 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
2023-03-09 16:37:46 +0100 | <kuribas> | int-e: why did you say it doesn't work? |
2023-03-09 16:39:11 +0100 | <int-e> | kuribas: Because you can still leak the resource existentially. |
2023-03-09 16:40:21 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
2023-03-09 16:42:09 +0100 | <kuribas> | int-e: but it will be fixed, like you said? |
2023-03-09 16:43:01 +0100 | <int-e> | Sure but you can still feed it into the proposed Res s -o (Res s, Array s a) interface. |
2023-03-09 16:43:09 +0100 | CiaoSen | (~Jura@p200300c9570e91002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
2023-03-09 16:46:01 +0100 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 276 seconds) |
2023-03-09 16:47:18 +0100 | Lycurgus | (~juan@user/Lycurgus) (Ping timeout: 255 seconds) |
2023-03-09 16:48:06 +0100 | <EvanR> | can you? |
2023-03-09 16:48:31 +0100 | <EvanR> | I thought when doing ST-like stuff the type checker (rightly) complains it can't tell they two s are the same |
2023-03-09 16:49:18 +0100 | <EvanR> | someone gives you an existential containing an "unknown" s, can't do anything with it |
2023-03-09 16:50:13 +0100 | <kuribas> | yeah, but then createArray must have another signature. |
2023-03-09 16:53:45 +0100 | <int-e> | maybe we should read https://arxiv.org/abs/2104.00480 |
2023-03-09 16:54:02 +0100 | <kuribas> | right :) |
2023-03-09 16:54:07 +0100 | <int-e> | Section 4, "Linear Resource Usage Protocols" |
2023-03-09 16:55:28 +0100 | <kuribas> | int-e: that example already looks broken, since I can do newArray 2 id |
2023-03-09 16:55:46 +0100 | Lycurgus | (~juan@user/Lycurgus) |
2023-03-09 16:55:53 +0100 | <int-e> | no you can't? a isn't linear. |
2023-03-09 16:57:04 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 276 seconds) |
2023-03-09 16:57:37 +0100 | <int-e> | Or maybe not, but then you can't use the result more than once. |
2023-03-09 16:57:57 +0100 | <kuribas> | sure I can |
2023-03-09 16:58:02 +0100 | <kuribas> | it doesn't say a has to be linear |
2023-03-09 16:58:32 +0100 | <kuribas> | So if I set a == Array t, it will happily return the array |
2023-03-09 16:58:55 +0100 | <kuribas> | well "\x => x" is linear. |
2023-03-09 17:00:07 +0100 | <int-e> | That make no sense. |
2023-03-09 17:01:02 +0100 | <int-e> | You're saying that you can write id : (1 x : a) -> a; id x = x, and then you can use the result of `id x` arbitrarily often? |
2023-03-09 17:04:56 +0100 | cheater | (~Username@user/cheater) |
2023-03-09 17:11:41 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) |
2023-03-09 17:15:16 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt: personae.ai-integration.biz) |
2023-03-09 17:15:53 +0100 | YoungFrog | (~youngfrog@2a02:a03f:ca07:f900:9c2d:58ba:f0b6:128f) (Quit: ZNC 1.7.x-git-3-96481995 - https://znc.in) |
2023-03-09 17:16:13 +0100 | YoungFrog | (~youngfrog@2a02:a03f:ca07:f900:9c2d:58ba:f0b6:128f) |
2023-03-09 17:21:50 +0100 | razetime | (~Thunderbi@117.193.7.18) |
2023-03-09 17:31:06 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
2023-03-09 17:31:47 +0100 | Alex_test | (~al_test@178.34.160.55) (Ping timeout: 265 seconds) |
2023-03-09 17:32:45 +0100 | AlexZenon | (~alzenon@178.34.160.55) (Ping timeout: 265 seconds) |
2023-03-09 17:32:46 +0100 | mbuf | (~Shakthi@49.207.178.186) (Quit: Leaving) |
2023-03-09 17:34:03 +0100 | chomwitt | (~chomwitt@2a02:587:7a18:6d00:1ac0:4dff:fedb:a3f1) |
2023-03-09 17:35:35 +0100 | Alex_test | (~al_test@178.34.160.55) |
2023-03-09 17:36:38 +0100 | AlexZenon | (~alzenon@178.34.160.55) |
2023-03-09 17:37:14 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
2023-03-09 17:39:35 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
2023-03-09 17:40:59 +0100 | chomwitt | (~chomwitt@2a02:587:7a18:6d00:1ac0:4dff:fedb:a3f1) (Ping timeout: 264 seconds) |
2023-03-09 17:43:14 +0100 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
2023-03-09 17:43:30 +0100 | <segfaultfizzbuzz> | from reddit: "the Haskely way" (really the functional way) is to make/extend an algebra of basic program elements and construct your program from it 🤯 |
2023-03-09 17:45:59 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) (Remote host closed the connection) |
2023-03-09 17:46:19 +0100 | <segfaultfizzbuzz> | algebra of program elements!! |
2023-03-09 17:47:30 +0100 | mastarija | (~mastarija@188.252.198.83) (Quit: WeeChat 3.7.1) |
2023-03-09 17:47:52 +0100 | acidjnk | (~acidjnk@p200300d6e715c453bc1e3b7a524e041a.dip0.t-ipconnect.de) |
2023-03-09 17:48:02 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
2023-03-09 17:48:58 +0100 | <c_wraith> | sure |
2023-03-09 17:50:07 +0100 | <c_wraith> | that's at least a common way of performing abstraction in Haskell. |
2023-03-09 17:50:49 +0100 | <segfaultfizzbuzz> | i know what algebraic structures are like groups and rings but "an algebra", i'm not aware of a formalization of what that means |
2023-03-09 17:50:51 +0100 | <c_wraith> | The algebra functions as primitives in your problem domain |
2023-03-09 17:51:03 +0100 | <monochrom> | s/the/a/ |
2023-03-09 17:51:04 +0100 | <segfaultfizzbuzz> | am i exposing whether my functions are associative, commute, etc? |
2023-03-09 17:51:35 +0100 | <c_wraith> | monochrom: eh, viewpoint. "the algebra you've created" vs "an algebra you can create" |
2023-03-09 17:51:51 +0100 | <monochrom> | No no no, s/the Haskely way/a Haskely way/ |
2023-03-09 17:51:55 +0100 | <c_wraith> | ah, yes. |
2023-03-09 17:52:00 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
2023-03-09 17:52:01 +0100 | <c_wraith> | It's an option. |
2023-03-09 17:52:10 +0100 | <c_wraith> | Successful programs have done other things |
2023-03-09 17:52:57 +0100 | <segfaultfizzbuzz> | i'm not seeing the relationship between defining the functions for my program and an algebra at the moment |
2023-03-09 17:53:05 +0100 | <c_wraith> | segfaultfizzbuzz: https://www.schoolofhaskell.com/user/tel/algebras-coalgebras |
2023-03-09 17:53:35 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
2023-03-09 17:54:04 +0100 | <segfaultfizzbuzz> | ah so algebra here is a jargon word and doesn't refer to the general meaning of the term? |
2023-03-09 17:54:25 +0100 | <c_wraith> | it refers to a common mathematical meaning of the term in branches of math you aren't yet familiar with :) |
2023-03-09 17:55:19 +0100 | <segfaultfizzbuzz> | "yet" sounds optimistic here but i suppose thanks for the flattery |
2023-03-09 17:55:37 +0100 | <monochrom> | And I wonder if "make an algebra" is tautological. |
2023-03-09 17:55:52 +0100 | <c_wraith> | That's less flattery and more an acknowledgement that if you want to, you can learn the stuff |
2023-03-09 17:56:42 +0100 | <segfaultfizzbuzz> | so a type and a function which is a functor is considered an algebra? |
2023-03-09 17:58:43 +0100 | <c_wraith> | It's a bit more specific than that, but that page isn't especially precise. |
2023-03-09 17:59:19 +0100 | <segfaultfizzbuzz> | how do folks deal with "definition spam": |
2023-03-09 18:00:12 +0100 | <segfaultfizzbuzz> | it feels like there is an unending torrent of definitions and properties and things |
2023-03-09 18:00:13 +0100 | phma_ | (~phma@host-67-44-208-201.hnremote.net) |
2023-03-09 18:00:27 +0100 | CiaoSen | (~Jura@p200300c9570e91002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
2023-03-09 18:00:44 +0100 | <c_wraith> | that's because there is. Things will always be defined! |
2023-03-09 18:01:32 +0100 | <c_wraith> | I don't really worry about it. If there are definitions in an area I'm interested in, I'll pick them up to keep up with what's going on. Otherwise, I leave them in peace. |
2023-03-09 18:01:56 +0100 | <segfaultfizzbuzz> | are you constantly confronting new definitions and terms and soforth? |
2023-03-09 18:01:57 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) |
2023-03-09 18:02:08 +0100 | <c_wraith> | sure |
2023-03-09 18:02:18 +0100 | <segfaultfizzbuzz> | and then if you use a library or other thing, there will be things the author decided to use,... |
2023-03-09 18:02:36 +0100 | <segfaultfizzbuzz> | so it's like, the code i write feels like it will be "perpetually un-grounded"--which is to say, i can't really know what it stands on |
2023-03-09 18:02:59 +0100 | coot | (~coot@213.134.171.3) (Quit: coot) |
2023-03-09 18:03:28 +0100 | phma | (~phma@2001:5b0:210f:6d68:df04:da38:ad7:41b3) (Ping timeout: 248 seconds) |
2023-03-09 18:03:51 +0100 | <geekosaur> | always true |
2023-03-09 18:04:02 +0100 | <c_wraith> | I'm perfectly willing to outsource grounding to library authors I trust. |
2023-03-09 18:04:09 +0100 | <segfaultfizzbuzz> | so that's just how it is |
2023-03-09 18:04:28 +0100 | <geekosaur> | now think about how this affects cpan, npm, etc. |
2023-03-09 18:04:31 +0100 | <c_wraith> | Do I have any clue what a Kan extension is? Nope. But Edward Kmett wrote the library, so I know it's based on solid stuff. |
2023-03-09 18:04:45 +0100 | <c_wraith> | So I use the stuff in there if it solves my problems, and don't worry about it |
2023-03-09 18:05:17 +0100 | <segfaultfizzbuzz> | i also run into failures,... like i tried to use a stream in haskell once to do a simple computation on some data streamed over http and it was a disaster |
2023-03-09 18:05:49 +0100 | <segfaultfizzbuzz> | the types wouldn't fit together even though conceptually what i was doing was no more complicated than summing certain items from the stream |
2023-03-09 18:06:22 +0100 | <segfaultfizzbuzz> | c_wraith: yeah that's a great example, kan extension, yoneda lemma, etc |
2023-03-09 18:06:37 +0100 | vglfr | (~vglfr@209.198.138.7) (Ping timeout: 276 seconds) |
2023-03-09 18:07:35 +0100 | <segfaultfizzbuzz> | and haskell is math, except it is not math, except it is math, except it is not... lol |
2023-03-09 18:08:13 +0100 | <segfaultfizzbuzz> | that is to say, i look up kan extension and i see adjoint functor,... so this term will be relevant to haskell, except it won't be, except it will be, except it won't |
2023-03-09 18:08:37 +0100 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 3.8) |
2023-03-09 18:09:13 +0100 | <geekosaur> | there are a lot of kinds of math |
2023-03-09 18:09:25 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
2023-03-09 18:09:27 +0100 | kenran | (~user@user/kenran) (Remote host closed the connection) |
2023-03-09 18:09:40 +0100 | <geekosaur> | you won't find many quaternions in haskell. you won't find much related to homotopy, in general |
2023-03-09 18:10:06 +0100 | <geekosaur> | (now watch someone mention HoTT) |
2023-03-09 18:11:10 +0100 | <kuribas> | int-e: of course. "id : (1 x : a) -> a", only means that id can use x once. |
2023-03-09 18:11:14 +0100 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) |
2023-03-09 18:11:18 +0100 | motherfsck | (~motherfsc@user/motherfsck) |
2023-03-09 18:11:22 +0100 | <kuribas> | int-e: it doesn't say anything about other functions. |
2023-03-09 18:11:49 +0100 | <kuribas> | int-e: in particular, it doesn't mean that the passed object is unique. |
2023-03-09 18:11:52 +0100 | razetime | (~Thunderbi@117.193.7.18) (Quit: See You Space Cowboy) |
2023-03-09 18:11:58 +0100 | <kuribas> | int-e: or that the returned object can be used only once. |
2023-03-09 18:13:37 +0100 | phma_ | phma |
2023-03-09 18:14:38 +0100 | <c_wraith> | segfaultfizzbuzz: You can learn a lot of just Haskell-as-Haskell. parametric polymorphism means types can say a *lot* about what's going on, and you can learn to work with that. So I don't care so much what math a library was derived from. That math might explain why the ideas were being studied in the first place, but it doesn't explain why I'd care about it as Haskell code. Instead, the types explain that, and I don't need to learn more than Haskell to |
2023-03-09 18:14:38 +0100 | <c_wraith> | read them. |
2023-03-09 18:16:27 +0100 | xff0x | (~xff0x@2405:6580:b080:900:a142:fa3c:5d94:d75c) (Ping timeout: 248 seconds) |
2023-03-09 18:17:30 +0100 | <segfaultfizzbuzz> | i should shut up and finish writing tic tac toe lol, perhaps "shut up and code" is the right motto |
2023-03-09 18:18:15 +0100 | <mauke> | *looks at lens types* *head explodes* |
2023-03-09 18:18:22 +0100 | xff0x | (~xff0x@ai098135.d.east.v6connect.net) |
2023-03-09 18:18:44 +0100 | <c_wraith> | lens types are fine when you remove all the type aliases |
2023-03-09 18:18:56 +0100 | <segfaultfizzbuzz> | i was a little sad that i apparently couldn't expose the lattice structure of my tic tac toe board to haskell |
2023-03-09 18:19:19 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 268 seconds) |
2023-03-09 18:21:05 +0100 | <c_wraith> | Well. The basic lens types. on the other hand, there is stuff like |
2023-03-09 18:21:08 +0100 | <c_wraith> | :t confusing |
2023-03-09 18:21:09 +0100 | <lambdabot> | Applicative f => LensLike (Data.Functor.Day.Curried.Curried (Data.Functor.Yoneda.Yoneda f) (Data.Functor.Yoneda.Yoneda f)) s t a b -> LensLike f s t a b |
2023-03-09 18:21:50 +0100 | econo | (uid147250@user/econo) |
2023-03-09 18:24:44 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) (Remote host closed the connection) |
2023-03-09 18:25:07 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
2023-03-09 18:26:10 +0100 | gmg | (~user@user/gehmehgeh) |
2023-03-09 18:27:02 +0100 | cheater | (~Username@user/cheater) |
2023-03-09 18:27:59 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 248 seconds) |
2023-03-09 18:28:11 +0100 | polyphem_ | (~rod@2a02:810d:840:8754:8192:31bf:f6c3:eb7e) (Ping timeout: 248 seconds) |
2023-03-09 18:28:57 +0100 | polyphem_ | (~rod@2a02:810d:840:8754:224e:f6ff:fe5e:bc17) |
2023-03-09 18:32:16 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 248 seconds) |
2023-03-09 18:32:25 +0100 | cheater | (~Username@user/cheater) |
2023-03-09 18:35:06 +0100 | ddellacosta | (~ddellacos@146.70.166.10) (Quit: WeeChat 3.8) |
2023-03-09 18:36:05 +0100 | ddellacosta | (~ddellacos@146.70.166.10) |
2023-03-09 18:36:05 +0100 | <int-e> | kuribas: I'm pretty sure that that's wrong; the multiplicity at which you can use the result of an application `f x` where f : (1 x: _) -> _ is governed by how many `x` you have in McBride's "Plenty O' Nuttin'" paper, so the same should be true for Atkey's QTT. Though in the copy of that paper, the `APP` rule has a very confusing, mostly unrestricted, sigma' that I feel is wrong... but the... |
2023-03-09 18:36:11 +0100 | <int-e> | ...conclusion is the same for the {0,1,omega} ring with 0,1 < omega weakening, which I think is what Idris uses. |
2023-03-09 18:36:12 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 255 seconds) |
2023-03-09 18:36:42 +0100 | raym | (~ray@user/raym) (Quit: kernel update, rebooting...) |
2023-03-09 18:36:59 +0100 | mechap | (~mechap@user/mechap) |
2023-03-09 18:38:54 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
2023-03-09 18:39:43 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1)) |
2023-03-09 18:40:24 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
2023-03-09 18:43:01 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2023-03-09 18:45:19 +0100 | <EvanR> | geekosaur, yeah because quaternions are not as convenient as rotation matrices! |
2023-03-09 18:45:52 +0100 | MajorBiscuit | (~MajorBisc@c-001-001-058.client.tudelft.eduvpn.nl) (Quit: WeeChat 3.6) |
2023-03-09 18:46:26 +0100 | <segfaultfizzbuzz> | lol rust: "ampersand-driven development" |
2023-03-09 18:47:48 +0100 | <segfaultfizzbuzz> | i'm sure people have implemented quaternions in haskell, ... but as far as i know i can't expose algebraic characteristics of functions to the haskell compiler? like, if i was to define a quaternion type, can i tell haskell that addition of quaternions is associative? |
2023-03-09 18:48:18 +0100 | <segfaultfizzbuzz> | the significance there being that haskell might be able to use that information to optimize things or produce errors |
2023-03-09 18:49:40 +0100 | <geekosaur> | you can't even tell it that + on integers is associative |
2023-03-09 18:50:04 +0100 | <geekosaur> | but iirc you don't actually get much from that in languages that do support it |
2023-03-09 18:50:31 +0100 | <geekosaur> | in the end, it has to pick an ordering (ASTs are trees, not sets) |
2023-03-09 18:50:37 +0100 | <segfaultfizzbuzz> | if i tell a language that addition is associative, programming languages won't make use of that information? |
2023-03-09 18:50:43 +0100 | <segfaultfizzbuzz> | that's... bizarre |
2023-03-09 18:50:58 +0100 | <int-e> | @check \a b c -> (a + b) + c == a + (b + c :: Double) |
2023-03-09 18:51:01 +0100 | <lambdabot> | *** Failed! Falsifiable (after 4 tests and 4 shrinks): |
2023-03-09 18:51:01 +0100 | <lambdabot> | -0.11668115919024846 1.452549394947626 -0.4297849906259958 |
2023-03-09 18:51:02 +0100 | <geekosaur> | and CPUs aren't set-bvased either |
2023-03-09 18:51:15 +0100 | <segfaultfizzbuzz> | geekosaur: whaaat, what does that mean |
2023-03-09 18:51:35 +0100 | <geekosaur> | when it comes down to it, it has to use an order |
2023-03-09 18:52:00 +0100 | <segfaultfizzbuzz> | @check \a b c -> (a*b)*c == a*(b*c :: Double) |
2023-03-09 18:52:01 +0100 | <geekosaur> | but it doesn't really matter which one it uses even before it gets down to coding an ADD |
2023-03-09 18:52:02 +0100 | <lambdabot> | *** Failed! Falsifiable (after 2 tests and 7 shrinks): |
2023-03-09 18:52:02 +0100 | <lambdabot> | -0.5208854264318805 -0.9738615249555872 -0.9289882691469215 |
2023-03-09 18:52:36 +0100 | <segfaultfizzbuzz> | wao |
2023-03-09 18:53:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2023-03-09 18:53:20 +0100 | <geekosaur> | think about it. it still has to force both parameters to + before it can add them; it doesn't really matter what order it does them in unless there's a cycle, but it'll fail in that case anyway |
2023-03-09 18:55:13 +0100 | <geekosaur> | even if `a` depends on `b` in `a + b`, in Haskell that just means one evaluation will already have been completed/reduced depending on the order it chooses |
2023-03-09 18:55:48 +0100 | <geekosaur> | so in the end knowing about associativity gains you nothing |
2023-03-09 18:58:38 +0100 | <mauke> | that's not quite true in general. associativity can open up optimization avenues |
2023-03-09 18:59:16 +0100 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 276 seconds) |
2023-03-09 18:59:35 +0100 | <geekosaur> | we lost them anyway |
2023-03-09 19:00:13 +0100 | <mauke> | consider the following C code: unsigned fac(unsigned n) { if (n == 0) return 1; return n * fac(n - 1); } |
2023-03-09 19:00:30 +0100 | <[Leary]> | It's the associativity of `<>` that makes all of `Foldable` well-defined. It also means you can break operations into the most suitable tree structure for, e.g. parallel evaluation. |
2023-03-09 19:00:37 +0100 | <int-e> | "we" probably use associativity liberally when auto-vectorizing code. |
2023-03-09 19:01:07 +0100 | <int-e> | though that won't carry over to custom types anyway |
2023-03-09 19:01:09 +0100 | <EvanR> | algebraic laws are cool, but I would not expect it to matter to quaternions directly because floats |
2023-03-09 19:01:38 +0100 | <EvanR> | associativity is morally true and immorally false |
2023-03-09 19:02:55 +0100 | <mauke> | if * is associative, then we can rewrite as: unsigned fac(unsigned n) { return fac_a(n, 1); } unsigned fac_a(unsigned n, unsigned a) { if (n == 0) return a; return fac_a(n - 1, a * n); } |
2023-03-09 19:03:28 +0100 | <mauke> | the latter is tail recursive and can be compiled to a straight loop, saving O(n) stack space |
2023-03-09 19:03:56 +0100 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
2023-03-09 19:04:05 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
2023-03-09 19:05:23 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
2023-03-09 19:05:46 +0100 | <int-e> | replacing foldr by foldl' |
2023-03-09 19:06:25 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 276 seconds) |
2023-03-09 19:06:55 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
2023-03-09 19:07:24 +0100 | <mauke> | (gcc actually does this) |
2023-03-09 19:08:32 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 248 seconds) |
2023-03-09 19:09:48 +0100 | raym | (~ray@user/raym) |
2023-03-09 19:09:55 +0100 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) (Read error: Connection reset by peer) |
2023-03-09 19:10:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2023-03-09 19:10:15 +0100 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) |
2023-03-09 19:11:22 +0100 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) (Client Quit) |
2023-03-09 19:12:14 +0100 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) |
2023-03-09 19:21:02 +0100 | cheater | (~Username@user/cheater) |
2023-03-09 19:23:27 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
2023-03-09 19:24:04 +0100 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) (Ping timeout: 268 seconds) |
2023-03-09 19:25:13 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) |
2023-03-09 19:25:59 +0100 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) |
2023-03-09 19:26:00 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2023-03-09 19:29:39 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) (Ping timeout: 255 seconds) |
2023-03-09 19:31:33 +0100 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 255 seconds) |
2023-03-09 19:36:11 +0100 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
2023-03-09 19:36:17 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) |
2023-03-09 19:42:01 +0100 | <hololeap> | I think it's time for me to attempt making a mandelbrot explorer, but I have no idea what graphics-related packages would be good for that |
2023-03-09 19:42:47 +0100 | <hololeap> | I have done no user interface stuff in haskell outside of CLI and brick |
2023-03-09 19:42:57 +0100 | <EvanR> | to just show images you could use SDL |
2023-03-09 19:43:24 +0100 | <EvanR> | control it via IPC from a CLI app xD |
2023-03-09 19:43:33 +0100 | <sm> | terminal! https://github.com/haskell-game/tiny-games-hs/tree/main/prelude/tiny-brot#readme |
2023-03-09 19:43:38 +0100 | <hololeap> | lol, but I want knobs |
2023-03-09 19:43:49 +0100 | <EvanR> | RIP |
2023-03-09 19:44:34 +0100 | <sm> | some folks have been making little knobs-uis with dear-imlib |
2023-03-09 19:45:05 +0100 | <sm> | https://hackage.haskell.org/package/dear-imgui I guess. There's also https://hackage.haskell.org/package/raylib-imgui |
2023-03-09 19:45:44 +0100 | <sm> | https://hackage.haskell.org/package/monomer and https://hackage.haskell.org/package/fltkhs are also widget-ful |
2023-03-09 19:46:15 +0100 | <sm> | and https://hackage.haskell.org/package/h-raylib seems the newest |
2023-03-09 19:46:37 +0100 | <hololeap> | neat, I'll take a look |
2023-03-09 19:46:43 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.8) |
2023-03-09 19:48:07 +0100 | pwntips | (~user@24-113-98-114.wavecable.com) (Ping timeout: 268 seconds) |
2023-03-09 19:49:51 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
2023-03-09 19:58:16 +0100 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
2023-03-09 19:59:28 +0100 | <carter> | Question: is HasCallStack => the simplest way to add source location data to an API currently? |
2023-03-09 20:01:20 +0100 | <geekosaur> | simplest but second most expensive after compiling with profiling |
2023-03-09 20:05:34 +0100 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 276 seconds) |
2023-03-09 20:06:58 +0100 | Ashkan | (~Ashkan@a119011.upc-a.chello.nl) |
2023-03-09 20:08:01 +0100 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
2023-03-09 20:09:01 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) (Remote host closed the connection) |
2023-03-09 20:10:03 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 248 seconds) |
2023-03-09 20:15:22 +0100 | ft | (~ft@p3e9bc443.dip0.t-ipconnect.de) |
2023-03-09 20:16:39 +0100 | cheater_ | (~Username@user/cheater) |
2023-03-09 20:20:17 +0100 | <sm> | did I see something in ghc 9.6 release notes about dual building for profiling being no longer necessary ? or less building required ? |
2023-03-09 20:20:31 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 276 seconds) |
2023-03-09 20:20:36 +0100 | cheater_ | cheater |
2023-03-09 20:21:56 +0100 | <sm> | hmm no |
2023-03-09 20:22:33 +0100 | <geekosaur> | are you thinking of -prof-late? |
2023-03-09 20:22:57 +0100 | <geekosaur> | which makes profiling builds almost as fast as normal ones iirc |
2023-03-09 20:24:44 +0100 | <sm> | no it was something else maybe to do with adding more info to .hi files allowing GHC to make compilation decisions later/more locally |
2023-03-09 20:25:02 +0100 | <sm> | but -prof-late sounds great too |
2023-03-09 20:25:42 +0100 | Fischmiep | (~Fischmiep@user/Fischmiep) (Quit: Ping timeout (120 seconds)) |
2023-03-09 20:26:02 +0100 | Fischmiep | (~Fischmiep@user/Fischmiep) |
2023-03-09 20:31:55 +0100 | ph88 | (~ph88@ip5b426553.dynamic.kabel-deutschland.de) |
2023-03-09 20:32:07 +0100 | dsrt^ | (~dsrt@c-24-30-76-89.hsd1.ga.comcast.net) |
2023-03-09 20:33:18 +0100 | kilolympus | (~kilolympu@213.144.144.24) |
2023-03-09 20:40:35 +0100 | <monochrom> | -prof-late sounds like it solves the problem I observed where turning on profiling changes a O(1)-space program to Ω(n)-space. |
2023-03-09 20:40:57 +0100 | MacSlow | (~MacSlow@p57bb2fc5.dip0.t-ipconnect.de) (Quit: leaving) |
2023-03-09 20:44:34 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 276 seconds) |
2023-03-09 20:45:46 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
2023-03-09 20:45:50 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) |
2023-03-09 20:49:20 +0100 | <segfaultfizzbuzz> | wait a sec, does lazy evaluation mean that you can do less/very little/nothing with the knowledge that an operation is associative? because you need to evaluate each node... |
2023-03-09 20:49:52 +0100 | <segfaultfizzbuzz> | EvanR: you could define quaternions over rationals, over integers, etc |
2023-03-09 20:50:25 +0100 | <EvanR> | :thonk: |
2023-03-09 20:50:39 +0100 | <EvanR> | the formulas for converting quaternions involves trig |
2023-03-09 20:51:16 +0100 | <EvanR> | so maybe it works in isolation but uselessly for computer graphics |
2023-03-09 20:52:02 +0100 | <segfaultfizzbuzz> | yeah it would be a "mathematical curiousity" as far as i know |
2023-03-09 20:53:09 +0100 | <EvanR> | associativity is very useful for converting folds from one direction to another which has a more efficient evaluation strategy |
2023-03-09 20:53:25 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
2023-03-09 20:54:42 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
2023-03-09 20:56:16 +0100 | <EvanR> | to state the opposite of what you might have missed above, maybe you want to convert a foldl into a foldr which could be properly lazy |
2023-03-09 20:58:35 +0100 | <dsal> | foldl is a left fold and foldr is a right fold, but I generally prefer fold which is straightforward. |
2023-03-09 20:59:12 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) |
2023-03-09 20:59:51 +0100 | <EvanR> | lol |
2023-03-09 21:00:12 +0100 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 255 seconds) |
2023-03-09 21:01:50 +0100 | kuribas | (~user@ptr-17d51epmwvuiuir3x67.18120a2.ip6.access.telenet.be) |
2023-03-09 21:06:16 +0100 | <kuribas> | int-e: Linear.Array is just completely broken https://gist.github.com/kuribas/3539cd48795232553061571f6b7a64c1 |
2023-03-09 21:06:26 +0100 | <kuribas> | It allows me to duplicate an array, and also to write twice to it. |
2023-03-09 21:09:10 +0100 | <monochrom> | Lazy evaluation does not know about associativity. |
2023-03-09 21:11:04 +0100 | <monochrom> | Some humans and some code optimizers exploit some associativity. But then neither are related to lazy evaluation. |
2023-03-09 21:11:26 +0100 | <kuribas> | int-e: well the second does fail when I make the input linear. |
2023-03-09 21:12:31 +0100 | <monochrom> | For example I bet C compilers know to simplify "x = 3 * y * 4" to "x = 12 * y" (and furthermore use a bitwise trick to avoid real multiplication). |
2023-03-09 21:12:37 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
2023-03-09 21:13:38 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
2023-03-09 21:14:44 +0100 | <mauke> | (y << 3) + (y << 2)? |
2023-03-09 21:14:45 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
2023-03-09 21:18:48 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
2023-03-09 21:19:55 +0100 | shriekingnoise | (~shrieking@186.137.175.87) (Ping timeout: 248 seconds) |
2023-03-09 21:22:10 +0100 | cheater | (~Username@user/cheater) |
2023-03-09 21:22:40 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
2023-03-09 21:24:22 +0100 | cheater_ | (~Username@user/cheater) |
2023-03-09 21:24:40 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
2023-03-09 21:24:47 +0100 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 256 seconds) |
2023-03-09 21:25:10 +0100 | <kuribas> | int-e: it looks fine when I apply the Ur trick from the issue comments. |
2023-03-09 21:25:13 +0100 | shriekingnoise | (~shrieking@186.137.175.87) |
2023-03-09 21:25:45 +0100 | pavonia | (~user@user/siracusa) |
2023-03-09 21:27:27 +0100 | <kuribas> | if it's an Int |
2023-03-09 21:27:28 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 276 seconds) |
2023-03-09 21:27:28 +0100 | cheater_ | cheater |
2023-03-09 21:27:38 +0100 | <kuribas> | if it's double, or polymorphic, those laws don't even hold. |
2023-03-09 21:34:06 +0100 | hugo | (znc@verdigris.lysator.liu.se) |
2023-03-09 21:38:43 +0100 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:4147:a345:6569:5bc8) (Quit: caryhartline) |
2023-03-09 21:39:00 +0100 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
2023-03-09 21:39:04 +0100 | <segfaultfizzbuzz> | EvanR: i always check the logs, it would be rude to start a conversation and not read what people say |
2023-03-09 21:39:39 +0100 | <EvanR> | consulting the panopticon |
2023-03-09 21:39:48 +0100 | <segfaultfizzbuzz> | haha yeah |
2023-03-09 21:45:53 +0100 | Joao003 | (~Joao003@2804:840:8310:4e00:483b:dfbc:6ebe:6566) |
2023-03-09 21:47:13 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) (Remote host closed the connection) |
2023-03-09 21:48:34 +0100 | zeenk | (~zeenk@2a02:2f04:a20d:f900::fba) (Quit: Konversation terminated!) |
2023-03-09 21:49:34 +0100 | kuribas | (~user@ptr-17d51epmwvuiuir3x67.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 27.1)) |
2023-03-09 21:51:18 +0100 | Ashkan | (~Ashkan@a119011.upc-a.chello.nl) (Quit: Client closed) |
2023-03-09 21:54:31 +0100 | pwntips | (~user@24-113-98-114.wavecable.com) |
2023-03-09 21:55:28 +0100 | alphabeta | (~kilolympu@vpn-fn-229.net.ed.ac.uk) |
2023-03-09 21:56:04 +0100 | kilolympus | (~kilolympu@213.144.144.24) (Ping timeout: 276 seconds) |
2023-03-09 21:57:19 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
2023-03-09 22:04:37 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
2023-03-09 22:05:48 +0100 | npmania | (~Thunderbi@91.193.7.59) (Quit: npmania) |
2023-03-09 22:06:47 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
2023-03-09 22:13:57 +0100 | lyle | (~lyle@104.246.145.237) (Quit: WeeChat 3.8) |
2023-03-09 22:18:48 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
2023-03-09 22:19:25 +0100 | alphabeta | (~kilolympu@vpn-fn-229.net.ed.ac.uk) (Read error: Connection reset by peer) |
2023-03-09 22:21:47 +0100 | acidjnk | (~acidjnk@p200300d6e715c453bc1e3b7a524e041a.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
2023-03-09 22:21:54 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
2023-03-09 22:28:16 +0100 | acidjnk | (~acidjnk@p200300d6e715c453a916ccc9b0d1ef20.dip0.t-ipconnect.de) |
2023-03-09 22:29:59 +0100 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
2023-03-09 22:31:29 +0100 | acidjnk_new | (~acidjnk@p200300d6e715c45369d03de84b7702ea.dip0.t-ipconnect.de) |
2023-03-09 22:35:39 +0100 | acidjnk | (~acidjnk@p200300d6e715c453a916ccc9b0d1ef20.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
2023-03-09 22:37:53 +0100 | michalz | (~michalz@185.246.204.125) (Remote host closed the connection) |
2023-03-09 22:39:39 +0100 | AlexZenon | (~alzenon@178.34.160.55) (Ping timeout: 255 seconds) |
2023-03-09 22:40:45 +0100 | Joao003 | (~Joao003@2804:840:8310:4e00:483b:dfbc:6ebe:6566) (Quit: Leaving) |
2023-03-09 22:42:01 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
2023-03-09 22:43:07 +0100 | Alex_test | (~al_test@178.34.160.55) (Ping timeout: 248 seconds) |
2023-03-09 22:46:03 +0100 | Alex_test | (~al_test@178.34.160.55) |
2023-03-09 22:46:42 +0100 | caryhartline | (~caryhartl@2603-8080-6c00-6c01-2dd0-c76a-1d13-9758.res6.spectrum.com) |
2023-03-09 22:47:44 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) |
2023-03-09 22:48:59 +0100 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 248 seconds) |
2023-03-09 22:51:07 +0100 | infinity0 | (~infinity0@pwned.gg) (Remote host closed the connection) |
2023-03-09 22:51:10 +0100 | AlexZenon | (~alzenon@178.34.160.55) |
2023-03-09 22:51:26 +0100 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) |
2023-03-09 22:51:42 +0100 | trev | (~trev@user/trev) (Remote host closed the connection) |
2023-03-09 22:52:08 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:182e:ca34:e210:1559) (Ping timeout: 255 seconds) |
2023-03-09 22:53:14 +0100 | infinity0 | (~infinity0@pwned.gg) |
2023-03-09 23:07:24 +0100 | <DavidDenoncin[m]> | Hi! Can anyone tell me the name of a proper package to compute a median? Is median-stream the one to go with? |
2023-03-09 23:10:56 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
2023-03-09 23:18:47 +0100 | <sclv> | DavidDenoncin[m]: depends on what you want to do -- median over a small list, a big list, ongoing median over a stream, etc? |
2023-03-09 23:19:11 +0100 | <sclv> | the `statistics` package is good for a high quality and high perf implementations of lots of fancier stuff |
2023-03-09 23:20:26 +0100 | <sclv> | for a small-medium list, just like doing the obvious one-liner is good enough, unless one is worried about numeric stability issues |
2023-03-09 23:21:05 +0100 | tsmc[m] | (~tsmcmatri@2001:470:69fc:105::1:7e1) |
2023-03-09 23:22:53 +0100 | zeenk | (~zeenk@2a02:2f04:a20d:f900::fba) |
2023-03-09 23:24:43 +0100 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 248 seconds) |
2023-03-09 23:25:38 +0100 | <DavidDenoncin[m]> | Well I'll apply it to small lists, I just don't want to have a to treat particularly that one case (I want to avoid recoding what I think should be there ^^). I saw mean and stdDev in the statistics package, but did not understand how to simply compute a median with this package |
2023-03-09 23:27:20 +0100 | <sclv> | ah i see the statistics median function is a quantile estimation, not a precise one https://hackage.haskell.org/package/statistics-0.16.1.2/docs/Statistics-Quantile.html#v:median |
2023-03-09 23:27:24 +0100 | <sclv> | too fancy :-P |
2023-03-09 23:28:32 +0100 | tmiller | (~tmiller@199.241.26.152) |
2023-03-09 23:28:44 +0100 | <mauke> | :t \xs -> sort xs !! (length xs `div` 2) |
2023-03-09 23:28:46 +0100 | <lambdabot> | Ord a => [a] -> a |
2023-03-09 23:28:52 +0100 | <sclv> | right, i guess everyone just does that :-P |
2023-03-09 23:29:19 +0100 | hugo | (znc@verdigris.lysator.liu.se) |
2023-03-09 23:29:25 +0100 | <mauke> | :t liftA2 (!!) sort (flip div 2 . length) |
2023-03-09 23:29:26 +0100 | <lambdabot> | Ord c => [c] -> c |
2023-03-09 23:29:28 +0100 | tmiller | (~tmiller@199.241.26.152) (Client Quit) |
2023-03-09 23:29:34 +0100 | <sclv> | i forgot about "sorting to avoid catastrophic cancellation" because i always use the knuth version |
2023-03-09 23:30:12 +0100 | <mauke> | what's cancellation? |
2023-03-09 23:30:23 +0100 | <sclv> | wait i'm high, i'm thinking about mean, nevermind! |
2023-03-09 23:30:55 +0100 | <mauke> | :t (!!) <$> sort <*> (flip div 2 <$> length) |
2023-03-09 23:30:56 +0100 | <lambdabot> | Ord b => [b] -> b |
2023-03-09 23:31:31 +0100 | NiceBird | (~NiceBird@185.133.111.196) (Quit: Leaving) |
2023-03-09 23:33:38 +0100 | <DavidDenoncin[m]> | I see. Either I'm going one liner (sort of only valid for odd length ;-) or fancy then ^^ |
2023-03-09 23:34:28 +0100 | <DavidDenoncin[m]> | s/;-/isn't it ?/ |
2023-03-09 23:36:06 +0100 | cheater_ | (~Username@user/cheater) |
2023-03-09 23:36:25 +0100 | <sclv> | i think last time it came up the "nicest" non-streaming precise fancy median algorithm was the one that could be derived from using vector-algorithm's select stuff in its heapsort https://hackage.haskell.org/package/vector-algorithms-0.9.0.1/docs/Data-Vector-Algorithms-Heap.html -- someone really should add a PR to have it directly there so people don't have to reinvent the wheel |
2023-03-09 23:37:22 +0100 | <sclv> | but yeah, just sort and index into the middle |
2023-03-09 23:38:10 +0100 | <DavidDenoncin[m]> | Allright, thanks! |
2023-03-09 23:38:35 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 248 seconds) |
2023-03-09 23:38:41 +0100 | cheater_ | cheater |
2023-03-09 23:39:07 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
2023-03-09 23:41:19 +0100 | Lycurgus | (~juan@user/Lycurgus) |
2023-03-09 23:58:29 +0100 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 268 seconds) |