2020-12-30 00:00:32 +0100 | <sshine> | aljce, I don't know accellerate, but it sounds like you want 'fmap Foo'? |
2020-12-30 00:00:44 +0100 | teardown_ | (~user@gateway/tor-sasl/mrush) |
2020-12-30 00:01:16 +0100 | mp___ | (~mp@hell.cx) (Ping timeout: 246 seconds) |
2020-12-30 00:01:47 +0100 | <sshine> | if 'Foo :: Word16 -> Foo', and Exp is a Functor, then 'fmap Foo :: Exp Word16 -> Exp Foo' |
2020-12-30 00:01:55 +0100 | Tario | (~Tario@200.119.186.210) (Ping timeout: 265 seconds) |
2020-12-30 00:02:02 +0100 | Tario | (~Tario@201.192.165.173) |
2020-12-30 00:02:06 +0100 | boxscape | (4ff0ba59@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.89) (Quit: Connection closed) |
2020-12-30 00:02:08 +0100 | <sshine> | sorry, accelerate. |
2020-12-30 00:02:33 +0100 | geowiesnot | (~user@87-89-181-157.abo.bbox.fr) |
2020-12-30 00:02:35 +0100 | <Melanie> | aljce: it looks like you want 'lift1 Foo' since I don't see a Functor instance for Exp |
2020-12-30 00:02:45 +0100 | <Melanie> | granted I don't know accelerate either |
2020-12-30 00:03:21 +0100 | <sshine> | I'm trying to compile the 'show-prettyprint' package against the latest Stackage. I'm getting a bunch of dependency problems related to trifecta-2.1. I can see on https://github.com/commercialhaskell/stackage/commit/f562e28566a8116a56310b24f415ece80249746e that some people have mitigated this by restricting themselves to trifecta < 2.1. but then I run into a bunch of upper bound constraints because the |
2020-12-30 00:03:27 +0100 | <sshine> | older versions are, well, old. |
2020-12-30 00:03:43 +0100 | teardown | (~user@gateway/tor-sasl/mrush) (Ping timeout: 240 seconds) |
2020-12-30 00:04:10 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
2020-12-30 00:08:42 +0100 | pera | (~pera@unaffiliated/pera) (Ping timeout: 272 seconds) |
2020-12-30 00:08:51 +0100 | perrier-jouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.0) |
2020-12-30 00:10:47 +0100 | pjb | (~t@2a01cb04063ec5009cc234517582f902.ipv6.abo.wanadoo.fr) (Read error: Connection reset by peer) |
2020-12-30 00:10:56 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 256 seconds) |
2020-12-30 00:14:50 +0100 | mputz | (~Thunderbi@dslb-088-064-063-125.088.064.pools.vodafone-ip.de) |
2020-12-30 00:16:41 +0100 | ransom | (~c4264035@2a09:bac0:72::82f:c34) (Read error: Connection reset by peer) |
2020-12-30 00:17:31 +0100 | ransom | (~c4264035@8.47.12.52) |
2020-12-30 00:18:54 +0100 | knupfer | (~Thunderbi@200116b82c7e8f00bd6d1b305dfa49c4.dip.versatel-1u1.de) (Quit: knupfer) |
2020-12-30 00:19:09 +0100 | knupfer | (~Thunderbi@200116b82c7e8f00084d19594ac0a1d9.dip.versatel-1u1.de) |
2020-12-30 00:21:44 +0100 | mputz | (~Thunderbi@dslb-088-064-063-125.088.064.pools.vodafone-ip.de) (Ping timeout: 265 seconds) |
2020-12-30 00:22:14 +0100 | yumh | (~yumh@mail.xglobe.in) (Quit: ZNC - https://znc.in) |
2020-12-30 00:25:07 +0100 | yumh | (~yumh@mail.xglobe.in) |
2020-12-30 00:25:42 +0100 | son0p | (~son0p@181.136.122.143) (Quit: Lost terminal) |
2020-12-30 00:26:01 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Remote host closed the connection) |
2020-12-30 00:26:07 +0100 | dfeuer | (~dfeuer@pool-108-18-223-60.washdc.fios.verizon.net) |
2020-12-30 00:26:12 +0100 | justanotheruser | (~justanoth@unaffiliated/justanotheruser) |
2020-12-30 00:26:38 +0100 | sand_dull | (~theuser@c-73-149-95-105.hsd1.ct.comcast.net) |
2020-12-30 00:26:47 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 00:28:42 +0100 | yumh | (~yumh@mail.xglobe.in) (Remote host closed the connection) |
2020-12-30 00:29:24 +0100 | <sshine> | if I don't 'allow-never: true', what is the shortest path forward for me? -- oh, this is funny. in my procrastination, I started looking at https://github.com/NorfairKing/sydtest/ and saw that it touted use of 'ppShow' which comes from 'pretty-show'. easy. :) |
2020-12-30 00:29:53 +0100 | lawid | (~quassel@dslb-178-005-075-009.178.005.pools.vodafone-ip.de) |
2020-12-30 00:31:32 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 260 seconds) |
2020-12-30 00:32:01 +0100 | sand_dull | (~theuser@c-73-149-95-105.hsd1.ct.comcast.net) (Ping timeout: 264 seconds) |
2020-12-30 00:33:23 +0100 | yumh | (~yumh@mail.xglobe.in) |
2020-12-30 00:33:58 +0100 | Rudd0 | (~Rudd0@185.189.115.103) (Remote host closed the connection) |
2020-12-30 00:35:36 +0100 | <sm[m]> | sshine: pretty-simple is also good |
2020-12-30 00:37:17 +0100 | <sshine> | sm[m], ah. it has better overlap with my existing dependencies. thanks. |
2020-12-30 00:38:31 +0100 | Tesseraction | (~Tesseract@unaffiliated/tesseraction) |
2020-12-30 00:46:17 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 00:47:49 +0100 | verement | (~anonymous@cpe-76-167-229-223.san.res.rr.com) (Quit: verement) |
2020-12-30 00:49:47 +0100 | yumh | (~yumh@mail.xglobe.in) (Quit: ZNC - https://znc.in) |
2020-12-30 00:49:47 +0100 | Gorbel | (~Gorbel@p5790e186.dip0.t-ipconnect.de) (Quit: Gorbel) |
2020-12-30 00:50:31 +0100 | yumh | (~yumh@mail.xglobe.in) |
2020-12-30 00:52:47 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 260 seconds) |
2020-12-30 00:52:56 +0100 | elfets | (~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) (Quit: Leaving) |
2020-12-30 00:54:09 +0100 | knupfer | (~Thunderbi@200116b82c7e8f00084d19594ac0a1d9.dip.versatel-1u1.de) (Ping timeout: 268 seconds) |
2020-12-30 00:54:32 +0100 | justanotheruser | (~justanoth@unaffiliated/justanotheruser) (Ping timeout: 260 seconds) |
2020-12-30 00:55:03 +0100 | mp___ | (~mp@hell.cx) |
2020-12-30 00:56:27 +0100 | yumh | (~yumh@mail.xglobe.in) (Quit: ZNC - https://znc.in) |
2020-12-30 01:01:19 +0100 | polyrain | (~polyrain@121.222.65.83) |
2020-12-30 01:08:30 +0100 | gzj | (~gzj@unaffiliated/gzj) |
2020-12-30 01:09:03 +0100 | o1lo01ol1o | (~o1lo01ol1@31.22.145.144) |
2020-12-30 01:09:42 +0100 | justanotheruser | (~justanoth@unaffiliated/justanotheruser) |
2020-12-30 01:13:16 +0100 | o1lo01ol1o | (~o1lo01ol1@31.22.145.144) (Ping timeout: 240 seconds) |
2020-12-30 01:15:57 +0100 | aveltras | (uid364989@gateway/web/irccloud.com/x-kccvjjqcpxkkewrw) (Quit: Connection closed for inactivity) |
2020-12-30 01:17:13 +0100 | star_cloud | (~star_clou@ec2-34-220-44-120.us-west-2.compute.amazonaws.com) (Ping timeout: 246 seconds) |
2020-12-30 01:18:10 +0100 | perrier-jouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
2020-12-30 01:18:22 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds) |
2020-12-30 01:19:37 +0100 | stef204 | (~stef204@unaffiliated/stef-204/x-384198) (Ping timeout: 260 seconds) |
2020-12-30 01:20:16 +0100 | <sshine> | hm, it defaults to Data.Text.Lazy; annoying. |
2020-12-30 01:22:38 +0100 | AndreasK | (uid320732@gateway/web/irccloud.com/x-hcwkkoekyeoydiqt) (Ping timeout: 265 seconds) |
2020-12-30 01:22:40 +0100 | alanz | (sid110616@gateway/web/irccloud.com/x-tooahcfpyawpixxr) (Read error: Connection reset by peer) |
2020-12-30 01:22:41 +0100 | ebutleriv | (sid217783@gateway/web/irccloud.com/x-vuvhvprvfualywxv) (Ping timeout: 272 seconds) |
2020-12-30 01:22:50 +0100 | alanz | (sid110616@gateway/web/irccloud.com/x-prwdeyzwdytgtxkp) |
2020-12-30 01:22:52 +0100 | wpcarro_ | (sid397589@gateway/web/irccloud.com/x-azkchtsfvqsclphx) (Ping timeout: 260 seconds) |
2020-12-30 01:23:19 +0100 | gOOgler | (uid125351@gateway/web/irccloud.com/x-wkvpcwzuhpoudvgh) (Ping timeout: 272 seconds) |
2020-12-30 01:23:41 +0100 | gOOgler | (uid125351@gateway/web/irccloud.com/x-jdvndeteehxffire) |
2020-12-30 01:23:52 +0100 | ebutleriv | (sid217783@gateway/web/irccloud.com/x-snsrtsqpsqwwbfgf) |
2020-12-30 01:24:02 +0100 | jyri-matti | (uid479350@gateway/web/irccloud.com/x-sahqhoxyiermzqtr) (Ping timeout: 260 seconds) |
2020-12-30 01:24:02 +0100 | nbloomf | (~nbloomf@2600:1700:ad14:3020:3cf1:586e:d728:faa3) |
2020-12-30 01:24:18 +0100 | eruditass | (uid248673@gateway/web/irccloud.com/x-glwlnislsolfajwk) (Ping timeout: 260 seconds) |
2020-12-30 01:24:51 +0100 | AndreasK | (uid320732@gateway/web/irccloud.com/x-vdseamlbfcbchsil) |
2020-12-30 01:24:59 +0100 | jyri-matti | (uid479350@gateway/web/irccloud.com/x-sdpspavvezzlrhxl) |
2020-12-30 01:25:34 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 01:25:42 +0100 | wpcarro_ | (sid397589@gateway/web/irccloud.com/x-cihesreymldlqpdf) |
2020-12-30 01:26:05 +0100 | eruditass | (uid248673@gateway/web/irccloud.com/x-qhjyzbcwmhhifert) |
2020-12-30 01:28:37 +0100 | usr25 | (~usr25@unaffiliated/usr25) |
2020-12-30 01:28:41 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Remote host closed the connection) |
2020-12-30 01:28:47 +0100 | Vulfe_ | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 01:28:52 +0100 | gehmehgeh | (~ircuser1@gateway/tor-sasl/gehmehgeh) (Quit: Leaving) |
2020-12-30 01:30:55 +0100 | da39a3ee5e6b4b0d | (~da39a3ee5@2403:6200:8876:f14e:750f:83e8:c56e:b09f) |
2020-12-30 01:38:58 +0100 | Kronic | (~Kronic___@84.203.96.46) |
2020-12-30 01:39:49 +0100 | geowiesnot | (~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 264 seconds) |
2020-12-30 01:44:16 +0100 | madjestic | (~Android@86-88-72-244.fixed.kpn.net) (Ping timeout: 256 seconds) |
2020-12-30 01:45:01 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 01:50:26 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds) |
2020-12-30 01:52:08 +0100 | Vulfe_ | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Remote host closed the connection) |
2020-12-30 02:00:55 +0100 | polyrain | (~polyrain@121.222.65.83) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 02:01:16 +0100 | mp___ | (~mp@hell.cx) (Ping timeout: 240 seconds) |
2020-12-30 02:04:08 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 02:05:09 +0100 | madjestic | (~Android@86-88-72-244.fixed.kpn.net) |
2020-12-30 02:05:44 +0100 | dfeuer | (~dfeuer@pool-108-18-223-60.washdc.fios.verizon.net) (Ping timeout: 260 seconds) |
2020-12-30 02:06:45 +0100 | Rudd0 | (~Rudd0@185.189.115.108) |
2020-12-30 02:07:43 +0100 | eacameron | (uid256985@gateway/web/irccloud.com/x-wupypehaymlqhtxd) (Quit: Connection closed for inactivity) |
2020-12-30 02:10:30 +0100 | cr3 | (~cr3@192-222-143-195.qc.cable.ebox.net) (Ping timeout: 256 seconds) |
2020-12-30 02:12:05 +0100 | justsomeguy | (~justsomeg@unaffiliated/--/x-3805311) () |
2020-12-30 02:16:32 +0100 | madjestic | (~Android@86-88-72-244.fixed.kpn.net) (Ping timeout: 260 seconds) |
2020-12-30 02:18:03 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) (Quit: Leaving.) |
2020-12-30 02:21:02 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 02:21:04 +0100 | Gurkenglas | (~Gurkengla@unaffiliated/gurkenglas) (Ping timeout: 272 seconds) |
2020-12-30 02:23:46 +0100 | <pie_> | so, I need to figure out how to pass arguments to the c++ compiler thats somehow called through the c compiler, thats called through ghc... |
2020-12-30 02:24:14 +0100 | <pie_> | the c++ compiler is somehow called through -xc++ |
2020-12-30 02:24:50 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) |
2020-12-30 02:25:28 +0100 | stef204 | (~stef204@unaffiliated/stef-204/x-384198) |
2020-12-30 02:25:49 +0100 | cr3 | (~cr3@192-222-143-195.qc.cable.ebox.net) |
2020-12-30 02:25:51 +0100 | mnrmnaugh | (~mnrmnaugh@unaffiliated/mnrmnaugh) |
2020-12-30 02:29:12 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) (Ping timeout: 256 seconds) |
2020-12-30 02:29:59 +0100 | <pie_> | f*** it, if nothing else works, strace |
2020-12-30 02:30:06 +0100 | gzj | (~gzj@unaffiliated/gzj) (Remote host closed the connection) |
2020-12-30 02:30:27 +0100 | gzj | (~gzj@unaffiliated/gzj) |
2020-12-30 02:30:35 +0100 | verement | (~anonymous@cpe-76-167-229-223.san.res.rr.com) |
2020-12-30 02:31:06 +0100 | Fischmie1 | (~Fischmiep@149.224.197.30) |
2020-12-30 02:31:17 +0100 | carthia | (~carthia@gateway/tor-sasl/carthia) (Remote host closed the connection) |
2020-12-30 02:31:57 +0100 | carthia | (~carthia@gateway/tor-sasl/carthia) |
2020-12-30 02:34:18 +0100 | Fischmiep | (~Fischmiep@46.59.219.2) (Ping timeout: 256 seconds) |
2020-12-30 02:37:29 +0100 | Feuermagier | (~Feuermagi@213.178.26.41) (Remote host closed the connection) |
2020-12-30 02:38:15 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Remote host closed the connection) |
2020-12-30 02:38:32 +0100 | mnrmnaugh | (~mnrmnaugh@unaffiliated/mnrmnaugh) (Quit: Leaving) |
2020-12-30 02:39:33 +0100 | mnrmnaugh | (~mnrmnaugh@unaffiliated/mnrmnaugh) |
2020-12-30 02:39:36 +0100 | columbarius | (~columbari@i5E86B356.versanet.de) (Ping timeout: 240 seconds) |
2020-12-30 02:40:52 +0100 | mnrmnaugh | (~mnrmnaugh@unaffiliated/mnrmnaugh) () |
2020-12-30 02:41:15 +0100 | <pie_> | ok looks like i may need to upgrade to at least ghc 8.10 to get something reasonable |
2020-12-30 02:42:05 +0100 | columbarius | (~columbari@i5E86B34F.versanet.de) |
2020-12-30 02:46:22 +0100 | wei2912 | (~wei2912@unaffiliated/wei2912) |
2020-12-30 02:52:50 +0100 | Entertainment | (~entertain@104.246.132.210) (Ping timeout: 264 seconds) |
2020-12-30 02:54:05 +0100 | <koz_> | Is there anything already out there equivalent to 'data Foo a b = Foo b (a -> b)'? |
2020-12-30 02:55:09 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) |
2020-12-30 02:55:14 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
2020-12-30 02:57:19 +0100 | mp___ | (~mp@hell.cx) |
2020-12-30 02:58:49 +0100 | Vulfe | (~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) |
2020-12-30 03:00:22 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) (Ping timeout: 256 seconds) |
2020-12-30 03:00:54 +0100 | star_cloud | (~star_clou@ec2-34-220-44-120.us-west-2.compute.amazonaws.com) |
2020-12-30 03:02:04 +0100 | mp___ | (~mp@hell.cx) (Ping timeout: 256 seconds) |
2020-12-30 03:03:49 +0100 | Vulfe | (~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 264 seconds) |
2020-12-30 03:05:38 +0100 | <sshine> | koz_, what's it for? |
2020-12-30 03:06:05 +0100 | <koz_> | sshine: I figured out that I need something equivalent to that, and was curious if it has any clever instances. |
2020-12-30 03:07:34 +0100 | usr25 | (~usr25@unaffiliated/usr25) (Ping timeout: 260 seconds) |
2020-12-30 03:08:04 +0100 | olligobber | (olligobber@gateway/vpn/privateinternetaccess/olligobber) |
2020-12-30 03:08:28 +0100 | carthia | (~carthia@gateway/tor-sasl/carthia) (Remote host closed the connection) |
2020-12-30 03:14:30 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) |
2020-12-30 03:18:45 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) (Ping timeout: 240 seconds) |
2020-12-30 03:20:16 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 03:20:52 +0100 | perrier-jouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.0) |
2020-12-30 03:23:09 +0100 | Inboxkiller | (~Inboxkill@177.25.173.143) |
2020-12-30 03:23:16 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 03:24:03 +0100 | vicfred | (~vicfred@unaffiliated/vicfred) (Quit: Leaving) |
2020-12-30 03:25:07 +0100 | Inboxkiller | (~Inboxkill@177.25.173.143) () |
2020-12-30 03:25:14 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 264 seconds) |
2020-12-30 03:28:42 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds) |
2020-12-30 03:34:59 +0100 | nbloomf | (~nbloomf@2600:1700:ad14:3020:3cf1:586e:d728:faa3) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 03:35:22 +0100 | dfeuer | (~dfeuer@pool-108-18-223-60.washdc.fios.verizon.net) |
2020-12-30 03:38:03 +0100 | philopsos | (~caecilius@gateway/tor-sasl/caecilius) (Ping timeout: 240 seconds) |
2020-12-30 03:38:41 +0100 | cheater | (~user@unaffiliated/cheater) (Ping timeout: 256 seconds) |
2020-12-30 03:38:51 +0100 | cheater | (~user@unaffiliated/cheater) |
2020-12-30 03:39:08 +0100 | smitop | (uid328768@gateway/web/irccloud.com/x-tanlhsstfzbvbzcf) (Quit: Connection closed for inactivity) |
2020-12-30 03:39:16 +0100 | Anthaas | (~Anthaas@unaffiliated/anthaas) (Ping timeout: 240 seconds) |
2020-12-30 03:40:01 +0100 | alx741 | (~alx741@181.196.68.142) (Ping timeout: 246 seconds) |
2020-12-30 03:40:08 +0100 | Anthaas | (~Anthaas@unaffiliated/anthaas) |
2020-12-30 03:40:49 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 03:41:32 +0100 | <pie_> | bitonic: I appear to have no linker error after upgrading to ghc 8.10 but im not sure if everything works , also I needed to add clang to LD_LIBARY_PATH while loading cabal repl for some reason |
2020-12-30 03:43:15 +0100 | <pie_> | and now that seems to have been intermittent...idk needs more research i guess |
2020-12-30 03:44:07 +0100 | <pie_> | nevermind, stepping on my own toes |
2020-12-30 03:45:12 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 260 seconds) |
2020-12-30 03:51:24 +0100 | nbloomf | (~nbloomf@2600:1700:ad14:3020:3cf1:586e:d728:faa3) |
2020-12-30 03:51:45 +0100 | xff0x_ | (~fox@2001:1a81:532a:2200:ffb2:f24f:b99c:824f) (Ping timeout: 268 seconds) |
2020-12-30 03:51:48 +0100 | nbloomf | (~nbloomf@2600:1700:ad14:3020:3cf1:586e:d728:faa3) (Client Quit) |
2020-12-30 03:53:00 +0100 | xff0x_ | (~fox@2001:1a81:5361:7200:f380:27a:9a5d:7c68) |
2020-12-30 03:54:01 +0100 | <pie_> | i need to get some sleep, but _if_ im looking at the right file, it looks like the output still has U typeinfo for clang::ast_matchers::MatchFinder::MatchCallback , just ghci isnt choking on it. not sure tho |
2020-12-30 03:55:09 +0100 | Matt_P | (~Matt_P@217.146.82.202) (Remote host closed the connection) |
2020-12-30 03:55:12 +0100 | <pie_> | this was for the minimal repro, which doesnt actually have any interesting code in it, so if something just got better at being lazy, it might still break later |
2020-12-30 03:57:38 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 03:58:14 +0100 | Stanley00 | (~stanley00@unaffiliated/stanley00) |
2020-12-30 03:58:30 +0100 | <pie_> | either im very confused or actually my ghc is now 8.8.4 and not 8.10 |
2020-12-30 03:59:05 +0100 | nbloomf | (~nbloomf@2600:1700:ad14:3020:3cf1:586e:d728:faa3) |
2020-12-30 04:03:57 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@static-198-54-134-148.cust.tzulo.com) (Quit: Leaving) |
2020-12-30 04:04:34 +0100 | Tops2 | (~Tobias@dyndsl-095-033-094-200.ewe-ip-backbone.de) (Read error: Connection reset by peer) |
2020-12-30 04:05:37 +0100 | theDon | (~td@muedsl-82-207-238-118.citykom.de) (Ping timeout: 264 seconds) |
2020-12-30 04:05:41 +0100 | chang | (~textual@host-173-230-65-85.njjcmar.clients.pavlovmedia.com) |
2020-12-30 04:07:24 +0100 | theDon | (~td@94.134.91.72) |
2020-12-30 04:11:29 +0100 | m0rphism | (~m0rphism@HSI-KBW-085-216-104-059.hsi.kabelbw.de) (Ping timeout: 268 seconds) |
2020-12-30 04:11:52 +0100 | perrier-jouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
2020-12-30 04:12:24 +0100 | b5er | (~b5er_@91.193.4.202) |
2020-12-30 04:12:42 +0100 | xirhtogal | (~lagothrix@unaffiliated/lagothrix) |
2020-12-30 04:12:42 +0100 | lagothrix | (~lagothrix@unaffiliated/lagothrix) (Killed (rothfuss.freenode.net (Nickname regained by services))) |
2020-12-30 04:12:42 +0100 | xirhtogal | lagothrix |
2020-12-30 04:14:46 +0100 | <danso> | reading this chart, i notice a pattern: |
2020-12-30 04:14:54 +0100 | <danso> | https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages |
2020-12-30 04:15:21 +0100 | <danso> | haskell, reason, ML, clojure, and friends don't have `%` as a modulo operator |
2020-12-30 04:15:31 +0100 | <danso> | instead they go with the function named `mod` |
2020-12-30 04:15:33 +0100 | <koz_> | danso: Because that's a C-ism. |
2020-12-30 04:15:40 +0100 | V3ct0r | (~V3ct0r@185.204.1.185) |
2020-12-30 04:15:51 +0100 | <koz_> | We don't consider C syntax so great that we should mindlessly ape it. |
2020-12-30 04:16:05 +0100 | <danso> | yeah, C looks like one of the earliest ones on that chart that use it |
2020-12-30 04:16:33 +0100 | <danso> | but was this just a historical coincidence? |
2020-12-30 04:16:49 +0100 | <danso> | i'm wondering whether any rationale for choosing or not choosing it is known |
2020-12-30 04:16:58 +0100 | <koz_> | That everyone copied C apart from the listed languages? Or that the listed languages chose _not_ to copy C? |
2020-12-30 04:17:28 +0100 | cr3 | (~cr3@192-222-143-195.qc.cable.ebox.net) (Quit: leaving) |
2020-12-30 04:17:46 +0100 | <danso> | i'm asking about haskell in particular, and why it chose to omit `%` |
2020-12-30 04:17:58 +0100 | <danso> | and i realize the answer is probably "because ML chose to" |
2020-12-30 04:18:03 +0100 | <koz_> | Haskell is technically part of the ML family. |
2020-12-30 04:18:10 +0100 | <danso> | but maybe somebody knows why they did? :^) |
2020-12-30 04:18:26 +0100 | <koz_> | So I'm pretty sure it's 'because ML did it'. |
2020-12-30 04:18:58 +0100 | <ephemient> | I'm not sure I'd call Haskell a ML language, but it's definitely at least half inspired |
2020-12-30 04:19:23 +0100 | stef204 | (~stef204@unaffiliated/stef-204/x-384198) (Ping timeout: 272 seconds) |
2020-12-30 04:19:38 +0100 | vicfred | (vicfred@gateway/vpn/mullvad/vicfred) |
2020-12-30 04:19:44 +0100 | <danso> | some languages predating C do have modulo operators: APL used `|` and algol68 used `÷×` |
2020-12-30 04:20:16 +0100 | <monochrom> | % contains a / stroke, perhaps that's why K&R chose it. |
2020-12-30 04:20:16 +0100 | <yahb> | monochrom: ; <interactive>:122:20: error: parse error on input `,' |
2020-12-30 04:20:55 +0100 | <danso> | i guess this is not what #haskell is for. where would be the place to ask or research this kind of thing? |
2020-12-30 04:21:01 +0100 | <monochrom> | But it's a stupid reason, so independent thinkers don't follow it. |
2020-12-30 04:22:02 +0100 | <ephemient> | https://hackage.haskell.org/package/base-unicode-symbols defines (∣) and (∤) :D |
2020-12-30 04:22:11 +0100 | Mikagami | (~MOSCOS@122.54.107.175) (Remote host closed the connection) |
2020-12-30 04:22:31 +0100 | <monochrom> | Haskell actually outdoes all other languages by acknowledging that there are two kinds of remainders, and there are three kinds of exponentiation. |
2020-12-30 04:22:34 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 04:22:38 +0100 | Mikagami | (~MOSCOS@122.54.107.175) |
2020-12-30 04:23:30 +0100 | alx741 | (~alx741@181.196.68.142) |
2020-12-30 04:23:31 +0100 | <monochrom> | But Haskell follows the sane convention of Pascal (probably Algol actually?) in using names like div, mod, quot, rem, instead of shoehorning funny punctuations. |
2020-12-30 04:24:15 +0100 | <danso> | even fortran uses `mod`, apparently |
2020-12-30 04:24:24 +0100 | <danso> | ephemient, that is terrifying yet satisfying |
2020-12-30 04:24:56 +0100 | <monochrom> | and follows the inspiration of ML in providing a route for making them infix, so the syntax doesn't have to suck just because they are alphabetical "function" "names". |
2020-12-30 04:25:30 +0100 | <monochrom> | "function" in quotes because there was a time people made a stupid big fuss about "function vs operator" |
2020-12-30 04:26:56 +0100 | <monochrom> | Since ML, modernized people recognize that all are semantically functions and all are semantically operators, the punny difference between "oh, this one is alphabetical" and "oh, that one is punctuational" is merely syntax sugar. |
2020-12-30 04:27:02 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 264 seconds) |
2020-12-30 04:30:07 +0100 | gzj | (~gzj@unaffiliated/gzj) (Remote host closed the connection) |
2020-12-30 04:30:27 +0100 | gzj | (~gzj@unaffiliated/gzj) |
2020-12-30 04:31:11 +0100 | chang | (~textual@host-173-230-65-85.njjcmar.clients.pavlovmedia.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 04:31:11 +0100 | Tario | (~Tario@201.192.165.173) (Read error: Connection reset by peer) |
2020-12-30 04:31:23 +0100 | Tario | (~Tario@201.192.165.173) |
2020-12-30 04:32:09 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 260 seconds) |
2020-12-30 04:32:57 +0100 | <dibblego> | you've clearly not used scala yet |
2020-12-30 04:34:08 +0100 | <maerwald> | and why would anyone |
2020-12-30 04:38:37 +0100 | <koz_> | maerwald: 'ghcup compile ghc -v 8.10.3 -b whatever' is still spewing a DigestError. |
2020-12-30 04:38:56 +0100 | <dsal> | If you don't like `mod`, you can use `rem` |
2020-12-30 04:41:09 +0100 | <maerwald> | koz_: that's because the hash is wrong :D |
2020-12-30 04:42:41 +0100 | <Widget> | dsal: they are not the same |
2020-12-30 04:43:15 +0100 | <koz_> | maerwald: I would never have guessed. |
2020-12-30 04:43:30 +0100 | <dsal> | Widget: No, but I don't know how to do `rem` in C. |
2020-12-30 04:43:44 +0100 | <dsal> | Maybe C uses ‰ |
2020-12-30 04:43:49 +0100 | <maerwald> | koz_: someone copy pasted it, it's the hash from 8.10.2, lol |
2020-12-30 04:44:06 +0100 | <maerwald> | I guess we don't test this in CI, only the bindists |
2020-12-30 04:44:39 +0100 | jacks2 | (~bc815220@217.29.117.252) |
2020-12-30 04:45:47 +0100 | <maerwald> | koz_: but you know you can just build ghc manually, create a bindist via `make binary-dist` (I think) and then feed it into ghcup? |
2020-12-30 04:45:56 +0100 | Melanie | (~Melanie@192-0-134-138.cpe.teksavvy.com) (Ping timeout: 240 seconds) |
2020-12-30 04:46:06 +0100 | dfeuer | (~dfeuer@pool-108-18-223-60.washdc.fios.verizon.net) (Ping timeout: 256 seconds) |
2020-12-30 04:46:21 +0100 | <koz_> | maerwald: Sure. I could also bypass ghcup entirely. I'm reporting this as a bug because I like bugs to be fixed, or at least the maintainers to be aware. |
2020-12-30 04:46:42 +0100 | <koz_> | This isn't a 'I dunno wat do maerwald, instruct me sensei'. It's 'this isn't working as it should maerwald, maybe you might wanna know'. |
2020-12-30 04:47:15 +0100 | <maerwald> | you get my attention quicker with a PR, but I'm already fixing it |
2020-12-30 04:47:30 +0100 | <koz_> | Thanks! |
2020-12-30 04:48:15 +0100 | sand_dull | (~theuser@c-73-149-95-105.hsd1.ct.comcast.net) |
2020-12-30 04:49:20 +0100 | christo | (~chris@81.96.113.213) (Remote host closed the connection) |
2020-12-30 04:50:00 +0100 | christo | (~chris@81.96.113.213) |
2020-12-30 04:53:31 +0100 | ransom | (~c4264035@8.47.12.52) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 04:53:56 +0100 | christo | (~chris@81.96.113.213) (Ping timeout: 240 seconds) |
2020-12-30 05:01:12 +0100 | nbloomf_ | (~nbloomf@2600:1700:ad14:3020:7dec:2218:241d:6f03) |
2020-12-30 05:02:40 +0100 | justanotheruser | (~justanoth@unaffiliated/justanotheruser) (Ping timeout: 268 seconds) |
2020-12-30 05:02:46 +0100 | theDon | (~td@94.134.91.72) (Ping timeout: 256 seconds) |
2020-12-30 05:03:38 +0100 | nbloomf | (~nbloomf@2600:1700:ad14:3020:3cf1:586e:d728:faa3) (Ping timeout: 264 seconds) |
2020-12-30 05:03:53 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 05:04:29 +0100 | theDon | (~td@94.134.91.51) |
2020-12-30 05:06:09 +0100 | plutoniix | (~q@184.82.204.116) |
2020-12-30 05:06:38 +0100 | teardown | (~user@gateway/tor-sasl/mrush) |
2020-12-30 05:09:19 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
2020-12-30 05:09:23 +0100 | teardown_ | (~user@gateway/tor-sasl/mrush) (Ping timeout: 240 seconds) |
2020-12-30 05:10:24 +0100 | urodna | (~urodna@unaffiliated/urodna) (Quit: urodna) |
2020-12-30 05:11:50 +0100 | polyrain | (~polyrain@121.222.65.83) |
2020-12-30 05:13:16 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 240 seconds) |
2020-12-30 05:13:51 +0100 | Deide | (~Deide@217.155.19.23) (Quit: Seeee yaaaa) |
2020-12-30 05:13:52 +0100 | ransom | (~c4264035@2a09:bac0:72::82f:c34) |
2020-12-30 05:16:24 +0100 | dibblego | (~dibblego@122-199-1-30.ip4.superloop.com) |
2020-12-30 05:16:24 +0100 | dibblego | (~dibblego@122-199-1-30.ip4.superloop.com) (Changing host) |
2020-12-30 05:16:24 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) |
2020-12-30 05:16:28 +0100 | geowiesnot | (~user@87-89-181-157.abo.bbox.fr) |
2020-12-30 05:16:42 +0100 | Sheilong | (uid293653@gateway/web/irccloud.com/x-unmksdzihnsijttq) () |
2020-12-30 05:18:24 +0100 | xelxebar | (~xelxebar@gateway/tor-sasl/xelxebar) (Ping timeout: 240 seconds) |
2020-12-30 05:18:43 +0100 | srk | (~sorki@gateway/tor-sasl/sorki) (Ping timeout: 240 seconds) |
2020-12-30 05:18:48 +0100 | SeMas | (uid32977@gateway/web/irccloud.com/x-ewxsbmmdfjckxyvi) (Quit: Connection closed for inactivity) |
2020-12-30 05:19:19 +0100 | hacxman | (~hexo@gateway/tor-sasl/hexo) |
2020-12-30 05:19:23 +0100 | jb55 | (~jb55@gateway/tor-sasl/jb55) (Ping timeout: 240 seconds) |
2020-12-30 05:19:23 +0100 | hexo | (~hexo@gateway/tor-sasl/hexo) (Ping timeout: 240 seconds) |
2020-12-30 05:19:28 +0100 | srk | (~sorki@gateway/tor-sasl/sorki) |
2020-12-30 05:19:37 +0100 | hacxman | hexo |
2020-12-30 05:19:43 +0100 | ChaiTRex | (~ChaiTRex@gateway/tor-sasl/chaitrex) (Ping timeout: 240 seconds) |
2020-12-30 05:19:44 +0100 | cantstanya | (~chatting@gateway/tor-sasl/cantstanya) (Ping timeout: 240 seconds) |
2020-12-30 05:19:46 +0100 | xelxebar | (~xelxebar@gateway/tor-sasl/xelxebar) |
2020-12-30 05:19:48 +0100 | denisse_ | (~spaceCat@gateway/tor-sasl/alephzer0) |
2020-12-30 05:20:01 +0100 | ransom | (~c4264035@2a09:bac0:72::82f:c34) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 05:20:03 +0100 | denisse | (~spaceCat@gateway/tor-sasl/alephzer0) (Ping timeout: 240 seconds) |
2020-12-30 05:21:56 +0100 | ChaiTRex | (~ChaiTRex@gateway/tor-sasl/chaitrex) |
2020-12-30 05:22:57 +0100 | jb55 | (~jb55@gateway/tor-sasl/jb55) |
2020-12-30 05:24:35 +0100 | cantstanya | (~chatting@gateway/tor-sasl/cantstanya) |
2020-12-30 05:33:10 +0100 | boxscape | (4ff0ba59@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.89) |
2020-12-30 05:37:24 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 05:42:09 +0100 | MOSCOS | (~MOSCOS@152.32.70.55) |
2020-12-30 05:44:31 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 05:45:22 +0100 | Mikagami | (~MOSCOS@122.54.107.175) (Ping timeout: 260 seconds) |
2020-12-30 05:45:50 +0100 | Mikagami | (~MOSCOS@122.54.107.175) |
2020-12-30 05:47:05 +0100 | MOSCOS | (~MOSCOS@152.32.70.55) (Ping timeout: 240 seconds) |
2020-12-30 05:48:52 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 260 seconds) |
2020-12-30 05:54:12 +0100 | pavonia | (~user@unaffiliated/siracusa) (Quit: Bye!) |
2020-12-30 05:55:56 +0100 | solonarv | (~solonarv@astrasbourg-653-1-157-135.w90-6.abo.wanadoo.fr) (Ping timeout: 240 seconds) |
2020-12-30 05:57:35 +0100 | unlink2 | (~unlink2@p5dc0acf8.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
2020-12-30 05:58:29 +0100 | geowiesnot | (~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 260 seconds) |
2020-12-30 06:00:05 +0100 | wei2912 | (~wei2912@unaffiliated/wei2912) (Remote host closed the connection) |
2020-12-30 06:03:36 +0100 | unlink2 | (~unlink2@p200300ebcf259600e4593ff5d42812d3.dip0.t-ipconnect.de) |
2020-12-30 06:06:57 +0100 | Tario | (~Tario@201.192.165.173) (Ping timeout: 260 seconds) |
2020-12-30 06:09:43 +0100 | rowbee | (~augh@theguntretort.com) (Quit: ZNC - https://znc.in) |
2020-12-30 06:09:56 +0100 | rowbee | (~augh@theguntretort.com) |
2020-12-30 06:11:34 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
2020-12-30 06:13:05 +0100 | Guest_46 | (bb7a7d6d@187.122.125.109) |
2020-12-30 06:14:14 +0100 | Guest_46 | (bb7a7d6d@187.122.125.109) () |
2020-12-30 06:17:27 +0100 | V3ct0r | (~V3ct0r@185.204.1.185) (Remote host closed the connection) |
2020-12-30 06:19:12 +0100 | polyrain | (~polyrain@121.222.65.83) (Read error: Connection reset by peer) |
2020-12-30 06:19:36 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) |
2020-12-30 06:21:38 +0100 | sand_dull | (~theuser@c-73-149-95-105.hsd1.ct.comcast.net) (Quit: Lost terminal) |
2020-12-30 06:21:43 +0100 | tomboy64 | (~tomboy64@gateway/tor-sasl/tomboy64) (Ping timeout: 240 seconds) |
2020-12-30 06:22:09 +0100 | ADG1089__ | (~aditya@223.235.213.117) |
2020-12-30 06:22:25 +0100 | ddellacosta | (dd@gateway/vpn/mullvad/ddellacosta) (Ping timeout: 246 seconds) |
2020-12-30 06:22:43 +0100 | rowbee | (~augh@theguntretort.com) (Quit: ZNC - https://znc.in) |
2020-12-30 06:23:29 +0100 | tomboy64 | (~tomboy64@gateway/tor-sasl/tomboy64) |
2020-12-30 06:25:18 +0100 | |Kin| | (~|Kin|@217.151.98.163) |
2020-12-30 06:26:23 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 06:27:11 +0100 | rowbee | (~augh@theguntretort.com) |
2020-12-30 06:30:52 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 260 seconds) |
2020-12-30 06:38:14 +0100 | teardown_ | (~user@gateway/tor-sasl/mrush) |
2020-12-30 06:41:03 +0100 | teardown | (~user@gateway/tor-sasl/mrush) (Ping timeout: 240 seconds) |
2020-12-30 06:41:04 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 06:41:38 +0100 | rayyyy | (~nanoz@gateway/tor-sasl/nanoz) |
2020-12-30 06:46:37 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 260 seconds) |
2020-12-30 06:48:30 +0100 | Varis | (~Tadas@unaffiliated/varis) (Remote host closed the connection) |
2020-12-30 06:51:11 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Quit: leaving) |
2020-12-30 06:52:50 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 06:55:37 +0100 | MOSCOS | (~MOSCOS@152.32.70.55) |
2020-12-30 06:57:16 +0100 | MOSCOS | (~MOSCOS@152.32.70.55) (Read error: Connection reset by peer) |
2020-12-30 06:58:01 +0100 | MOSCOS | (~MOSCOS@152.32.70.55) |
2020-12-30 06:58:45 +0100 | Mikagami | (~MOSCOS@122.54.107.175) (Ping timeout: 240 seconds) |
2020-12-30 06:58:53 +0100 | Mikagami | (~MOSCOS@122.54.107.175) |
2020-12-30 06:59:38 +0100 | boxscape | (4ff0ba59@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.89) (Quit: Connection closed) |
2020-12-30 07:02:25 +0100 | MOSCOS | (~MOSCOS@152.32.70.55) (Ping timeout: 240 seconds) |
2020-12-30 07:04:27 +0100 | |Kin| | (~|Kin|@217.151.98.163) (Remote host closed the connection) |
2020-12-30 07:07:12 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) |
2020-12-30 07:08:07 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 07:11:50 +0100 | o1lo01ol1o | (~o1lo01ol1@31.22.145.144) |
2020-12-30 07:12:52 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 260 seconds) |
2020-12-30 07:14:12 +0100 | rdivyanshu | (uid322626@gateway/web/irccloud.com/x-azqolmgutgadssur) |
2020-12-30 07:15:36 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 07:16:50 +0100 | o1lo01ol1o | (~o1lo01ol1@31.22.145.144) (Ping timeout: 272 seconds) |
2020-12-30 07:17:01 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) |
2020-12-30 07:18:12 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 07:21:36 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) (Ping timeout: 240 seconds) |
2020-12-30 07:31:13 +0100 | teardown | (~user@gateway/tor-sasl/mrush) |
2020-12-30 07:31:41 +0100 | newz2000 | (~newz2000@185.103.96.147) |
2020-12-30 07:32:25 +0100 | b5er | (~b5er_@91.193.4.202) (Ping timeout: 246 seconds) |
2020-12-30 07:34:03 +0100 | teardown_ | (~user@gateway/tor-sasl/mrush) (Ping timeout: 240 seconds) |
2020-12-30 07:37:04 +0100 | b4er | (~b5er_@91.193.4.138) |
2020-12-30 07:40:05 +0100 | christo | (~chris@81.96.113.213) |
2020-12-30 07:49:36 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds) |
2020-12-30 07:51:02 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 264 seconds) |
2020-12-30 07:56:06 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
2020-12-30 08:00:23 +0100 | gxt | (~gxt@gateway/tor-sasl/gxt) (Ping timeout: 240 seconds) |
2020-12-30 08:00:54 +0100 | gxt | (~gxt@gateway/tor-sasl/gxt) |
2020-12-30 08:07:38 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 08:12:36 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 268 seconds) |
2020-12-30 08:16:23 +0100 | hexo | (~hexo@gateway/tor-sasl/hexo) (Ping timeout: 240 seconds) |
2020-12-30 08:16:40 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 08:16:43 +0100 | srk | (~sorki@gateway/tor-sasl/sorki) (Ping timeout: 240 seconds) |
2020-12-30 08:17:12 +0100 | qwerty | (~tema@217.118.92.215) |
2020-12-30 08:18:00 +0100 | Sgeo | (~Sgeo@ool-18b98aa4.dyn.optonline.net) (Read error: Connection reset by peer) |
2020-12-30 08:19:02 +0100 | srk | (~sorki@gateway/tor-sasl/sorki) |
2020-12-30 08:19:02 +0100 | hexo | (~hexo@gateway/tor-sasl/hexo) |
2020-12-30 08:20:00 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:8058:a74d:29ea:8456) (Remote host closed the connection) |
2020-12-30 08:20:55 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 08:21:40 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds) |
2020-12-30 08:21:44 +0100 | jacks2 | (~bc815220@217.29.117.252) (Quit: http://www.okay.uz/ (Ping timeout)) |
2020-12-30 08:23:56 +0100 | phasespace_ | (~sar@89-162-33-21.fiber.signal.no) (Ping timeout: 256 seconds) |
2020-12-30 08:24:13 +0100 | tsrt^ | (tsrt@ip98-184-89-2.mc.at.cox.net) (Ping timeout: 264 seconds) |
2020-12-30 08:24:52 +0100 | tsrt^ | (~hph@ip98-184-89-2.mc.at.cox.net) |
2020-12-30 08:30:53 +0100 | teardown_ | (~user@gateway/tor-sasl/mrush) |
2020-12-30 08:33:35 +0100 | teardown_ | (~user@gateway/tor-sasl/mrush) (Remote host closed the connection) |
2020-12-30 08:33:43 +0100 | teardown | (~user@gateway/tor-sasl/mrush) (Ping timeout: 240 seconds) |
2020-12-30 08:36:03 +0100 | teardown | (~user@gateway/tor-sasl/mrush) |
2020-12-30 08:37:54 +0100 | phasespace | (~sar@80-89-47-117.inet.signal.no) |
2020-12-30 08:38:44 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 08:40:49 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) |
2020-12-30 08:42:22 +0100 | mputz | (~Thunderbi@dslb-088-064-063-125.088.064.pools.vodafone-ip.de) |
2020-12-30 08:45:56 +0100 | bitmagie | (~Thunderbi@200116b80684bd0008a0a917606ec592.dip.versatel-1u1.de) |
2020-12-30 08:46:19 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 08:49:03 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 08:49:38 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) |
2020-12-30 08:50:06 +0100 | al3x27 | (~plovs@85.254.74.40) (Quit: WeeChat 3.0) |
2020-12-30 08:51:28 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 08:52:30 +0100 | pjb | (~t@2a01cb04063ec5007877dab9a3fb2e14.ipv6.abo.wanadoo.fr) |
2020-12-30 08:53:47 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 260 seconds) |
2020-12-30 08:57:31 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
2020-12-30 08:58:03 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 09:04:39 +0100 | da39a3ee5e6b4b0d | (~da39a3ee5@2403:6200:8876:f14e:750f:83e8:c56e:b09f) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 09:15:07 +0100 | bisickcor | (~username@117.200.6.145) (Remote host closed the connection) |
2020-12-30 09:17:08 +0100 | madjestic | (~Android@86-88-72-244.fixed.kpn.net) |
2020-12-30 09:19:12 +0100 | LKoen | (~LKoen@126.170.9.109.rev.sfr.net) |
2020-12-30 09:19:18 +0100 | olligobber | (olligobber@gateway/vpn/privateinternetaccess/olligobber) (Remote host closed the connection) |
2020-12-30 09:19:43 +0100 | rayyyy | (~nanoz@gateway/tor-sasl/nanoz) (Ping timeout: 240 seconds) |
2020-12-30 09:21:37 +0100 | bitmagie | (~Thunderbi@200116b80684bd0008a0a917606ec592.dip.versatel-1u1.de) (Quit: bitmagie) |
2020-12-30 09:21:44 +0100 | darjeeling_ | (~darjeelin@122.245.217.190) (Ping timeout: 256 seconds) |
2020-12-30 09:24:54 +0100 | nbloomf_ | (~nbloomf@2600:1700:ad14:3020:7dec:2218:241d:6f03) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 09:30:49 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 09:34:17 +0100 | christo | (~chris@81.96.113.213) (Remote host closed the connection) |
2020-12-30 09:34:42 +0100 | christo | (~chris@81.96.113.213) |
2020-12-30 09:35:26 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 264 seconds) |
2020-12-30 09:36:31 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) |
2020-12-30 09:37:26 +0100 | shatriff | (~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection) |
2020-12-30 09:37:46 +0100 | shatriff | (~vitaliish@176-52-216-242.irishtelecom.com) |
2020-12-30 09:37:59 +0100 | kritzefitz | (~kritzefit@fw-front.credativ.com) |
2020-12-30 09:38:15 +0100 | shatriff | (~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection) |
2020-12-30 09:38:31 +0100 | shatriff | (~vitaliish@176-52-216-242.irishtelecom.com) |
2020-12-30 09:39:03 +0100 | shatriff | (~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection) |
2020-12-30 09:39:20 +0100 | shatriff | (~vitaliish@176-52-216-242.irishtelecom.com) |
2020-12-30 09:39:49 +0100 | shatriff | (~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection) |
2020-12-30 09:39:58 +0100 | darjeeling_ | (~darjeelin@122.245.217.190) |
2020-12-30 09:40:06 +0100 | shatriff | (~vitaliish@176-52-216-242.irishtelecom.com) |
2020-12-30 09:40:32 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) (Client Quit) |
2020-12-30 09:40:44 +0100 | shatriff | (~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection) |
2020-12-30 09:42:27 +0100 | newz2000 | (~newz2000@185.103.96.147) (Remote host closed the connection) |
2020-12-30 09:52:05 +0100 | aljce | (617326cd@97-115-38-205.ptld.qwest.net) (Remote host closed the connection) |
2020-12-30 09:52:47 +0100 | gxt | (~gxt@gateway/tor-sasl/gxt) (Remote host closed the connection) |
2020-12-30 09:53:09 +0100 | gxt | (~gxt@gateway/tor-sasl/gxt) |
2020-12-30 09:55:27 +0100 | rayyyy | (~nanoz@gateway/tor-sasl/nanoz) |
2020-12-30 09:57:22 +0100 | wz1000 | (~wz1000@static.11.113.47.78.clients.your-server.de) (Ping timeout: 260 seconds) |
2020-12-30 10:00:07 +0100 | themsay[m] | (themsaymat@gateway/shell/matrix.org/x-lszdfmzzigovolaq) (Quit: Idle for 30+ days) |
2020-12-30 10:02:37 +0100 | p-core | (~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56) |
2020-12-30 10:03:40 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds) |
2020-12-30 10:05:44 +0100 | thunderrd | (~thunderrd@183.182.111.131) |
2020-12-30 10:07:12 +0100 | gioyik | (~gioyik@179.32.228.107) (Quit: WeeChat 3.0) |
2020-12-30 10:12:43 +0100 | Franciman | (~francesco@host-95-250-152-231.retail.telecomitalia.it) |
2020-12-30 10:13:11 +0100 | LaserShark | (~LaserShar@185.163.110.125) |
2020-12-30 10:14:36 +0100 | tsrt^ | (~hph@ip98-184-89-2.mc.at.cox.net) (Ping timeout: 240 seconds) |
2020-12-30 10:15:21 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) |
2020-12-30 10:15:23 +0100 | tsrt^ | (tsrt@ip98-184-89-2.mc.at.cox.net) |
2020-12-30 10:18:11 +0100 | qwerty | (~tema@217.118.92.215) (Excess Flood) |
2020-12-30 10:18:14 +0100 | benjamingr__ | (uid23465@gateway/web/irccloud.com/x-hcdctxhyzchiutea) |
2020-12-30 10:18:53 +0100 | qwerty | (~tema@217.118.92.215) |
2020-12-30 10:19:53 +0100 | michalz | (~user@185.246.204.91) |
2020-12-30 10:20:12 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) (Client Quit) |
2020-12-30 10:21:10 +0100 | danso | (~dan@69-165-210-185.cable.teksavvy.com) (Quit: WeeChat 3.0) |
2020-12-30 10:22:08 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Remote host closed the connection) |
2020-12-30 10:24:04 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) |
2020-12-30 10:24:48 +0100 | Gurkenglas | (~Gurkengla@unaffiliated/gurkenglas) |
2020-12-30 10:27:01 +0100 | wonko7 | (~wonko7@lns-bzn-55-82-255-183-4.adsl.proxad.net) (Quit: See You Space Cowboy..) |
2020-12-30 10:28:35 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) (Client Quit) |
2020-12-30 10:31:08 +0100 | _ht | (~quassel@82-169-194-8.biz.kpn.net) |
2020-12-30 10:32:00 +0100 | gehmehgeh | (~ircuser1@gateway/tor-sasl/gehmehgeh) |
2020-12-30 10:32:32 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) |
2020-12-30 10:32:45 +0100 | wz1000 | (~wz1000@static.11.113.47.78.clients.your-server.de) |
2020-12-30 10:34:57 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) |
2020-12-30 10:36:01 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 10:37:32 +0100 | fendor | (~fendor@178.165.130.45.wireless.dyn.drei.com) |
2020-12-30 10:38:02 +0100 | pera | (~pera@unaffiliated/pera) |
2020-12-30 10:39:49 +0100 | plutoniix | (~q@184.82.204.116) (Ping timeout: 264 seconds) |
2020-12-30 10:48:17 +0100 | da39a3ee5e6b4b0d | (~da39a3ee5@2403:6200:8876:f14e:750f:83e8:c56e:b09f) |
2020-12-30 10:49:05 +0100 | polyrain | (~polyrain@2001:8003:e501:6901:ec47:17f7:9d76:1795) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 10:50:48 +0100 | LKoen | (~LKoen@126.170.9.109.rev.sfr.net) (Remote host closed the connection) |
2020-12-30 10:50:54 +0100 | <[exa]> | Is there any decent format/library/tool for user-specifiable tokenization? |
2020-12-30 10:51:52 +0100 | <[exa]> | My program is processing text input that is tokenized based on user decision, currently using a bunch-of-regexes kind of "specification" |
2020-12-30 10:52:36 +0100 | hiroaki_ | (~hiroaki@ip4d16fa3b.dynamic.kabel-deutschland.de) (Ping timeout: 240 seconds) |
2020-12-30 10:52:42 +0100 | <[exa]> | usage is roughly like `program --format bunch-of-regexes-that-specify-how-to-tokenize-input.txt < input.txt ` |
2020-12-30 10:52:56 +0100 | <Uniaika> | well there is the boring way of having a fixed set of possible tokenisation options and an associated tokeniser |
2020-12-30 10:53:13 +0100 | <[exa]> | yeah that's boring and practical. :] |
2020-12-30 10:53:46 +0100 | <Uniaika> | [exa]: and it frees your mind from thinking about it whilst having your feature delivered, so you can take more time to appropriately think of a solution! |
2020-12-30 10:53:53 +0100 | <[exa]> | I'm probably going that way unless some kind of lex-style token specification format surfaces |
2020-12-30 10:54:07 +0100 | <Uniaika> | Like accepting user-supplied Lua programs that do the tokenisation for you! :'D |
2020-12-30 10:54:17 +0100 | <Uniaika> | (this is dangerous don't do that) |
2020-12-30 10:54:28 +0100 | <[exa]> | eyebrow raised. |
2020-12-30 10:54:51 +0100 | <Uniaika> | I was shitposting, don't implement that for the love of god |
2020-12-30 10:55:04 +0100 | <[exa]> | anyway yes, the possible complexity of the "specified parser" is a concern |
2020-12-30 10:55:28 +0100 | hnOsmium0001 | (uid453710@gateway/web/irccloud.com/x-rbphamfimqkpbxje) (Quit: Connection closed for inactivity) |
2020-12-30 10:56:06 +0100 | <[exa]> | Uniaika: I won't, but you can't deny that just running anyther program is The Unixest Way to get the thing done |
2020-12-30 10:56:52 +0100 | <[exa]> | oh my, this shouldn't have happened |
2020-12-30 10:57:00 +0100 | <[exa]> | :] |
2020-12-30 10:57:36 +0100 | <[exa]> | hm, what if I gut out the lexer spec from Alex? |
2020-12-30 10:58:55 +0100 | mputz | (~Thunderbi@dslb-088-064-063-125.088.064.pools.vodafone-ip.de) (Ping timeout: 246 seconds) |
2020-12-30 10:59:44 +0100 | <Uniaika> | [exa]: or, you do it like a functional programmer |
2020-12-30 11:00:01 +0100 | <Uniaika> | you design an Algebra faithfully representing the scope and depth of your problem |
2020-12-30 11:00:20 +0100 | <[exa]> | I actually have that already |
2020-12-30 11:00:24 +0100 | <Uniaika> | then you make a DSL that can be used to solve this problem |
2020-12-30 11:00:32 +0100 | <Uniaika> | make sure it's safe-by-construction |
2020-12-30 11:00:42 +0100 | <Uniaika> | and finally you've written a safer Lua :D |
2020-12-30 11:00:49 +0100 | <Uniaika> | ah, wonderful |
2020-12-30 11:00:57 +0100 | <Uniaika> | then leave the implementation detail to the reader! |
2020-12-30 11:01:01 +0100 | <Uniaika> | :^) |
2020-12-30 11:01:49 +0100 | <[exa]> | the whole thing is a DFA that sometimes outputs "hey there's a new {whitespace|content} token here" |
2020-12-30 11:02:03 +0100 | <kritzefitz> | And since GHC is available as a library, having a DSL for your algebra is suddenly so “easy”. |
2020-12-30 11:02:18 +0100 | <[exa]> | kritzefitz: teasing. |
2020-12-30 11:02:58 +0100 | <kritzefitz> | Sorry |
2020-12-30 11:03:47 +0100 | <Uniaika> | haha |
2020-12-30 11:03:50 +0100 | <[exa]> | oh don't worry, you are right technically |
2020-12-30 11:03:51 +0100 | <Uniaika> | heya kritzefitz |
2020-12-30 11:05:44 +0100 | <[exa]> | background: I had a student who did a bachelor thesis on diff/diff3/patch that can patch e.g. single words in a paragraph and merging survives whitespace mismatches; all of that configurable with custom tokenizer |
2020-12-30 11:05:45 +0100 | hiroaki_ | (~hiroaki@ip4d168e73.dynamic.kabel-deutschland.de) |
2020-12-30 11:06:57 +0100 | <[exa]> | catch: it seems that he kindof failed by his own choice, but I want the tool to be able to reasonably merge latex docs with git etc |
2020-12-30 11:07:26 +0100 | <[exa]> | and it actually works but the current method of specifying the custom tokenizers is a mess |
2020-12-30 11:08:24 +0100 | <Uniaika> | My sad, practical advice from earlier still stands |
2020-12-30 11:08:52 +0100 | Uniaika | is an industrial Haskeller 😎 |
2020-12-30 11:09:20 +0100 | <[exa]> | so I rewrote the whole thing to ~300 lines of haskell and now I don't really want to spend more than another 300 lines of code on the input specification :D |
2020-12-30 11:09:56 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds) |
2020-12-30 11:10:47 +0100 | o1lo01ol1o | (~o1lo01ol1@31.22.145.144) |
2020-12-30 11:10:48 +0100 | <Uniaika> | [exa]: any chance this would become open-source? |
2020-12-30 11:10:50 +0100 | <kritzefitz> | I haven't thought about it too deeply, but from your description the custom tokenization sounds like the most complex part of your description. |
2020-12-30 11:11:00 +0100 | <[exa]> | Uniaika: yeah working on that now :] |
2020-12-30 11:11:38 +0100 | <[exa]> | in fact I guess I can just push the intermediate state to github now |
2020-12-30 11:12:18 +0100 | <Uniaika> | [exa]: lovely :) |
2020-12-30 11:12:57 +0100 | <[exa]> | like, you ever tried to merge 2 tex docs with git, right? |
2020-12-30 11:13:33 +0100 | <[exa]> | similar fun for markdown with paragraphs broken at 80cols, etc |
2020-12-30 11:13:55 +0100 | <kritzefitz> | I actually have done the latter several time, but I think now I'm gonna have nightmares about the former. |
2020-12-30 11:14:52 +0100 | <Uniaika> | [exa]: I actually never did have to git + tex |
2020-12-30 11:14:55 +0100 | <Uniaika> | but I feel your pain |
2020-12-30 11:15:29 +0100 | o1lo01ol1o | (~o1lo01ol1@31.22.145.144) (Ping timeout: 256 seconds) |
2020-12-30 11:15:43 +0100 | <[exa]> | the best part is of the workflow is: fix a word in a middle of the paragraph -> reflow to 80cols -> the rest of the paragraph gets marked as a difference&collides |
2020-12-30 11:16:41 +0100 | <[exa]> | ok let's give a bit of credit to the student first, so that there's no problem if he ever decides to push himself to finish the thesis |
2020-12-30 11:22:33 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 11:22:50 +0100 | xff0x_ | (~fox@2001:1a81:5361:7200:f380:27a:9a5d:7c68) (Ping timeout: 264 seconds) |
2020-12-30 11:23:28 +0100 | xff0x_ | (~fox@2001:1a81:5361:7200:385b:388d:c84e:fce8) |
2020-12-30 11:24:13 +0100 | jassob | (~jassob@korrob.vth.sgsnet.se) (Ping timeout: 264 seconds) |
2020-12-30 11:25:21 +0100 | cole-h | (~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) (Ping timeout: 265 seconds) |
2020-12-30 11:26:06 +0100 | gzj | (~gzj@unaffiliated/gzj) (Remote host closed the connection) |
2020-12-30 11:26:26 +0100 | gzj | (~gzj@unaffiliated/gzj) |
2020-12-30 11:26:59 +0100 | Ariakenom | (~Ariakenom@2001:9b1:efb:fc00:6963:1023:8668:d646) |
2020-12-30 11:27:02 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Ping timeout: 264 seconds) |
2020-12-30 11:27:59 +0100 | jassob | (~jassob@korrob.vth.sgsnet.se) |
2020-12-30 11:30:13 +0100 | Kronic | (~Kronic___@84.203.96.46) (Ping timeout: 264 seconds) |
2020-12-30 11:31:16 +0100 | dolio | (~dolio@haskell/developer/dolio) (Ping timeout: 240 seconds) |
2020-12-30 11:31:18 +0100 | bitmagie | (~Thunderbi@200116b80684bd0008a0a917606ec592.dip.versatel-1u1.de) |
2020-12-30 11:31:22 +0100 | zangi | (~azure@103.154.230.250) |
2020-12-30 11:31:39 +0100 | dolio | (~dolio@haskell/developer/dolio) |
2020-12-30 11:32:36 +0100 | jassob | (~jassob@korrob.vth.sgsnet.se) (Ping timeout: 265 seconds) |
2020-12-30 11:34:03 +0100 | jassob | (~jassob@korrob.vth.sgsnet.se) |
2020-12-30 11:35:04 +0100 | ADG1089__ | (~aditya@223.235.213.117) (Remote host closed the connection) |
2020-12-30 11:35:45 +0100 | eldritch | (~eldritch@unaffiliated/eldritch) (Ping timeout: 272 seconds) |
2020-12-30 11:35:56 +0100 | drewolson | (~drewolson@64.227.24.16) (Ping timeout: 240 seconds) |
2020-12-30 11:36:01 +0100 | eldritch | (~eldritch@unaffiliated/eldritch) |
2020-12-30 11:36:17 +0100 | drewolson | (~drewolson@64.227.24.16) |
2020-12-30 11:36:57 +0100 | ADG1089__ | (~aditya@223.235.213.117) |
2020-12-30 11:37:15 +0100 | vicfred | (vicfred@gateway/vpn/mullvad/vicfred) (Quit: Leaving) |
2020-12-30 11:37:53 +0100 | m0rphism | (~m0rphism@HSI-KBW-085-216-104-059.hsi.kabelbw.de) |
2020-12-30 11:37:57 +0100 | da39a3ee5e6b4b0d | (~da39a3ee5@2403:6200:8876:f14e:750f:83e8:c56e:b09f) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 11:39:16 +0100 | jvanbure | (~jvanbure@159.65.233.183) (Ping timeout: 240 seconds) |
2020-12-30 11:39:34 +0100 | jvanbure | (~jvanbure@159.65.233.183) |
2020-12-30 11:39:36 +0100 | luigy | (~luigy@104.236.106.229) (Ping timeout: 240 seconds) |
2020-12-30 11:39:44 +0100 | luigy | (~luigy@104.236.106.229) |
2020-12-30 11:40:16 +0100 | plutoniix | (~q@ppp-27-55-68-230.revip3.asianet.co.th) |
2020-12-30 11:40:56 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 11:43:19 +0100 | ADG1089__ | (~aditya@223.235.213.117) (Remote host closed the connection) |
2020-12-30 11:44:16 +0100 | brettgilio | (~brettgili@brettgilio.com) (Ping timeout: 240 seconds) |
2020-12-30 11:45:45 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds) |
2020-12-30 11:45:50 +0100 | brettgilio | (~brettgili@brettgilio.com) |
2020-12-30 11:50:22 +0100 | p-core | (~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56) (Quit: p-core) |
2020-12-30 11:50:39 +0100 | p-core | (~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56) |
2020-12-30 11:50:45 +0100 | christo | (~chris@81.96.113.213) (Remote host closed the connection) |
2020-12-30 11:50:48 +0100 | <gentauro> | so I'm generating code based on data source. As I'm generating `sum types`, it's mandatory for the case-constructos to be `uppercase`. Is there a `good` symbol for this? |
2020-12-30 11:51:23 +0100 | christo | (~chris@81.96.113.213) |
2020-12-30 11:51:44 +0100 | <gentauro> | I'm thinking about capital lambda `Λ` or capital delta `Δ` but I guess it would be to `meh` if people want to type the sum type … |
2020-12-30 11:51:59 +0100 | gentauro | (unless they are greek ofc) |
2020-12-30 11:52:37 +0100 | <lortabac> | I would add a 'Con_' prefix |
2020-12-30 11:52:40 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 11:52:56 +0100 | <lortabac> | or 'C_' |
2020-12-30 11:53:01 +0100 | ADG1089__ | (~aditya@223.235.213.117) |
2020-12-30 11:53:36 +0100 | <kritzefitz> | Can you just uppercase the first character of the name you were already using? |
2020-12-30 11:53:42 +0100 | <gentauro> | lortabac: yea, it something like that I'm looking for |
2020-12-30 11:54:07 +0100 | <gentauro> | kritzefitz: in some cases yes, but others, the data is like "1. …" |
2020-12-30 11:54:14 +0100 | <gentauro> | so that's the problematic part |
2020-12-30 11:54:36 +0100 | sdrodge | (~sdrodge@unaffiliated/sdrodge) (Quit: WeeChat 3.0) |
2020-12-30 11:55:37 +0100 | christo | (~chris@81.96.113.213) (Ping timeout: 246 seconds) |
2020-12-30 11:56:13 +0100 | <[exa]> | Uniaika: (potentially kritzefitz) -- I uploaded it here: https://gitea.blesmrt.net/exa/adiff |
2020-12-30 11:56:20 +0100 | <Uniaika> | awesome |
2020-12-30 11:56:24 +0100 | bor0 | (~boro@unaffiliated/boro/x-000000001) |
2020-12-30 11:56:47 +0100 | sdrodge | (~sdrodge@unaffiliated/sdrodge) |
2020-12-30 11:56:52 +0100 | <Uniaika> | brilliant |
2020-12-30 11:56:57 +0100 | <Uniaika> | thanks [exa] :) |
2020-12-30 11:57:07 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 258 seconds) |
2020-12-30 11:58:00 +0100 | <[exa]> | like, I'd welcome any ideas on e.g. how to tackle unicode on input |
2020-12-30 11:58:57 +0100 | <[exa]> | some parts suck, esp. escaping/un-escaping the regexes and everything (regex-tdfa does not support \n \t etc) |
2020-12-30 12:01:07 +0100 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) (Ping timeout: 265 seconds) |
2020-12-30 12:01:17 +0100 | <kritzefitz> | [exa], thank! It looks really interesting, but I'm afraid I'm not gonna have time (and energy) to properly look into it. |
2020-12-30 12:03:16 +0100 | <[exa]> | it's a slow off-time project anyway, I don't expect much activity :D |
2020-12-30 12:08:30 +0100 | <Uniaika> | did you folks see quad-ci? the CI server/runner in haskell? |
2020-12-30 12:08:35 +0100 | <Uniaika> | it looks really neat |
2020-12-30 12:08:55 +0100 | <Uniaika> | https://github.com/alpacaaa/quad-ci/ |
2020-12-30 12:09:40 +0100 | coot | (~coot@37.30.55.131.nat.umts.dynamic.t-mobile.pl) |
2020-12-30 12:09:44 +0100 | <[exa]> | (one fun thing I learned: if you run Levenshtein algorithm from both sides and sum the matrix weights, you will get a nice map where the optimal diff paths are all on the same "minimum" value.) |
2020-12-30 12:10:24 +0100 | <Uniaika> | [exa]: oh! |
2020-12-30 12:10:27 +0100 | <Uniaika> | that's interesting :) |
2020-12-30 12:10:49 +0100 | <[exa]> | Uniaika: quad-ci looks pretty minimal, that's good |
2020-12-30 12:10:54 +0100 | <Uniaika> | yeah |
2020-12-30 12:11:00 +0100 | <Uniaika> | might use it for my own stuff |
2020-12-30 12:14:27 +0100 | <[exa]> | hm, Simple Haskell |
2020-12-30 12:14:40 +0100 | LKoen | (~LKoen@126.170.9.109.rev.sfr.net) |
2020-12-30 12:15:05 +0100 | <[exa]> | we should have a better name for this principle, "keep the stuff tiny so that it can be fixed" |
2020-12-30 12:15:08 +0100 | rmk236 | (~lcampos@2a02:908:3616:b100:849c:a12b:ff95:e193) |
2020-12-30 12:15:36 +0100 | <Uniaika> | [exa]: it doesn't fit on a README badge :P |
2020-12-30 12:16:41 +0100 | <[exa]> | lol |
2020-12-30 12:17:02 +0100 | notzmv | (~user@unaffiliated/zmv) (Remote host closed the connection) |
2020-12-30 12:17:54 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 12:24:05 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 12:28:27 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Ping timeout: 260 seconds) |
2020-12-30 12:29:10 +0100 | toorevitimirp | (~tooreviti@117.182.181.108) |
2020-12-30 12:29:23 +0100 | bor0 | (~boro@unaffiliated/boro/x-000000001) (Quit: This computer has gone to sleep) |
2020-12-30 12:29:48 +0100 | <arahael> | Occam's Razor? |
2020-12-30 12:34:16 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 12:36:02 +0100 | zangi | (~azure@103.154.230.250) (Ping timeout: 272 seconds) |
2020-12-30 12:36:19 +0100 | zangi | (~azure@103.154.230.250) |
2020-12-30 12:37:21 +0100 | <ADG1089__> | spawnPipe :: MonadIO m => String -> m Handle (Launch an external application through the system shell and return a Handle to its standard input.); How can i spawn and get handle to stdout instead? |
2020-12-30 12:37:33 +0100 | <[exa]> | arahael: "less entropy is more probable"...not sure it applies to programs seamlessly |
2020-12-30 12:38:03 +0100 | ericsagn1 | (~ericsagne@2405:6580:0:5100:fcdb:75f:452b:6812) |
2020-12-30 12:38:57 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 260 seconds) |
2020-12-30 12:39:13 +0100 | <[exa]> | ADG1089__: it should be doable by just copying the spawnPipe definition and creating/dup2ing one additional pipe |
2020-12-30 12:39:16 +0100 | cheater | (~user@unaffiliated/cheater) (Ping timeout: 240 seconds) |
2020-12-30 12:39:24 +0100 | <arahael> | [exa]: Possibly not. |
2020-12-30 12:39:42 +0100 | <[exa]> | ADG1089__: (copy from here: https://hackage.haskell.org/package/xmonad-contrib-0.16/docs/src/XMonad.Util.Run.html#spawnPipe ) |
2020-12-30 12:40:32 +0100 | <[exa]> | arahael: if a program is taken as an explanation of the external effect perhaps, kindof in a curryhowardish way |
2020-12-30 12:40:49 +0100 | ericsagnes | (~ericsagne@2405:6580:0:5100:7c82:3285:3449:9fb4) (Ping timeout: 258 seconds) |
2020-12-30 12:40:50 +0100 | <[exa]> | but that doesn't imply that the effects themselves should be kept simple |
2020-12-30 12:40:55 +0100 | <arahael> | [exa]: It's 10:40 pm here, this is getting *way* too academic now. :D |
2020-12-30 12:41:17 +0100 | <[exa]> | ok worry not, I likely had too much coffee |
2020-12-30 12:41:43 +0100 | <arahael> | [exa]: I've also not had enough coffee! But I'm not about to catch up at this hour! :D |
2020-12-30 12:42:44 +0100 | gentauro | (~gentauro@unaffiliated/gentauro) (Read error: Connection reset by peer) |
2020-12-30 12:43:07 +0100 | o1lo01ol1o | (~o1lo01ol1@31.22.145.144) |
2020-12-30 12:43:23 +0100 | <dminuoso> | Are all ANSI control sequences encodable in ASCII? |
2020-12-30 12:43:25 +0100 | gentauro | (~gentauro@unaffiliated/gentauro) |
2020-12-30 12:44:06 +0100 | o1lo01ol1o | (~o1lo01ol1@31.22.145.144) (Remote host closed the connection) |
2020-12-30 12:44:09 +0100 | <dminuoso> | The wikipedia article suggests that only most use ASCII escape \033 |
2020-12-30 12:45:46 +0100 | pavonia | (~user@unaffiliated/siracusa) |
2020-12-30 12:46:19 +0100 | o1lo01ol1o | (~o1lo01ol1@31.22.145.144) |
2020-12-30 12:49:24 +0100 | <ADG1089__> | [exa]: thanks! |
2020-12-30 12:49:55 +0100 | kuribas | (~user@ptr-25vy0i8109xerw15t0a.18120a2.ip6.access.telenet.be) |
2020-12-30 12:50:49 +0100 | o1lo01ol1o | (~o1lo01ol1@31.22.145.144) (Remote host closed the connection) |
2020-12-30 12:52:20 +0100 | <[exa]> | dminuoso: afaik these in iso2022 all have a 7bit ascii representation where the only "non-printable" character is the actual escape |
2020-12-30 12:52:23 +0100 | madjest11 | (~Android@31-161-157-155.mobile.kpn.net) |
2020-12-30 12:52:30 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 272 seconds) |
2020-12-30 12:53:34 +0100 | xff0x_ | (~fox@2001:1a81:5361:7200:385b:388d:c84e:fce8) (Remote host closed the connection) |
2020-12-30 12:53:52 +0100 | xff0x_ | (~fox@2001:1a81:5361:7200:f921:dfdc:3d2e:f65) |
2020-12-30 12:54:14 +0100 | b4er | (~b5er_@91.193.4.138) (Ping timeout: 256 seconds) |
2020-12-30 12:54:39 +0100 | madjestic | (~Android@86-88-72-244.fixed.kpn.net) (Ping timeout: 256 seconds) |
2020-12-30 12:54:48 +0100 | ph88 | (~ph88@2a02:8109:9e00:7e5c:cce3:aa71:9586:6387) |
2020-12-30 12:57:03 +0100 | madjest11 | (~Android@31-161-157-155.mobile.kpn.net) (Read error: Connection reset by peer) |
2020-12-30 12:57:19 +0100 | <dminuoso> | [exa]: Mmm alright. |
2020-12-30 12:58:25 +0100 | madjestic | (~Android@31-161-157-155.mobile.kpn.net) |
2020-12-30 12:58:31 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) |
2020-12-30 12:58:35 +0100 | <dminuoso> | I guess this is sufficient. If there are C1 sequences that do not have an escape sequence representation, then that's not my problem anymore. |
2020-12-30 12:58:43 +0100 | rayyyy | (~nanoz@gateway/tor-sasl/nanoz) (Remote host closed the connection) |
2020-12-30 12:59:07 +0100 | rayyyy | (~nanoz@gateway/tor-sasl/nanoz) |
2020-12-30 13:00:31 +0100 | <kuribas> | hmm, I was thinking how often static types can be more general than dynamic types, due to type inference and dispatching on the types. |
2020-12-30 13:01:14 +0100 | <kuribas> | It's possible to do type inference in a dynamic language, but that would end up with more code, not less. |
2020-12-30 13:01:40 +0100 | <dminuoso> | kuribas: Doing type inference in a dynamic language certainly is possible. |
2020-12-30 13:01:42 +0100 | <kuribas> | well, I guess the advantage is being more concise, not more general. |
2020-12-30 13:02:05 +0100 | <kuribas> | dminuoso: possible yes, but it ends up being a heavier solution, not lighter. |
2020-12-30 13:02:06 +0100 | mputz | (~Thunderbi@dslb-088-064-063-125.088.064.pools.vodafone-ip.de) |
2020-12-30 13:02:32 +0100 | <dminuoso> | It depends a bit on the semantics of the language, you get into the turing undecidability fairly quickly. |
2020-12-30 13:02:35 +0100 | <kuribas> | While dynamic proponents often claim dynamic language are lighter |
2020-12-30 13:03:52 +0100 | Anthaas | (~Anthaas@unaffiliated/anthaas) (Ping timeout: 246 seconds) |
2020-12-30 13:04:07 +0100 | <kuribas> | I've found that a dynamic language solution is only lighter (more concise, requiring less modelling, etc...), when you are willing to give up on certain features, like validation, precise error handling, etc... |
2020-12-30 13:04:54 +0100 | <kuribas> | my haskell code usually ends up being less lines than the lisp/clojure/scheme equivalent. |
2020-12-30 13:06:01 +0100 | <kuribas> | dminuoso: so you end up using something like clojure spec, which is heavier, not lighter than ADTs + type classes IMO. |
2020-12-30 13:06:33 +0100 | Anthaas | (~Anthaas@unaffiliated/anthaas) |
2020-12-30 13:06:36 +0100 | <kuribas> | I also find that heavy type machinery leads to less flexible code, not more flexible code. |
2020-12-30 13:07:52 +0100 | <kuribas> | and Functor/Applicative/Monad/Monoid, are a more flexible way to create libraries than type level stuff. |
2020-12-30 13:09:52 +0100 | ericsagn1 | (~ericsagne@2405:6580:0:5100:fcdb:75f:452b:6812) (Ping timeout: 260 seconds) |
2020-12-30 13:09:54 +0100 | pera | (~pera@unaffiliated/pera) (Quit: leaving) |
2020-12-30 13:11:44 +0100 | olligobber | (~olligobbe@unaffiliated/olligobber) |
2020-12-30 13:14:34 +0100 | _noblegas | (uid91066@gateway/web/irccloud.com/x-hltwtxmffoclzdwc) |
2020-12-30 13:14:48 +0100 | <kuribas> | "heavier" is of course subjective, some people may find modelling types to be hard. But I just don't see much difference between modelling a type using an ADT or using clojure spec. |
2020-12-30 13:15:59 +0100 | mputz | (~Thunderbi@dslb-088-064-063-125.088.064.pools.vodafone-ip.de) (Ping timeout: 260 seconds) |
2020-12-30 13:16:02 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 13:16:12 +0100 | Kronic | (~Kronic___@84.203.96.46) |
2020-12-30 13:17:21 +0100 | ericsagnes | (~ericsagne@2405:6580:0:5100:1a8:463f:5e1d:212e) |
2020-12-30 13:17:26 +0100 | <Kronic> | Is there a nice way to do varargs in Haskell? I seen the examples online but I found them to be pretty complex for something that I would have imagined to be so easy, is there some extension I can use to get this? |
2020-12-30 13:18:00 +0100 | <kuribas> | Kronic: the only way is using type classes. |
2020-12-30 13:18:07 +0100 | <kuribas> | and overloading (->) |
2020-12-30 13:18:25 +0100 | <kuribas> | varargs are often a code small IMO |
2020-12-30 13:18:28 +0100 | <kuribas> | haskell isn't lisp |
2020-12-30 13:18:38 +0100 | LKoen_ | (~LKoen@126.170.9.109.rev.sfr.net) |
2020-12-30 13:18:38 +0100 | <kuribas> | code smell |
2020-12-30 13:19:20 +0100 | <kuribas> | For example formatting vs printf. formatting is more idiomatic haskell. |
2020-12-30 13:19:48 +0100 | <Kronic> | Okay, well I'll give you my scenario and you can tell me if you think that VarArgs are appropriate in that case. I'm working on a chatbot, and I'm currently building a representation for commands. In doing so, I have a Command Record which defines an execute function, which pending on the command would be polyvariadic |
2020-12-30 13:20:25 +0100 | <dminuoso> | Kronic: Probably not. :) |
2020-12-30 13:20:32 +0100 | <Kronic> | Okay, I thought so :) |
2020-12-30 13:20:37 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Ping timeout: 260 seconds) |
2020-12-30 13:20:45 +0100 | <dminuoso> | Kronic: You're generally better off writing a data type and an evaluator for that data type. |
2020-12-30 13:21:03 +0100 | <dminuoso> | Then the variability can be encoded into, say, a list. |
2020-12-30 13:21:21 +0100 | LKoen | (~LKoen@126.170.9.109.rev.sfr.net) (Ping timeout: 265 seconds) |
2020-12-30 13:21:25 +0100 | <lortabac> | commands are a common use case for GADTs |
2020-12-30 13:21:25 +0100 | <Kronic> | That sounds interesting but I don't know how to do that, do you have an example I can read ? |
2020-12-30 13:21:49 +0100 | shailangsa | (~shailangs@host86-186-196-229.range86-186.btcentralplus.com) (Ping timeout: 260 seconds) |
2020-12-30 13:22:25 +0100 | <Kronic> | I've heard about GADTs but never used them. The project I'm working on is purely educational so if there is a route to go here to learn something very useful I'm open to that |
2020-12-30 13:22:38 +0100 | <dminuoso> | You might not even need full blown GADTs. |
2020-12-30 13:22:42 +0100 | <maerwald> | why would you need GADTs for that? |
2020-12-30 13:23:00 +0100 | <kuribas> | Kronic: you can uncurry your tuples, then put the input type in the Command type. |
2020-12-30 13:23:39 +0100 | Entertainment | (~entertain@104.246.132.210) |
2020-12-30 13:23:47 +0100 | <dminuoso> | Kronic: It's hard to give you a good example without knowing a bit more about what you want to be polyvariadic exactly. |
2020-12-30 13:24:00 +0100 | <kuribas> | like data Command input output = Command { commandName :: Text, commandFun :: input -> output } |
2020-12-30 13:24:31 +0100 | <Kronic> | I like that solution kuribas |
2020-12-30 13:24:33 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 13:24:35 +0100 | <Kronic> | Thank you |
2020-12-30 13:24:41 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 13:24:54 +0100 | <kuribas> | Kronic: even easier might be to just make a big sum type for your commands. |
2020-12-30 13:25:05 +0100 | <dminuoso> | I'd opt for the big sum type. :) |
2020-12-30 13:25:13 +0100 | <maerwald> | +1 |
2020-12-30 13:25:27 +0100 | LaserShark | (~LaserShar@185.163.110.125) (Remote host closed the connection) |
2020-12-30 13:25:39 +0100 | <Kronic> | I have a sum type already, I suppose I could pack this information into that |
2020-12-30 13:25:49 +0100 | <dminuoso> | Kronic: So say, you have `data Command = Say Message | Join ChannelRef | Connect URI`, and then some `execteCommand :: Command -> IO ()` |
2020-12-30 13:25:56 +0100 | <dminuoso> | As a very simplistic example |
2020-12-30 13:26:24 +0100 | <Kronic> | That's really nice, glad I asked this question |
2020-12-30 13:27:10 +0100 | <lortabac> | maerwald: you only need GADTs in the most complex case, that is if you have constraints in some commands or if the result type is not uniform |
2020-12-30 13:27:38 +0100 | <maerwald> | lortabac: yeah, so unless you have that complex case I'd avoid GADTs at all cost :) |
2020-12-30 13:27:44 +0100 | <lortabac> | of course |
2020-12-30 13:28:01 +0100 | <kuribas> | Kronic: alternatively you could just compose commands. For example Command :: InputString -> Maybe (IO ErrorMsg) |
2020-12-30 13:28:02 +0100 | <Uniaika> | yeah no need for GADTs here |
2020-12-30 13:28:08 +0100 | <lortabac> | maerwald: but in real life every time I have something called Command I have that complex case :) |
2020-12-30 13:28:09 +0100 | <kuribas> | Kronic: then compose with (<|>) |
2020-12-30 13:28:59 +0100 | <maerwald> | lortabac: I've only encountered one case of GADTs in real life and it wasn't necessary there either :p |
2020-12-30 13:29:03 +0100 | <lortabac> | :) |
2020-12-30 13:29:05 +0100 | <ADG1089__> | @hoogle X a -> IO a |
2020-12-30 13:29:06 +0100 | <lambdabot> | Basement.Monad unsafePrimToIO :: PrimMonad prim => prim a -> IO a |
2020-12-30 13:29:07 +0100 | <lambdabot> | Generic.Data.Internal.Utils coerce' :: Coercible (f x) (g x) => f x -> g x |
2020-12-30 13:29:07 +0100 | <lambdabot> | Control.Effect.Lift sendM :: (Has (Lift n) sig m, Functor n) => n a -> m a |
2020-12-30 13:29:36 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds) |
2020-12-30 13:29:42 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Ping timeout: 260 seconds) |
2020-12-30 13:30:05 +0100 | Mrbuck | (~Mrbuck@gateway/tor-sasl/mrbuck) |
2020-12-30 13:30:26 +0100 | argento | (~argent0@168.227.96.26) |
2020-12-30 13:30:47 +0100 | <Mrbuck> | Hi how recursion works in haskell? |
2020-12-30 13:31:08 +0100 | <Kronic> | spiffingly |
2020-12-30 13:31:13 +0100 | <maerwald> | on assembly level? |
2020-12-30 13:31:29 +0100 | <ADG1089__> | Is there a X transformer for the above? |
2020-12-30 13:31:37 +0100 | <Mrbuck> | output is stored some where untill next next next functions run? |
2020-12-30 13:31:47 +0100 | mputz | (~Thunderbi@dslb-088-064-063-125.088.064.pools.vodafone-ip.de) |
2020-12-30 13:32:20 +0100 | <Mrbuck> | maerwald: tell me howit works on assembly level |
2020-12-30 13:32:24 +0100 | <kuribas> | Mrbuck: like in any language? except lazy |
2020-12-30 13:32:35 +0100 | Stanley00 | (~stanley00@unaffiliated/stanley00) () |
2020-12-30 13:32:37 +0100 | <kuribas> | Mrbuck: assembly level is complicated in haskell |
2020-12-30 13:32:45 +0100 | <kuribas> | and actually unspecified |
2020-12-30 13:32:47 +0100 | binwiederhier1 | (~binwieder@217.146.82.202) |
2020-12-30 13:32:58 +0100 | <kuribas> | you cannot speak about assembly level in haskell, only in a specific compiler, like ghc |
2020-12-30 13:33:06 +0100 | <Mrbuck> | kuribas: ok,and recurion on haskell is fast is it because of az feature? |
2020-12-30 13:33:07 +0100 | <maerwald> | Mrbuck: you could easily examine that by spitting out a foldr and a foldl into assembly |
2020-12-30 13:33:08 +0100 | <Mrbuck> | lazy* |
2020-12-30 13:33:21 +0100 | Melanie | (~Melanie@192-0-134-138.cpe.teksavvy.com) |
2020-12-30 13:33:30 +0100 | <kuribas> | Mrbuck: recursion can be fast or slow. It depends. |
2020-12-30 13:33:47 +0100 | <hpc> | i suggest starting with how a thunk is implemented |
2020-12-30 13:33:56 +0100 | <hpc> | (in ghc) |
2020-12-30 13:34:27 +0100 | <Mrbuck> | ok |
2020-12-30 13:34:57 +0100 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) |
2020-12-30 13:35:12 +0100 | <maerwald> | Mrbuck: https://haskell.godbolt.org/ |
2020-12-30 13:35:19 +0100 | <maerwald> | here you can easily examine assembly |
2020-12-30 13:35:34 +0100 | <hpc> | iirc there's a good explanation somewhere in https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/#the-ghc-commentary |
2020-12-30 13:35:51 +0100 | <Mrbuck> | one doubt if I were to implement a Breadth first or depth first algoroithms I would usewhile loop with help of stack or queue in other langauges how it is done in Haskell....since they are done recursively if I simply use recursion performance can be affectedright? |
2020-12-30 13:36:19 +0100 | <Mrbuck> | maerwald: Ok I will explore it thank you |
2020-12-30 13:36:31 +0100 | <maerwald> | Mrbuck: the interesting thing you should spot is that there is no `call` |
2020-12-30 13:36:39 +0100 | geekosaur | (ac3a8b4c@172.58.139.76) |
2020-12-30 13:36:39 +0100 | guest122` | (~user@49.5.6.87) (Read error: Connection reset by peer) |
2020-12-30 13:37:10 +0100 | <dminuoso> | Mrbuck: I tend to think of a function call in Haskell as a sort of "jump/control transfer". |
2020-12-30 13:37:25 +0100 | <maerwald> | yeah, there are no functions in haskell :p |
2020-12-30 13:37:28 +0100 | guest122` | (~user@49.5.6.87) |
2020-12-30 13:37:34 +0100 | <dminuoso> | Similar to that of a goto from other langauges. |
2020-12-30 13:37:57 +0100 | <dminuoso> | Now, consider, how loops are usually implemented in imperative languages. They are usually (conditional) jumps/gotos. |
2020-12-30 13:38:21 +0100 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) |
2020-12-30 13:38:45 +0100 | <Mrbuck> | Ok I think I understand a little now, I will play and come back again |
2020-12-30 13:39:03 +0100 | usr25 | (~usr25@unaffiliated/usr25) |
2020-12-30 13:39:12 +0100 | <Mrbuck> | Thank you all |
2020-12-30 13:41:20 +0100 | <kuribas> | Mrbuck: don't worry about performance, get something working first. |
2020-12-30 13:41:27 +0100 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) (Client Quit) |
2020-12-30 13:41:33 +0100 | shatriff | (~vitaliish@176-52-216-242.irishtelecom.com) |
2020-12-30 13:42:27 +0100 | <Mrbuck> | kuribas: Yes, actally I am not working directly with haskell bow but implementing some algorithm recursively in another language and then thought if it can be fast in haskell and want to know how it is done here |
2020-12-30 13:42:36 +0100 | <Mrbuck> | s/bow/now* |
2020-12-30 13:42:43 +0100 | <dminuoso> | Mrbuck: So this is generally a difficult thing for several reasons. |
2020-12-30 13:43:00 +0100 | <Mrbuck> | dminuoso: ok |
2020-12-30 13:43:13 +0100 | <dminuoso> | For one, we tend to often represent/structure data and algorithms very differently, in ways that are not just "mimicry of the same ideas" |
2020-12-30 13:43:15 +0100 | __monty__ | (~toonn@unaffiliated/toonn) |
2020-12-30 13:43:56 +0100 | Melanie | (~Melanie@192-0-134-138.cpe.teksavvy.com) (Ping timeout: 256 seconds) |
2020-12-30 13:44:57 +0100 | <dminuoso> | We tend to prefer pure functional data structures (for futher reading consult Okasaki) and algorithms that operate on these instead. |
2020-12-30 13:45:56 +0100 | <Mrbuck> | dminuoso: ok I will check them I forget I have come across that fucntional datastructures talk long back but forgot it |
2020-12-30 13:46:46 +0100 | <ij> | [exa], you meant this one? https://www.microsoft.com/en-us/research/wp-content/uploads/2002/07/inline.pdf |
2020-12-30 13:46:54 +0100 | <Mrbuck> | I think this http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf bookmarked it |
2020-12-30 13:50:17 +0100 | <dminuoso> | Mrbuck: And even then, getting high performance is (generally in any language) a complicated business. There's topics like sharing, strictness, memory allocations, using mutable operations, ensuring fusion happens, etc.. all of this in the presence of a compiler that transforms your program representation. |
2020-12-30 13:50:41 +0100 | <[exa]> | ij: yes |
2020-12-30 13:50:53 +0100 | <dminuoso> | So when you find your implementation is slower in Haskell, the first question should be "why is it that way" |
2020-12-30 13:51:26 +0100 | solarliner | (~solarline@243.81.10.109.rev.sfr.net) |
2020-12-30 13:51:35 +0100 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) |
2020-12-30 13:51:40 +0100 | <Mrbuck> | dminuoso: ok got it |
2020-12-30 13:52:06 +0100 | gzj | (~gzj@unaffiliated/gzj) (Remote host closed the connection) |
2020-12-30 13:52:27 +0100 | gzj | (~gzj@unaffiliated/gzj) |
2020-12-30 13:54:29 +0100 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) (Client Quit) |
2020-12-30 13:54:38 +0100 | da39a3ee5e6b4b0d | (~da39a3ee5@171.5.28.247) |
2020-12-30 13:54:50 +0100 | <solarliner> | Hi, it's maybe a noob question here, but I have a bunch of `Context -> IO a`, and I'd like to use them without wrapping them, in a monadic context that provides both a Context reader and IO |
2020-12-30 13:55:24 +0100 | lazyshrk | (~lazyshrk@128.199.58.13) (Quit: ZNC 1.8.2 - https://znc.in) |
2020-12-30 13:55:33 +0100 | <ij> | I read the data types a la carte paper – it seems really unintuitive to program something that way. Is anyone using it for actual code |
2020-12-30 13:55:35 +0100 | <dminuoso> | solarliner: Put it inside `Reader` :) |
2020-12-30 13:55:36 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 13:55:52 +0100 | <dminuoso> | solarliner: Oh wait, do you mean you just have `MonadReader Context` and `MonadIO`? |
2020-12-30 13:56:08 +0100 | lazyshrk | (~lazyshrk@128.199.58.13) |
2020-12-30 13:57:01 +0100 | <dminuoso> | Either way, you cant use them directly. Either you have to `liftIO (f =<< ask)`, or you need to hoist/wrap them into your monad. |
2020-12-30 13:57:33 +0100 | <kritzefitz> | dminuoso, I think you mean `liftIO . f =<< ask`. |
2020-12-30 13:57:47 +0100 | <solarliner> | Well, my use case is a library which provides the monadic context and the functions, and the users use the functions within the monadic context, if possible without having to lift or wrap anything explicitely (for ergonomics), and without having me wrap each function individually (because I'm lazy lol) |
2020-12-30 13:57:52 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 13:57:59 +0100 | shailangsa | (~shailangs@host86-185-58-185.range86-185.btcentralplus.com) |
2020-12-30 13:58:00 +0100 | <dminuoso> | kritzefitz: Ah yeah. |
2020-12-30 13:58:23 +0100 | <solarliner> | I don't have too much in the way of a concrete implementation yet, I'm just thinking about the design of the library |
2020-12-30 13:58:52 +0100 | knupfer | (~Thunderbi@mue-88-130-61-254.dsl.tropolys.de) |
2020-12-30 13:59:05 +0100 | <kritzefitz> | solarliner, If your `Context -> IO a`s are actually monomorphic, I think there is no way to use them without wrapping or listing explicitly. |
2020-12-30 13:59:09 +0100 | <dminuoso> | solarliner: You could write your functions polymorphic: `f :: (MonadReader Context m, MonadIO m) => m T`, and they can use it appropriately |
2020-12-30 13:59:47 +0100 | bitmagie | (~Thunderbi@200116b80684bd0008a0a917606ec592.dip.versatel-1u1.de) (Quit: bitmagie) |
2020-12-30 14:00:28 +0100 | <solarliner> | Right, okay; I imagine that wouldn't work well with FFI though, so I'd have to still do some wrapping |
2020-12-30 14:00:37 +0100 | <dminuoso> | Why wouldn't it? |
2020-12-30 14:00:43 +0100 | <dminuoso> | With MonadIO you can do full FFI |
2020-12-30 14:00:51 +0100 | <dminuoso> | You just need IO :) |
2020-12-30 14:00:54 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) (Remote host closed the connection) |
2020-12-30 14:01:00 +0100 | Vulfe | (~vulfe@2600:1702:31b0:34e0:3dea:7cc:1ee9:85fe) |
2020-12-30 14:01:57 +0100 | <solarliner> | Alright, thanks for the quick answers, I'll dig more into that |
2020-12-30 14:01:59 +0100 | <dminuoso> | The two problems I just see with this, is that this can deter in-experienced users, and if this is to be used in hot code paths, mtl-style polymorphic code tends to prevent inlining. |
2020-12-30 14:02:30 +0100 | <dminuoso> | (at least without additional work) |
2020-12-30 14:02:59 +0100 | <solarliner> | Inexperienced users are the primary target of the library, yeah, I don't want to have users deal with too much monadic plumbing if possible, to make reasoning about the code easier conceptually |
2020-12-30 14:03:18 +0100 | <dminuoso> | Then just go with `Context -> IO T` |
2020-12-30 14:03:25 +0100 | plutoniix | (~q@ppp-27-55-68-230.revip3.asianet.co.th) (Quit: Leaving) |
2020-12-30 14:03:31 +0100 | <dminuoso> | If the user is inside another monad, it's their responsibility. |
2020-12-30 14:03:41 +0100 | <dminuoso> | I might consider writing it polymorphic over MonadIO, possibly. |
2020-12-30 14:04:12 +0100 | <zangi> | I'm still learning monad, but is it possible to have a state without monad? |
2020-12-30 14:04:19 +0100 | <dminuoso> | Yes. |
2020-12-30 14:04:23 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) (Ping timeout: 260 seconds) |
2020-12-30 14:04:53 +0100 | <ski> | just thread the versions of your state through parameters, and possibly results |
2020-12-30 14:05:20 +0100 | <ski> | (this is what `State' and `StateT' does, behind the covers, anyway) |
2020-12-30 14:05:22 +0100 | <dminuoso> | zangi: Monad is not something magical, it just presents a unified interface for common operations. You can use the same operations without the interface just fine. |
2020-12-30 14:06:37 +0100 | <zangi> | any code example? |
2020-12-30 14:06:39 +0100 | <ski> | > takeWhile (< 1000) (iterate (2 *) 1) -- a simple version of iterating on a state |
2020-12-30 14:06:41 +0100 | <lambdabot> | [1,2,4,8,16,32,64,128,256,512] |
2020-12-30 14:07:01 +0100 | <dminuoso> | zangi: The manual method is by setting up a function and encoding the state as a parameter. |
2020-12-30 14:07:10 +0100 | <ski> | zangi : do you know accumulator-passing style ? |
2020-12-30 14:07:27 +0100 | <zangi> | f x acc? sure |
2020-12-30 14:07:33 +0100 | <dminuoso> | So say `f :: Int -> (Int, Char)` depends on some "input state", produces a result of type Char, along with a (possibly modified) state of type Int. |
2020-12-30 14:07:36 +0100 | <dminuoso> | zangi: ^- |
2020-12-30 14:07:50 +0100 | <ski> | `acc' is a state, that is passed downwards (assuming you have linear recursion) |
2020-12-30 14:07:51 +0100 | madjestic | (~Android@31-161-157-155.mobile.kpn.net) (Read error: Connection reset by peer) |
2020-12-30 14:08:33 +0100 | Melanie | (~Melanie@192-0-134-138.cpe.teksavvy.com) |
2020-12-30 14:08:36 +0100 | <ski> | if you also want to pass it "upwards", that is "threading it" in and out of (some) function calls, you'll also have to return it as the result of functions (possibly together with another, "main", result) |
2020-12-30 14:08:44 +0100 | <dminuoso> | zangi: the State monad is *exactly* this, except it hides the tedious passing of this Int to the user. :) |
2020-12-30 14:08:56 +0100 | Nucleo | (~textual@mskresolve-a.mskcc.org) |
2020-12-30 14:09:07 +0100 | <dminuoso> | (when I say exactly I dont just mean semantically, but what it internally does) |
2020-12-30 14:09:08 +0100 | Nucleo | Guest37372 |
2020-12-30 14:09:41 +0100 | Guest37372 | (~textual@mskresolve-a.mskcc.org) (Client Quit) |
2020-12-30 14:10:04 +0100 | <ski> | zangi : exercise, given `data Tree a = Tip | Node (Tree a) a (Tree a)', write a function `labelTree :: Tree a -> Tree (Integer,a)' that labels the elements with natural numbers (from `0' upwards), using in-order traversal |
2020-12-30 14:10:08 +0100 | Alleria | (~textual@zrcout.mskcc.org) |
2020-12-30 14:10:19 +0100 | lazyshrk | (~lazyshrk@128.199.58.13) (Quit: ZNC 1.8.2 - https://znc.in) |
2020-12-30 14:10:32 +0100 | Alleria | Guest67343 |
2020-12-30 14:11:03 +0100 | lazyshrk | (~lazyshrk@128.199.58.13) |
2020-12-30 14:11:08 +0100 | madjestic | (~Android@86-88-72-244.fixed.kpn.net) |
2020-12-30 14:12:26 +0100 | <ski> | (then, you could compare with a monadic, and an idiomatic, solution, using operations from `Monad' resp. `Applicative' on `State Integer') |
2020-12-30 14:14:57 +0100 | usr25 | (~usr25@unaffiliated/usr25) (Quit: Leaving) |
2020-12-30 14:16:37 +0100 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) |
2020-12-30 14:18:53 +0100 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) (Client Quit) |
2020-12-30 14:19:17 +0100 | unlink2 | (~unlink2@p200300ebcf259600e4593ff5d42812d3.dip0.t-ipconnect.de) (Remote host closed the connection) |
2020-12-30 14:19:20 +0100 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) |
2020-12-30 14:19:36 +0100 | unlink2 | (~unlink2@p200300ebcf259600e4593ff5d42812d3.dip0.t-ipconnect.de) |
2020-12-30 14:22:58 +0100 | Mikagami | (~MOSCOS@122.54.107.175) (Remote host closed the connection) |
2020-12-30 14:23:22 +0100 | Mikagami | (~MOSCOS@122.54.107.175) |
2020-12-30 14:24:49 +0100 | knupfer | (~Thunderbi@mue-88-130-61-254.dsl.tropolys.de) (Ping timeout: 260 seconds) |
2020-12-30 14:27:32 +0100 | da39a3ee5e6b4b0d | (~da39a3ee5@171.5.28.247) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 14:29:01 +0100 | toorevitimirp | (~tooreviti@117.182.181.108) (Ping timeout: 264 seconds) |
2020-12-30 14:29:37 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
2020-12-30 14:30:05 +0100 | urodna | (~urodna@unaffiliated/urodna) |
2020-12-30 14:30:27 +0100 | binwiederhier1 | (~binwieder@217.146.82.202) (Remote host closed the connection) |
2020-12-30 14:35:06 +0100 | gzj | (~gzj@unaffiliated/gzj) (Remote host closed the connection) |
2020-12-30 14:38:10 +0100 | sunetoft | (~sunetoft@178.239.168.171) |
2020-12-30 14:41:38 +0100 | ward_ | (~ward@ptr-1u4szschif2qqvply2m.18120a2.ip6.access.telenet.be) |
2020-12-30 14:43:50 +0100 | coot | (~coot@37.30.55.131.nat.umts.dynamic.t-mobile.pl) (Quit: coot) |
2020-12-30 14:46:03 +0100 | da39a3ee5e6b4b0d | (~da39a3ee5@171.5.28.247) |
2020-12-30 14:47:09 +0100 | berberman_ | (~berberman@unaffiliated/berberman) |
2020-12-30 14:47:53 +0100 | berberman | (~berberman@unaffiliated/berberman) (Ping timeout: 268 seconds) |
2020-12-30 14:49:05 +0100 | p-core1 | (~Thunderbi@koleje-wifi-0045.koleje.cuni.cz) |
2020-12-30 14:49:14 +0100 | ericsagnes | (~ericsagne@2405:6580:0:5100:1a8:463f:5e1d:212e) (Ping timeout: 258 seconds) |
2020-12-30 14:49:24 +0100 | <ward_> | Hi, I have a third-party haskell app that needs to run on a server with 16 cpu cores. I'm suspecting it runs slows because it uses too many threads so I'm looking for a way to limit it to 1-2 threads. In the cabal file the following options are set: `ghc-options: -threaded -rtsopts -with-rtsopts=-N`. I tried setting `GHCRTS="-maxN2"` as an environment variable but it seems to be ignored. Is there a way to achieve this |
2020-12-30 14:49:24 +0100 | <ward_> | without recompiling? |
2020-12-30 14:50:10 +0100 | <kuribas> | ward_: green threads or OS threads? |
2020-12-30 14:50:15 +0100 | <kuribas> | green threads are very cheap |
2020-12-30 14:50:23 +0100 | p-core | (~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56) (Ping timeout: 258 seconds) |
2020-12-30 14:50:23 +0100 | p-core1 | p-core |
2020-12-30 14:50:37 +0100 | <ward_> | I can see them in htop, so OS threads? |
2020-12-30 14:51:55 +0100 | <kuribas> | pass -RTS -N=1 to the program? |
2020-12-30 14:52:33 +0100 | <kuribas> | erm +RTS -N1 -RTS |
2020-12-30 14:52:46 +0100 | <geekosaur> | +RTS -N1 -qg -RTS |
2020-12-30 14:52:48 +0100 | <ward_> | as a runtime argument? |
2020-12-30 14:52:54 +0100 | <geekosaur> | yes |
2020-12-30 14:53:19 +0100 | <geekosaur> | replace 1 with the number of OS threads you want |
2020-12-30 14:54:21 +0100 | <siraben> | ski: I love that exercise, I first saw it in http://okmij.org/ftp/Scheme/monad-in-Scheme.html |
2020-12-30 14:54:52 +0100 | darjeeling_ | (~darjeelin@122.245.217.190) (Ping timeout: 260 seconds) |
2020-12-30 14:57:30 +0100 | elfets | (~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) |
2020-12-30 14:57:53 +0100 | <ski> | i don't recall where i saw it |
2020-12-30 14:57:59 +0100 | rdivyanshu | (uid322626@gateway/web/irccloud.com/x-azqolmgutgadssur) (Quit: Connection closed for inactivity) |
2020-12-30 14:59:43 +0100 | pfurla | (~pfurla@ool-182ed2e2.dyn.optonline.net) (Ping timeout: 246 seconds) |
2020-12-30 14:59:49 +0100 | geowiesnot | (~user@87-89-181-157.abo.bbox.fr) |
2020-12-30 15:00:22 +0100 | <kuribas> | siraben: you can implement monadic bind using scheme continuations. That gives you monad-notation for free :) |
2020-12-30 15:01:14 +0100 | <siraben> | kuribas: define-syntax FTW https://github.com/siraben/monadic-parsing |
2020-12-30 15:01:43 +0100 | ericsagnes | (~ericsagne@2405:6580:0:5100:9344:4d83:8d7c:8a3f) |
2020-12-30 15:01:50 +0100 | <kuribas> | siraben: that's not what I mean. I mean using the continuation. |
2020-12-30 15:01:59 +0100 | pfurla | (~pfurla@ool-182ed2e2.dyn.optonline.net) |
2020-12-30 15:02:06 +0100 | <siraben> | kuribas: oh yes |
2020-12-30 15:02:11 +0100 | <siraben> | but don't you end up with callback hell? |
2020-12-30 15:02:23 +0100 | ski | . o O ( "Representing Monads" by Andrzej Filinski in 1994-01 at <http://hjemmesider.diku.dk/~andrzej/papers/> ) |
2020-12-30 15:02:51 +0100 | <kuribas> | siraben: that's what bind is for... |
2020-12-30 15:03:02 +0100 | <siraben> | oh lol of course |
2020-12-30 15:04:25 +0100 | <ski> | you can define `reify' and `reflect', in terms of `list-return' and `list-bind', and (composable) continuations, so that `(reify (* (reflect (list 2 3)) (reflect (list 10 100))))' computes the list `(20 200 30 300)' |
2020-12-30 15:04:59 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 15:05:00 +0100 | tsrt^ | (tsrt@ip98-184-89-2.mc.at.cox.net) () |
2020-12-30 15:06:02 +0100 | <ski> | (or you could use `(reify (let* ((a (reflect (list 2 3))) (b (reflect (list 10 100)))) (* a b)))', if you want it to look more like `do') |
2020-12-30 15:06:16 +0100 | ph88 | (~ph88@2a02:8109:9e00:7e5c:cce3:aa71:9586:6387) (Remote host closed the connection) |
2020-12-30 15:06:44 +0100 | ph88 | (~ph88@2a02:8109:9e00:7e5c:cce3:aa71:9586:6387) |
2020-12-30 15:08:39 +0100 | <kuribas> | sadly you cannot define applicatives this way... |
2020-12-30 15:08:50 +0100 | <kuribas> | but then, neither can monad do... |
2020-12-30 15:09:49 +0100 | Gurkenglas | (~Gurkengla@unaffiliated/gurkenglas) (Ping timeout: 264 seconds) |
2020-12-30 15:09:56 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds) |
2020-12-30 15:10:00 +0100 | <ski> | (fwiw, you `(define (reflect lis) (shift (lambda (c) (list-bind lis c))))' and `(define (reify* thunk) (reset (lambda () (list-return (thunk)))))', defining `(reify ?expr)' as a macro, expanding to `(reify* (lambda () ?expr))') |
2020-12-30 15:11:29 +0100 | <ski> | (and you can use the `return' and `bind' for any monad that you can define in the language, not just for the list monad. so you can e.g. introduce parser side-effects, if you have a monadic parsing combinator library) |
2020-12-30 15:11:48 +0100 | <ski> | kuribas : hm, elaborate ? |
2020-12-30 15:11:50 +0100 | geowiesnot | (~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 272 seconds) |
2020-12-30 15:12:10 +0100 | <kuribas> | I don't think it's a coincidence that both continations and monads are proposed as a building block for exceptions, control flow, etc... |
2020-12-30 15:12:18 +0100 | <kuribas> | ski: I mean like doing stuff in paralel. |
2020-12-30 15:12:28 +0100 | <kuribas> | for example applicative do |
2020-12-30 15:12:35 +0100 | darjeeling_ | (~darjeelin@122.245.217.190) |
2020-12-30 15:12:38 +0100 | madjest16 | (~Android@31-161-158-37.mobile.kpn.net) |
2020-12-30 15:13:10 +0100 | Sheilong | (uid293653@gateway/web/irccloud.com/x-htiyqqtzxccutmly) |
2020-12-30 15:13:38 +0100 | <ski> | hm, okay |
2020-12-30 15:13:51 +0100 | <kuribas> | continuations imply a sequence, like monads do |
2020-12-30 15:14:15 +0100 | rekahsoft | (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) |
2020-12-30 15:14:43 +0100 | <ski> | (fwiw, i think the above monadic reflection thing is related to codensity, which is a continuation monad) |
2020-12-30 15:14:55 +0100 | LKoen_ | (~LKoen@126.170.9.109.rev.sfr.net) (Remote host closed the connection) |
2020-12-30 15:15:02 +0100 | madjestic | (~Android@86-88-72-244.fixed.kpn.net) (Ping timeout: 264 seconds) |
2020-12-30 15:15:13 +0100 | <ski> | well, idioms also express a kind of sequencing, but not in quite the same sense |
2020-12-30 15:23:13 +0100 | stef204 | (~stef204@unaffiliated/stef-204/x-384198) |
2020-12-30 15:23:13 +0100 | madjest16 | (~Android@31-161-158-37.mobile.kpn.net) (Read error: Connection reset by peer) |
2020-12-30 15:25:51 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 15:26:59 +0100 | Tario | (~Tario@201.192.165.173) |
2020-12-30 15:27:18 +0100 | madjestic | (~Android@86-88-72-244.fixed.kpn.net) |
2020-12-30 15:27:30 +0100 | Melanie | (~Melanie@192-0-134-138.cpe.teksavvy.com) (Ping timeout: 265 seconds) |
2020-12-30 15:29:05 +0100 | nehsou^ | (nehsou@ip98-184-89-2.mc.at.cox.net) |
2020-12-30 15:31:02 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Ping timeout: 260 seconds) |
2020-12-30 15:35:25 +0100 | madjest51 | (~Android@31-161-158-37.mobile.kpn.net) |
2020-12-30 15:37:39 +0100 | madjestic | (~Android@86-88-72-244.fixed.kpn.net) (Ping timeout: 265 seconds) |
2020-12-30 15:38:18 +0100 | Gurkenglas | (~Gurkengla@unaffiliated/gurkenglas) |
2020-12-30 15:39:12 +0100 | ph88 | (~ph88@2a02:8109:9e00:7e5c:cce3:aa71:9586:6387) (Ping timeout: 260 seconds) |
2020-12-30 15:39:13 +0100 | tabemann_ | (~tabemann@2600:1700:7990:24e0:bd20:50d4:5aa8:e550) (Remote host closed the connection) |
2020-12-30 15:39:18 +0100 | notzmv | (~user@unaffiliated/zmv) |
2020-12-30 15:39:27 +0100 | tabemann_ | (~tabemann@2600:1700:7990:24e0:3ba2:fef5:1410:7dbb) |
2020-12-30 15:40:06 +0100 | da39a3ee5e6b4b0d | (~da39a3ee5@171.5.28.247) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 15:40:34 +0100 | nshepperd | (~nshepperd@li364-218.members.linode.com) (Quit: WeeChat 2.9) |
2020-12-30 15:40:43 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 15:40:45 +0100 | nbloomf | (~nbloomf@2600:1700:ad14:3020:7dec:2218:241d:6f03) |
2020-12-30 15:42:17 +0100 | geekosaur | (ac3a8b4c@172.58.139.76) (Remote host closed the connection) |
2020-12-30 15:42:26 +0100 | geowiesnot | (~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) |
2020-12-30 15:42:26 +0100 | madjest51 | (~Android@31-161-158-37.mobile.kpn.net) (Read error: Connection reset by peer) |
2020-12-30 15:42:45 +0100 | madjestic | (~Android@86-88-72-244.fixed.kpn.net) |
2020-12-30 15:44:39 +0100 | ddellacosta | (dd@gateway/vpn/mullvad/ddellacosta) |
2020-12-30 15:45:59 +0100 | <siraben> | ski: shift and reset confuse me |
2020-12-30 15:46:06 +0100 | ADG1089__ | (~aditya@223.235.213.117) (Remote host closed the connection) |
2020-12-30 15:46:25 +0100 | <siraben> | oh using that you can interleave effects as in mtl? |
2020-12-30 15:46:27 +0100 | ADG1089__ | (~aditya@223.235.213.117) |
2020-12-30 15:46:43 +0100 | <kuribas> | using that you can do anything you do with monads. |
2020-12-30 15:47:22 +0100 | <kuribas> | probably using generic methods instead of type classes |
2020-12-30 15:47:31 +0100 | <ski> | siraben : see the Filinski paper i referenced |
2020-12-30 15:48:40 +0100 | <ski> | (and the follow up "Representing Layered Monads", from 1999-01 |
2020-12-30 15:48:53 +0100 | <siraben> | i see, saved |
2020-12-30 15:49:00 +0100 | <ski> | ) |
2020-12-30 15:49:15 +0100 | Sgeo | (~Sgeo@ool-18b98aa4.dyn.optonline.net) |
2020-12-30 15:49:20 +0100 | <siraben> | is the way i use reflect/reify similar? https://github.com/siraben/r5rs-denot/blob/74fbb82e5b4969a2d90678112fd455b243bec9da/src/SchemeEval… |
2020-12-30 15:49:59 +0100 | ADG1089_ | (~aditya@223.235.213.117) |
2020-12-30 15:50:33 +0100 | ADG1089__ | (~aditya@223.235.213.117) (Read error: Connection reset by peer) |
2020-12-30 15:50:44 +0100 | nbloomf | (~nbloomf@2600:1700:ad14:3020:7dec:2218:241d:6f03) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 15:53:31 +0100 | <ski> | only very vaguely |
2020-12-30 15:54:23 +0100 | Mrbuck | (~Mrbuck@gateway/tor-sasl/mrbuck) (Ping timeout: 240 seconds) |
2020-12-30 15:56:04 +0100 | <kuribas> | siraben: you can also implement reify/reflect, then implement shift reset on top of that... |
2020-12-30 15:56:05 +0100 | unlink2 | (~unlink2@p200300ebcf259600e4593ff5d42812d3.dip0.t-ipconnect.de) (Remote host closed the connection) |
2020-12-30 15:56:26 +0100 | <kuribas> | IMO a scheme with applicative continuations would be neat. |
2020-12-30 15:57:04 +0100 | Varis | (~Tadas@unaffiliated/varis) |
2020-12-30 15:57:08 +0100 | <siraben> | ski: Yeah, i wasn't basing it on the paper but just as convenient names to go back/from the denotational and monadic semantics |
2020-12-30 15:57:26 +0100 | unlink2 | (~unlink2@p200300ebcf259600e4593ff5d42812d3.dip0.t-ipconnect.de) |
2020-12-30 15:57:49 +0100 | da39a3ee5e6b4b0d | (~da39a3ee5@mx-ll-171.5.28-247.dynamic.3bb.co.th) |
2020-12-30 15:57:56 +0100 | <siraben> | related: call/cc's woes http://okmij.org/ftp/continuations/against-callcc.html |
2020-12-30 15:58:27 +0100 | chang | (~textual@host-173-230-65-85.njjcmar.clients.pavlovmedia.com) |
2020-12-30 15:58:35 +0100 | geowiesnot | (~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) (Ping timeout: 272 seconds) |
2020-12-30 15:59:06 +0100 | <kuribas> | shift/reset is better than call/cc |
2020-12-30 16:01:08 +0100 | nshepperd | (nshepperd@2600:3c03::f03c:92ff:fe28:92c9) |
2020-12-30 16:01:41 +0100 | nshepperd2 | (~nshepperd@li364-218.members.linode.com) (Quit: The Lounge - https://thelounge.chat) |
2020-12-30 16:01:41 +0100 | nshepperd | (nshepperd@2600:3c03::f03c:92ff:fe28:92c9) (Client Quit) |
2020-12-30 16:02:44 +0100 | olligobber | (~olligobbe@unaffiliated/olligobber) (Remote host closed the connection) |
2020-12-30 16:03:02 +0100 | nshepperd2 | (~nshepperd@li364-218.members.linode.com) |
2020-12-30 16:03:02 +0100 | nshepperd | (nshepperd@2600:3c03::f03c:92ff:fe28:92c9) |
2020-12-30 16:03:06 +0100 | <siraben> | kuribas: applicative continations? |
2020-12-30 16:03:28 +0100 | <siraben> | is that paper a good way to learn about shift/reset? |
2020-12-30 16:03:50 +0100 | Tops2 | (~Tobias@dyndsl-095-033-027-207.ewe-ip-backbone.de) |
2020-12-30 16:03:56 +0100 | mputz | (~Thunderbi@dslb-088-064-063-125.088.064.pools.vodafone-ip.de) (Ping timeout: 240 seconds) |
2020-12-30 16:07:21 +0100 | <exarkun> | I read https://nliu.net/posts/2020-11-06-bytestring.html yesterday and started to wonder if I should just use `ByteString` as my streaming data abstraction instead of `Int -> IO ByteString` |
2020-12-30 16:07:48 +0100 | nbloomf | (~nbloomf@2600:1700:ad14:3020:2994:ee4e:2fd6:b5cb) |
2020-12-30 16:09:01 +0100 | <exarkun> | Or more specifically, if I should use `Data.ByteString.Lazy.ByteString` instead of `Int -> IO Data.ByteString.ByteString` |
2020-12-30 16:10:20 +0100 | <exarkun> | There is some distinct appeal in being able to operate on parts of the data outside of IO |
2020-12-30 16:10:31 +0100 | <exarkun> | But is that a trap? Because, of course, I/O is still happening ... |
2020-12-30 16:14:07 +0100 | phasespace | (~sar@80-89-47-117.inet.signal.no) (Ping timeout: 256 seconds) |
2020-12-30 16:14:48 +0100 | ward_ | (~ward@ptr-1u4szschif2qqvply2m.18120a2.ip6.access.telenet.be) (Quit: Leaving) |
2020-12-30 16:16:19 +0100 | _noblegas | (uid91066@gateway/web/irccloud.com/x-hltwtxmffoclzdwc) (Quit: Connection closed for inactivity) |
2020-12-30 16:16:29 +0100 | <[exa]> | exarkun: likely depends on how much control you need over the possible IO interleaving |
2020-12-30 16:16:39 +0100 | pera | (~pera@unaffiliated/pera) |
2020-12-30 16:16:46 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) |
2020-12-30 16:17:23 +0100 | p-core | (~Thunderbi@koleje-wifi-0045.koleje.cuni.cz) (Remote host closed the connection) |
2020-12-30 16:17:48 +0100 | <[exa]> | if it's just reading a yuge bytestring from location 1 and writing the result to location 2, I wouldn't care at all |
2020-12-30 16:18:09 +0100 | <exarkun> | I guess that's approximately what I'm doing |
2020-12-30 16:18:43 +0100 | <[exa]> | the Int parameter in your case is an offset? |
2020-12-30 16:19:32 +0100 | <exarkun> | a length |
2020-12-30 16:19:58 +0100 | <exarkun> | to be read from the point after the last read |
2020-12-30 16:20:24 +0100 | <merijn> | exarkun: It's a trap, yes |
2020-12-30 16:20:36 +0100 | sunetoft | (~sunetoft@178.239.168.171) (Remote host closed the connection) |
2020-12-30 16:20:52 +0100 | <merijn> | exarkun: For example, you lose the ability to control when files get closed (or even if they are closed) and file descriptors are a finite resource |
2020-12-30 16:21:16 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) (Ping timeout: 240 seconds) |
2020-12-30 16:21:53 +0100 | <merijn> | exarkun: Usually you'd want something like a streaming library like conduit or pipes |
2020-12-30 16:21:57 +0100 | ADG1089_ | (~aditya@223.235.213.117) (Remote host closed the connection) |
2020-12-30 16:22:20 +0100 | ADG1089__ | (~aditya@223.235.213.117) |
2020-12-30 16:22:22 +0100 | <merijn> | exarkun: Although it depends a bit on the exact details of what you wanna do |
2020-12-30 16:23:11 +0100 | fendor_ | (~fendor@77.119.128.173.wireless.dyn.drei.com) |
2020-12-30 16:23:22 +0100 | <exarkun> | I see there are a lot of options for streaming |
2020-12-30 16:24:12 +0100 | <exarkun> | I played with Conduit a little bit. It's kind of neat but it didn't fit well with the branching (or something) I have in my processing. |
2020-12-30 16:24:19 +0100 | <exarkun> | streamly looks like it might but I haven't tried to work with it much yet. |
2020-12-30 16:25:09 +0100 | <merijn> | It depends a bit on what you're doing |
2020-12-30 16:25:14 +0100 | <exarkun> | When _do_ descriptors get closed if you use lazy ByteString? Does it have to do with what other IO actions get processed? Or GC? Or ... ? |
2020-12-30 16:25:34 +0100 | worc3131 | (~quassel@cpc88896-oxfd27-2-0-cust200.4-3.cable.virginm.net) |
2020-12-30 16:25:54 +0100 | <merijn> | exarkun: When you force the final part of the bytestring, then it gets closed and GCed |
2020-12-30 16:26:01 +0100 | fendor | (~fendor@178.165.130.45.wireless.dyn.drei.com) (Ping timeout: 256 seconds) |
2020-12-30 16:26:15 +0100 | <merijn> | exarkun: Well, what does the ByteString contain? i.e. how are you parsing it? |
2020-12-30 16:27:07 +0100 | <exarkun> | It's arbitrary bytes, I'm encrypting and erasure encoding it, then writing the erasure encoded pieces somewhere (to a file right now, to the network somehow later). |
2020-12-30 16:27:16 +0100 | chang | (~textual@host-173-230-65-85.njjcmar.clients.pavlovmedia.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 16:27:17 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 16:27:28 +0100 | <exarkun> | Also hashing it in a couple ways as I process it |
2020-12-30 16:27:35 +0100 | chang | (~textual@host-173-230-65-85.njjcmar.clients.pavlovmedia.com) |
2020-12-30 16:27:42 +0100 | <exarkun> | and collecting the hashes alongside for separate handling at the end |
2020-12-30 16:28:20 +0100 | <merijn> | Where are those bytes coming from, though? :p |
2020-12-30 16:28:49 +0100 | <merijn> | exarkun: Normally you'd wanna combine conduit with something like |
2020-12-30 16:28:51 +0100 | <exarkun> | Oh, usually a file |
2020-12-30 16:28:52 +0100 | <merijn> | @hackage binary-conduit |
2020-12-30 16:28:52 +0100 | <lambdabot> | https://hackage.haskell.org/package/binary-conduit |
2020-12-30 16:29:27 +0100 | <exarkun> | I have trouble fitting the erasure encoding part of it into the conduit model |
2020-12-30 16:29:37 +0100 | <exarkun> | one binary stream becomes N binary streams with different destinations |
2020-12-30 16:30:05 +0100 | t3xp4t | (~texinwien@213162073014.public.t-mobile.at) |
2020-12-30 16:30:16 +0100 | <merijn> | exarkun: Which lets you write normal parsers/serialisers for bytes using the binary package and then either "incrementally feed ByteStrings into a parser to get results" or "feed values into a conduit and get serialised bytes out" |
2020-12-30 16:30:46 +0100 | <exarkun> | I figured out a thing with TQueues but it basically involved escaping the Conduit abstraction entirely |
2020-12-30 16:31:04 +0100 | <merijn> | exarkun: Yeah, if you wanna split a ByteString into multiple paths it's not as useful |
2020-12-30 16:31:10 +0100 | <exarkun> | ("I figured out" -> "I got lots of good help here") |
2020-12-30 16:31:42 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Ping timeout: 260 seconds) |
2020-12-30 16:31:47 +0100 | <merijn> | exarkun: But then I'd probably still just use strict ByteString to read (parts of) the file into memory, it's just so much more predictable |
2020-12-30 16:32:32 +0100 | noumenon | (~daemon@113.51-175-156.customer.lyse.net) |
2020-12-30 16:32:40 +0100 | <exarkun> | I do like predictable |
2020-12-30 16:34:10 +0100 | <merijn> | exarkun: reading strict ByteString behaves much more like programming in any other language. By the time you have access to the bytes you are *sure* all bytes have been read successfully and if you do "foo <- readBytes 1024 hnd; hClose hnd; doStuffWith foo" you know things work |
2020-12-30 16:35:45 +0100 | <merijn> | exarkun: Since the guaranteed ordering of IO guarantees those all happen in order. With lazy IO (which is how you'd generally use lazy ByteString) the actual reading is interleaved with processing of the ByteString which means the reads in that example may happen after the close (whoopsie...) alternatively, if you hit a disk error while reading, that gets triggered somewhere in the middle of doStuffWith, |
2020-12-30 16:35:51 +0100 | <merijn> | making sane error handling trickier |
2020-12-30 16:36:03 +0100 | dfeuer | (~dfeuer@pool-108-18-223-60.washdc.fios.verizon.net) |
2020-12-30 16:36:37 +0100 | <merijn> | If you're hacking together a one-off script to do something and don't are about handling errors its fine. For a server less so, values not getting forced fully can leak descriptors, DOSing your program |
2020-12-30 16:37:11 +0100 | da39a3ee5e6b4b0d | (~da39a3ee5@mx-ll-171.5.28-247.dynamic.3bb.co.th) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 16:37:34 +0100 | <exarkun> | since I don't have a particularly strong motivation to switch from (Int -> IO ByteString) right now I guess I won't, and maybe I'll save that energy for learning more about streamly some other time |
2020-12-30 16:38:12 +0100 | <exarkun> | that blog post made lazy ByteString sound awfully good :) |
2020-12-30 16:38:36 +0100 | qwerty | (~tema@217.118.92.215) (Ping timeout: 240 seconds) |
2020-12-30 16:40:21 +0100 | phasespace | (~sar@89-162-33-21.fiber.signal.no) |
2020-12-30 16:41:20 +0100 | LKoen | (~LKoen@126.170.9.109.rev.sfr.net) |
2020-12-30 16:42:02 +0100 | <merijn> | exarkun: Well, lazy ByteString itself has a bunch of uses that don't involve lazy IO, so it's not useless :p |
2020-12-30 16:42:20 +0100 | <exarkun> | Okay, sure, fair enough |
2020-12-30 16:42:58 +0100 | <merijn> | exarkun: Most of my comments are more critiques of lazy IO than lazy ByteString. It's just that the file operations exported/exposed by lazy ByteString tend to be lazy IO |
2020-12-30 16:44:13 +0100 | coot | (~coot@37.30.60.60.nat.umts.dynamic.t-mobile.pl) |
2020-12-30 16:44:43 +0100 | knupfer | (~Thunderbi@200116b82c1638000cca96fffe3f40e7.dip.versatel-1u1.de) |
2020-12-30 16:45:00 +0100 | jamm | (~jamm@unaffiliated/jamm) |
2020-12-30 16:45:54 +0100 | knupfer | (~Thunderbi@200116b82c1638000cca96fffe3f40e7.dip.versatel-1u1.de) (Remote host closed the connection) |
2020-12-30 16:46:07 +0100 | knupfer | (~Thunderbi@200116b82c163800046eb3771e39b917.dip.versatel-1u1.de) |
2020-12-30 16:46:09 +0100 | exarkun | nods |
2020-12-30 16:47:23 +0100 | philopsos | (~caecilius@gateway/tor-sasl/caecilius) |
2020-12-30 16:48:00 +0100 | LKoen | (~LKoen@126.170.9.109.rev.sfr.net) (Remote host closed the connection) |
2020-12-30 16:48:00 +0100 | chipc | (~chipc@217.146.82.202) |
2020-12-30 16:48:17 +0100 | eacameron | (uid256985@gateway/web/irccloud.com/x-galbhouawynbrsup) |
2020-12-30 16:48:55 +0100 | chang | (~textual@host-173-230-65-85.njjcmar.clients.pavlovmedia.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 16:49:22 +0100 | ezzieyguywuf | (~Unknown@unaffiliated/ezzieyguywuf) (Ping timeout: 272 seconds) |
2020-12-30 16:50:04 +0100 | LKoen | (~LKoen@126.170.9.109.rev.sfr.net) |
2020-12-30 16:52:58 +0100 | acidjnk_new | (~acidjnk@p200300d0c704e726458729e8ce1a3b25.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
2020-12-30 16:52:58 +0100 | Lowl3v3l | (~Lowl3v3l@dslb-084-062-101-233.084.062.pools.vodafone-ip.de) (Read error: Connection reset by peer) |
2020-12-30 16:53:40 +0100 | Lowl3v3l | (~Lowl3v3l@dslb-084-062-101-233.084.062.pools.vodafone-ip.de) |
2020-12-30 16:54:11 +0100 | coot | (~coot@37.30.60.60.nat.umts.dynamic.t-mobile.pl) (Quit: coot) |
2020-12-30 16:54:28 +0100 | geowiesnot | (~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) |
2020-12-30 16:55:04 +0100 | mp___ | (~mp@hell.cx) |
2020-12-30 16:58:25 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 264 seconds) |
2020-12-30 17:00:39 +0100 | thunderrd | (~thunderrd@183.182.111.131) (Remote host closed the connection) |
2020-12-30 17:01:14 +0100 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) |
2020-12-30 17:01:18 +0100 | geowiesnot | (~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) (Ping timeout: 256 seconds) |
2020-12-30 17:01:31 +0100 | ezzieyguywuf | (~Unknown@unaffiliated/ezzieyguywuf) |
2020-12-30 17:04:23 +0100 | dolio | (~dolio@haskell/developer/dolio) (Quit: ZNC 1.8.2 - https://znc.in) |
2020-12-30 17:08:00 +0100 | Rudd0^ | (~Rudd0@185.189.115.103) |
2020-12-30 17:08:56 +0100 | Rudd0 | (~Rudd0@185.189.115.108) (Read error: Connection reset by peer) |
2020-12-30 17:09:04 +0100 | ddellacosta | (dd@gateway/vpn/mullvad/ddellacosta) (Ping timeout: 256 seconds) |
2020-12-30 17:09:30 +0100 | dolio | (~dolio@haskell/developer/dolio) |
2020-12-30 17:10:12 +0100 | fendor_ | fendor |
2020-12-30 17:10:55 +0100 | cr3 | (~cr3@192-222-143-195.qc.cable.ebox.net) |
2020-12-30 17:11:58 +0100 | Feuermagier | (~Feuermagi@213.178.26.41) |
2020-12-30 17:13:16 +0100 | shf | (~sheaf@2a01:cb19:80cc:7e00:59dc:2e08:3bcf:ee74) (Quit: Leaving) |
2020-12-30 17:19:56 +0100 | pera | (~pera@unaffiliated/pera) (Quit: leaving) |
2020-12-30 17:19:57 +0100 | <madnight> | In Nemesis, Riker and Troi got married, but was it Will or Thomas? |
2020-12-30 17:20:00 +0100 | thunderrd | (~thunderrd@183.182.111.131) |
2020-12-30 17:20:08 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
2020-12-30 17:20:25 +0100 | jmchael | (~jmchael@81.174.205.210) (Ping timeout: 246 seconds) |
2020-12-30 17:21:07 +0100 | christo_ | (~chris@81.96.113.213) |
2020-12-30 17:22:27 +0100 | kritzefitz | (~kritzefit@fw-front.credativ.com) (Remote host closed the connection) |
2020-12-30 17:24:13 +0100 | Anthaas | (~Anthaas@unaffiliated/anthaas) (Ping timeout: 264 seconds) |
2020-12-30 17:27:11 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 17:27:36 +0100 | Anthaas | (~Anthaas@unaffiliated/anthaas) |
2020-12-30 17:28:46 +0100 | juuandyy | (~juuandyy@90.166.144.65) |
2020-12-30 17:28:50 +0100 | argento | (~argent0@168.227.96.26) (Ping timeout: 256 seconds) |
2020-12-30 17:30:05 +0100 | cfricke | (~cfricke@unaffiliated/cfricke) |
2020-12-30 17:33:29 +0100 | Ariakenom | (~Ariakenom@2001:9b1:efb:fc00:6963:1023:8668:d646) (Quit: Leaving) |
2020-12-30 17:33:52 +0100 | noumenon | (~daemon@113.51-175-156.customer.lyse.net) (Quit: Leaving) |
2020-12-30 17:34:50 +0100 | ADG1089__ | (~aditya@223.235.213.117) (Quit: Konversation terminated!) |
2020-12-30 17:36:17 +0100 | solarliner | (~solarline@243.81.10.109.rev.sfr.net) (Quit: solarliner) |
2020-12-30 17:37:25 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 264 seconds) |
2020-12-30 17:38:22 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Remote host closed the connection) |
2020-12-30 17:38:33 +0100 | Tops21 | (~Tobias@dyndsl-095-033-027-207.ewe-ip-backbone.de) |
2020-12-30 17:39:03 +0100 | Tops22 | (~Tobias@dyndsl-095-033-027-207.ewe-ip-backbone.de) |
2020-12-30 17:41:36 +0100 | Tops2 | (~Tobias@dyndsl-095-033-027-207.ewe-ip-backbone.de) (Ping timeout: 240 seconds) |
2020-12-30 17:41:57 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
2020-12-30 17:42:31 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds) |
2020-12-30 17:43:00 +0100 | Tops21 | (~Tobias@dyndsl-095-033-027-207.ewe-ip-backbone.de) (Ping timeout: 256 seconds) |
2020-12-30 17:46:03 +0100 | plutoniix | (~q@ppp-27-55-80-50.revip3.asianet.co.th) |
2020-12-30 17:46:12 +0100 | hekkaidekapus] | (~tchouri@gateway/tor-sasl/hekkaidekapus) |
2020-12-30 17:46:44 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 17:47:56 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
2020-12-30 17:48:23 +0100 | hekkaidekapus[ | (~tchouri@gateway/tor-sasl/hekkaidekapus) (Ping timeout: 240 seconds) |
2020-12-30 17:50:51 +0100 | hexo | (~hexo@gateway/tor-sasl/hexo) (Quit: ZNC 1.8.2 - https://znc.in) |
2020-12-30 17:50:56 +0100 | denisse_ | (~spaceCat@gateway/tor-sasl/alephzer0) (Quit: ZNC 1.7.5 - https://znc.in) |
2020-12-30 17:51:04 +0100 | hexo | (~hexo@gateway/tor-sasl/hexo) |
2020-12-30 17:51:11 +0100 | xelxebar | (~xelxebar@gateway/tor-sasl/xelxebar) (Quit: ZNC 1.7.2+deb3 - https://znc.in) |
2020-12-30 17:51:18 +0100 | denisse_ | (~spaceCat@gateway/tor-sasl/alephzer0) |
2020-12-30 17:51:20 +0100 | xelxebar_ | (~xelxebar@gateway/tor-sasl/xelxebar) |
2020-12-30 17:51:23 +0100 | hekkaidekapus] | (~tchouri@gateway/tor-sasl/hekkaidekapus) (Ping timeout: 240 seconds) |
2020-12-30 17:51:24 +0100 | cantstanya | (~chatting@gateway/tor-sasl/cantstanya) (Ping timeout: 240 seconds) |
2020-12-30 17:51:44 +0100 | teardown | (~user@gateway/tor-sasl/mrush) (Ping timeout: 240 seconds) |
2020-12-30 17:52:03 +0100 | gxt | (~gxt@gateway/tor-sasl/gxt) (Ping timeout: 240 seconds) |
2020-12-30 17:52:04 +0100 | ChaiTRex | (~ChaiTRex@gateway/tor-sasl/chaitrex) (Ping timeout: 240 seconds) |
2020-12-30 17:52:16 +0100 | geekosaur | (42d52137@66.213.33.55) |
2020-12-30 17:52:23 +0100 | philopsos | (~caecilius@gateway/tor-sasl/caecilius) (Ping timeout: 240 seconds) |
2020-12-30 17:52:23 +0100 | gehmehgeh | (~ircuser1@gateway/tor-sasl/gehmehgeh) (Ping timeout: 240 seconds) |
2020-12-30 17:52:23 +0100 | tomboy64 | (~tomboy64@gateway/tor-sasl/tomboy64) (Ping timeout: 240 seconds) |
2020-12-30 17:52:24 +0100 | jb55 | (~jb55@gateway/tor-sasl/jb55) (Ping timeout: 240 seconds) |
2020-12-30 17:52:27 +0100 | srk | (~sorki@gateway/tor-sasl/sorki) (Quit: ZNC 1.8.2 - https://znc.in) |
2020-12-30 17:52:39 +0100 | srk | (~sorki@gateway/tor-sasl/sorki) |
2020-12-30 17:52:47 +0100 | megaTherion | (~therion@unix.io) (Quit: ZNC 1.7.5 - https://znc.in) |
2020-12-30 17:52:50 +0100 | teardown | (~user@gateway/tor-sasl/mrush) |
2020-12-30 17:53:02 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 17:53:04 +0100 | gxt | (~gxt@gateway/tor-sasl/gxt) |
2020-12-30 17:53:21 +0100 | Melanie | (~Melanie@192-0-134-138.cpe.teksavvy.com) |
2020-12-30 17:53:24 +0100 | ChaiTRex | (~ChaiTRex@gateway/tor-sasl/chaitrex) |
2020-12-30 17:53:26 +0100 | _noblegas | (uid91066@gateway/web/irccloud.com/x-rwqmwswwleosbyhn) |
2020-12-30 17:53:40 +0100 | philopsos | (~caecilius@gateway/tor-sasl/caecilius) |
2020-12-30 17:54:46 +0100 | gehmehgeh | (~ircuser1@gateway/tor-sasl/gehmehgeh) |
2020-12-30 17:54:53 +0100 | cantstanya | (~chatting@gateway/tor-sasl/cantstanya) |
2020-12-30 17:58:23 +0100 | andreas303 | (~andreas@gateway/tor-sasl/andreas303) (Ping timeout: 240 seconds) |
2020-12-30 17:59:02 +0100 | mp___ | (~mp@hell.cx) (Ping timeout: 272 seconds) |
2020-12-30 17:59:14 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
2020-12-30 18:00:36 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Remote host closed the connection) |
2020-12-30 18:00:40 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
2020-12-30 18:04:50 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 264 seconds) |
2020-12-30 18:05:38 +0100 | solonarv | (~solonarv@astrasbourg-653-1-157-135.w90-6.abo.wanadoo.fr) |
2020-12-30 18:08:44 +0100 | Rudd0^ | (~Rudd0@185.189.115.103) (Ping timeout: 256 seconds) |
2020-12-30 18:16:54 +0100 | bennofs|ALLES | (~quassel@2a01:4f8:c17:5579::1) (Remote host closed the connection) |
2020-12-30 18:18:41 +0100 | <kuribas> | exarkun: isn't the output of erasure encoding still a single stream though? |
2020-12-30 18:19:01 +0100 | <kuribas> | exarkun: (looking at https://en.wikipedia.org/wiki/Erasure_code) |
2020-12-30 18:19:09 +0100 | bennofs | (~quassel@2a01:4f8:c17:5579::1) |
2020-12-30 18:19:41 +0100 | <kuribas> | it looks like you simply add redundant error codes to the stream, which can be done easily with conduit (or streamly) |
2020-12-30 18:21:43 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 18:21:50 +0100 | argento | (~argent0@168.227.97.23) |
2020-12-30 18:22:34 +0100 | danso | (~dan@69-165-210-185.cable.teksavvy.com) |
2020-12-30 18:22:37 +0100 | <kuribas> | then you write a stream which takes the input, calculates the error codes from the input, and writes a new stream where the input is augmented with error codes. |
2020-12-30 18:23:04 +0100 | Melanie | (~Melanie@192-0-134-138.cpe.teksavvy.com) (Ping timeout: 246 seconds) |
2020-12-30 18:23:25 +0100 | mlugg | (522733ea@cpc95124-newt39-2-0-cust489.19-3.cable.virginm.net) (Remote host closed the connection) |
2020-12-30 18:24:16 +0100 | juuandyy | (~juuandyy@90.166.144.65) (Ping timeout: 240 seconds) |
2020-12-30 18:24:56 +0100 | juuandyy | (~juuandyy@90.166.144.65) |
2020-12-30 18:24:57 +0100 | xff0x_ | (~fox@2001:1a81:5361:7200:f921:dfdc:3d2e:f65) (Ping timeout: 268 seconds) |
2020-12-30 18:28:10 +0100 | <ph88^> | does anyone know a function like https://hackage.haskell.org/package/base-4.14.1.0/docs/Data-List.html#v:group that groups without sorting first ? the problem is that i can easily write a comparison function to see if two elements are the same, but writing a sorting function is hard |
2020-12-30 18:28:25 +0100 | tomboy64 | (~tomboy64@gateway/tor-sasl/tomboy64) |
2020-12-30 18:28:40 +0100 | <Rembane> | ph88^: You can use a proper set from Data.Set instead. |
2020-12-30 18:29:01 +0100 | <ph88^> | Rembane, how ? |
2020-12-30 18:29:33 +0100 | <Rembane> | ph88^: Hm... or maybe use a HashSet instead: https://hackage.haskell.org/package/unordered-containers-0.2.13.0/docs/Data-HashSet.html |
2020-12-30 18:29:49 +0100 | hekkaidekapus] | (~tchouri@gateway/tor-sasl/hekkaidekapus) |
2020-12-30 18:30:01 +0100 | <monochrom> | Data.List.sort does not require you to write your own sorting function. |
2020-12-30 18:30:04 +0100 | <ph88^> | that requires me to make a hash .. which is as difficult as writing a function to put into sort .. |
2020-12-30 18:30:16 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
2020-12-30 18:30:42 +0100 | <ph88^> | monochrom, in the example in linked docs you see that not all letters are grouped together, which is what i need (though i have other elements than characters) |
2020-12-30 18:30:59 +0100 | DavidEichmann | (~david@62.110.198.146.dyn.plus.net) (Ping timeout: 260 seconds) |
2020-12-30 18:31:04 +0100 | <monochrom> | Bah |
2020-12-30 18:31:15 +0100 | <ph88^> | :( |
2020-12-30 18:31:46 +0100 | <ph88^> | i can try to write this function myself .. just asking in case someone knows an already implemented "trueGroupBy" function |
2020-12-30 18:32:05 +0100 | <ph88^> | rather use library functions than reinvent wheel |
2020-12-30 18:32:15 +0100 | tochicool | (~tochicool@188.166.170.246) (Quit: Konversation terminated!) |
2020-12-30 18:32:37 +0100 | jb55 | (~jb55@gateway/tor-sasl/jb55) |
2020-12-30 18:34:18 +0100 | <exarkun> | kuribas: There are lots of variations, I guess. I'm not an expert on the taxonomy. The variation I'm using spreads the redundancy across different outputs instead of mixing it together in a single longer output. |
2020-12-30 18:34:46 +0100 | <kuribas> | exarkun: a fixed number of outputs? |
2020-12-30 18:34:48 +0100 | dfeuer | (~dfeuer@pool-108-18-223-60.washdc.fios.verizon.net) (Ping timeout: 256 seconds) |
2020-12-30 18:35:09 +0100 | <exarkun> | kuribas: It's configurable, but for a particular degree of redundancy, yes, a fixed number of outputs |
2020-12-30 18:35:41 +0100 | <exarkun> | kuribas: It's https://hackage.haskell.org/package/fec fwiw |
2020-12-30 18:35:53 +0100 | DavidEichmann | (~david@62.110.198.146.dyn.plus.net) |
2020-12-30 18:36:11 +0100 | <exarkun> | enFEC :: Int -> Int -> ByteString -> [ByteString] |
2020-12-30 18:36:49 +0100 | <exarkun> | enFEC requiredBlocks totalBlocks inputBlock == [outputBlocks] |
2020-12-30 18:36:52 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@static-198-54-134-148.cust.tzulo.com) |
2020-12-30 18:37:15 +0100 | <exarkun> | eh that second line almost looks like it's supposed to be haskell but it's not it's just meant to clarify the signature |
2020-12-30 18:39:47 +0100 | Jesin | (~Jesin@pool-72-66-101-18.washdc.fios.verizon.net) (Quit: Leaving) |
2020-12-30 18:40:09 +0100 | <tomsmeding> | ph88^: you _cannot_ write such a function trueGroupBy with better than n^2 complexity without a comparison function (like in Ord) or a hashing function |
2020-12-30 18:40:38 +0100 | <tomsmeding> | an O(n^2) trueGroupBy is easily written, though, if that's what you're looking for |
2020-12-30 18:41:02 +0100 | <ph88^> | tomsmeding, yes i'm looking for that |
2020-12-30 18:42:34 +0100 | <monochrom> | Quadratic time requires mutable lists or arrays. With immutable lists or arrays, every update takes another linear time, so you're looking at cubic time. |
2020-12-30 18:42:49 +0100 | <tomsmeding> | > let trueGroupBy f l = case l of [] -> [] ; x:xs -> let (yes, no) = partition (f x) xs in (x : yes) : trueGroupBy f no in trueGroupBy (==) "abcabcabc" |
2020-12-30 18:42:52 +0100 | <lambdabot> | ["aaa","bbb","ccc"] |
2020-12-30 18:42:55 +0100 | <tomsmeding> | ph88^: ^ |
2020-12-30 18:43:03 +0100 | Kaivo | (~Kaivo@104-200-86-99.mc.derytele.com) (Quit: WeeChat 2.9) |
2020-12-30 18:43:12 +0100 | <ph88^> | lovely thanks a lot tomsmeding ! |
2020-12-30 18:43:48 +0100 | <monochrom> | Ah nevermind. |
2020-12-30 18:43:59 +0100 | <tomsmeding> | this is quadratic, right? |
2020-12-30 18:44:03 +0100 | <monochrom> | Yes. |
2020-12-30 18:44:07 +0100 | <tomsmeding> | wouldn't be the first time I have a brain fart |
2020-12-30 18:44:12 +0100 | <tomsmeding> | phew |
2020-12-30 18:44:28 +0100 | <monochrom> | I forgot that you can search and delete in one pass, such as the partition there. |
2020-12-30 18:44:49 +0100 | <tomsmeding> | even if you couldn't, and you had two filters, it would still be quadratic -- just with an extra constant factor 2 |
2020-12-30 18:45:43 +0100 | <kuribas> | exarkun: you could make a stream of [ByteString], and multiplex it at the consumer |
2020-12-30 18:46:05 +0100 | <exarkun> | kuribas: Tell me more about "multiplex it at the consumer" |
2020-12-30 18:46:55 +0100 | xff0x_ | (~fox@2001:1a81:5361:7200:f921:dfdc:3d2e:f65) |
2020-12-30 18:47:07 +0100 | <kuribas> | exarkun: I mean, read a list from the producer, and send each element to wherever you want (file, socket) |
2020-12-30 18:49:22 +0100 | DavidEichmann | (~david@62.110.198.146.dyn.plus.net) (Ping timeout: 260 seconds) |
2020-12-30 18:49:23 +0100 | usr25 | (~usr25@unaffiliated/usr25) |
2020-12-30 18:49:43 +0100 | andreas303 | (~andreas@gateway/tor-sasl/andreas303) |
2020-12-30 18:49:50 +0100 | ericsagnes | (~ericsagne@2405:6580:0:5100:9344:4d83:8d7c:8a3f) (Ping timeout: 264 seconds) |
2020-12-30 18:51:58 +0100 | <kuribas> | exarkun: hmm, zipSink looks like what you want: https://hackage.haskell.org/package/conduit-1.3.4/docs/Data-Conduit.html#g:18 |
2020-12-30 18:53:06 +0100 | <exarkun> | I was just reading that and wondering |
2020-12-30 18:55:01 +0100 | <exarkun> | (that's a link to ZipSink right, not some other `zipSink` that I can't find?) |
2020-12-30 18:55:12 +0100 | Jesin | (~Jesin@pool-72-66-101-18.washdc.fios.verizon.net) |
2020-12-30 18:55:17 +0100 | DavidEichmann | (~david@98.27.93.209.dyn.plus.net) |
2020-12-30 18:56:07 +0100 | <exarkun> | sequenceSinks would pass the whole [ByteString] to each consumer and each consumer would be responsible for picking out the element it wants to work on, I think? which would work. but maybe some kind of `mapSink` (except it's the inside-out version of map that I think has a name but I can't remember it) would be a better fit |
2020-12-30 18:56:45 +0100 | geekosaur | (42d52137@66.213.33.55) (Ping timeout: 245 seconds) |
2020-12-30 18:57:09 +0100 | <exarkun> | does this make sense? mapSinks :: (Traversable f, Monad m) => f (Sink i m r) -> Sink (f i) m (f r) |
2020-12-30 18:57:16 +0100 | mp___ | (~mp@hell.cx) |
2020-12-30 18:57:27 +0100 | <kuribas> | exarkun: I think it sends each output to each sink, so the sink has to filter the element it wants. |
2020-12-30 18:57:40 +0100 | Deide | (~Deide@217.155.19.23) |
2020-12-30 18:58:33 +0100 | <kuribas> | So you need to turn (Sink ByteString m r) info (Sink [ByteString] m r), by indexing in the list. |
2020-12-30 18:59:06 +0100 | <kuribas> | not very efficient though... |
2020-12-30 18:59:26 +0100 | PepegaSit | (~ircpepega@ws59.zone150.zaural.ru) |
2020-12-30 18:59:34 +0100 | <exarkun> | it's a bit academic for the time being, as none of the rest of the code I have is prepared to deal with conduits at the moment |
2020-12-30 19:00:21 +0100 | <exarkun> | I'll probably try to make it work with (Int -> IO ByteString) and then try to figure out if it would be better with Conduit |
2020-12-30 19:00:36 +0100 | PepegaSit | (~ircpepega@ws59.zone150.zaural.ru) (Remote host closed the connection) |
2020-12-30 19:01:08 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
2020-12-30 19:01:33 +0100 | <exarkun> | I appreciate the nudge back towards conduit. Apart from not being able to figure out how to do what I wanted, I liked what I saw when investigating it previously :) |
2020-12-30 19:01:34 +0100 | <kuribas> | yeah |
2020-12-30 19:01:34 +0100 | mp___ | (~mp@hell.cx) (Ping timeout: 246 seconds) |
2020-12-30 19:01:43 +0100 | ericsagnes | (~ericsagne@2405:6580:0:5100:2d54:ddf7:e8d2:c4c3) |
2020-12-30 19:02:02 +0100 | <kuribas> | make it simple first, then make it robust is a good choice... |
2020-12-30 19:02:46 +0100 | <kuribas> | lazy IO isn't always bad, you just have to be careful |
2020-12-30 19:03:46 +0100 | crblmr | (~carbolyme@matrix.dropacid.net) (Ping timeout: 258 seconds) |
2020-12-30 19:04:36 +0100 | DavidEichmann | (~david@98.27.93.209.dyn.plus.net) (Ping timeout: 240 seconds) |
2020-12-30 19:04:48 +0100 | crblmr | (~carbolyme@matrix.dropacid.net) |
2020-12-30 19:05:19 +0100 | DavidEichmann | (~david@98.27.93.209.dyn.plus.net) |
2020-12-30 19:08:22 +0100 | geekosaur | (42d52137@66.213.33.55) |
2020-12-30 19:08:34 +0100 | jmchael | (~jmchael@81.174.205.210) |
2020-12-30 19:13:22 +0100 | raothorn22 | (6b4dc5da@mobile-107-77-197-218.mobile.att.net) |
2020-12-30 19:15:22 +0100 | usr25 | (~usr25@unaffiliated/usr25) (Quit: Leaving) |
2020-12-30 19:16:39 +0100 | dfeuer | (~dfeuer@pool-108-18-223-60.washdc.fios.verizon.net) |
2020-12-30 19:16:43 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Remote host closed the connection) |
2020-12-30 19:16:45 +0100 | xff0x_ | (~fox@2001:1a81:5361:7200:f921:dfdc:3d2e:f65) (Ping timeout: 268 seconds) |
2020-12-30 19:20:26 +0100 | usr25 | (~usr25@unaffiliated/usr25) |
2020-12-30 19:20:36 +0100 | Kronic | (~Kronic___@84.203.96.46) (Quit: Leaving) |
2020-12-30 19:24:24 +0100 | <raothorn22> | First time here, could someone help me with a question about lenses? |
2020-12-30 19:24:35 +0100 | <dsal> | raothorn22: can't know until you ask |
2020-12-30 19:27:09 +0100 | megaTherion | (~therion@unix.io) |
2020-12-30 19:28:04 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 19:28:28 +0100 | knupfer | (~Thunderbi@200116b82c163800046eb3771e39b917.dip.versatel-1u1.de) (Ping timeout: 268 seconds) |
2020-12-30 19:31:42 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 19:32:41 +0100 | salumu | (~sMuNiX@vlnsm8-montreal02-142-122-8-233.internet.virginmobile.ca) (Quit: WeeChat 3.0) |
2020-12-30 19:33:36 +0100 | <raothorn22> | Ok, so let me try to phrase this well. From what I understand, composition of lenses (I'm using Control.Lens by the way) goes "deeper" into a nested structure, which isn't really what I'm trying to do. I'm looking for a way to combine two setters to update two things on the same level. The relevant code is here, along with some more explanation of |
2020-12-30 19:33:37 +0100 | <raothorn22> | what I'm trying to do. https://pastebin.com/EgzAjrwe |
2020-12-30 19:35:39 +0100 | jamm | (~jamm@unaffiliated/jamm) (Remote host closed the connection) |
2020-12-30 19:37:31 +0100 | xff0x_ | (~fox@2001:1a81:5361:7200:b495:b5df:7e6c:e9db) |
2020-12-30 19:39:00 +0100 | bitmapper | (uid464869@gateway/web/irccloud.com/x-eafppdbbqgpahaet) (Quit: Connection closed for inactivity) |
2020-12-30 19:39:03 +0100 | ddellacosta | (dd@gateway/vpn/mullvad/ddellacosta) |
2020-12-30 19:40:53 +0100 | nehsou^ | (nehsou@ip98-184-89-2.mc.at.cox.net) () |
2020-12-30 19:41:14 +0100 | Lord_of_Life | (~Lord@unaffiliated/lord-of-life/x-0885362) (Read error: Connection reset by peer) |
2020-12-30 19:41:27 +0100 | mputz | (~Thunderbi@dslb-088-064-063-125.088.064.pools.vodafone-ip.de) |
2020-12-30 19:41:41 +0100 | Lord_of_Life | (~Lord@unaffiliated/lord-of-life/x-0885362) |
2020-12-30 19:42:13 +0100 | jle` | (~mstksg@unaffiliated/mstksg) (Ping timeout: 264 seconds) |
2020-12-30 19:42:52 +0100 | rayyyy | (~nanoz@gateway/tor-sasl/nanoz) (Remote host closed the connection) |
2020-12-30 19:43:00 +0100 | rayyyy1 | (~nanoz@gateway/tor-sasl/nanoz) |
2020-12-30 19:44:34 +0100 | <dsal> | raothorn22: Your phase 2 is just `gamePhase & turnPhase .~ Phase1 & playerTurn +~ 1` isn't it? |
2020-12-30 19:45:02 +0100 | <dsal> | > (1,2) & _1 .~ 11 & 2 +~ 100 |
2020-12-30 19:45:06 +0100 | <lambdabot> | error: |
2020-12-30 19:45:06 +0100 | <lambdabot> | • Could not deduce (Num b1) |
2020-12-30 19:45:06 +0100 | <lambdabot> | from the context: (Num b, Num b2, Num a, |
2020-12-30 19:45:09 +0100 | <dsal> | > (1,2) & _1 .~ 11 & _2 +~ 100 |
2020-12-30 19:45:10 +0100 | o1lo01ol1o | (~o1lo01ol1@dsl-51-169.bl26.telepac.pt) |
2020-12-30 19:45:12 +0100 | <lambdabot> | (11,102) |
2020-12-30 19:45:19 +0100 | <raothorn22> | oooh |
2020-12-30 19:45:55 +0100 | jle` | (~mstksg@cpe-23-240-75-236.socal.res.rr.com) |
2020-12-30 19:45:55 +0100 | jle` | (~mstksg@cpe-23-240-75-236.socal.res.rr.com) (Changing host) |
2020-12-30 19:45:55 +0100 | jle` | (~mstksg@unaffiliated/mstksg) |
2020-12-30 19:45:59 +0100 | <dsal> | You could also make a `nextPlayer` function to swap the player. |
2020-12-30 19:46:11 +0100 | <raothorn22> | it's literally just function application I guess? I think I might have misunderstood something about lenses |
2020-12-30 19:46:36 +0100 | <dsal> | > (True,1) & _1 %~ not & _2 +~ 1 |
2020-12-30 19:46:39 +0100 | <lambdabot> | (False,2) |
2020-12-30 19:46:49 +0100 | justsomeguy | (~justsomeg@unaffiliated/--/x-3805311) |
2020-12-30 19:46:52 +0100 | <merijn> | raothorn22: Lenses are just "a nice way to conveniently apply a function to something nested deeply into some data structure" |
2020-12-30 19:47:14 +0100 | <merijn> | There's no magic, updating through a lens is just a function that returns a new value |
2020-12-30 19:47:55 +0100 | <raothorn22> | Right, yeah I'm getting that now. I think the complicated type stuff in the Lens library was confusing me more than it should |
2020-12-30 19:47:55 +0100 | Lord_of_Life_ | (~Lord@unaffiliated/lord-of-life/x-0885362) |
2020-12-30 19:48:27 +0100 | <dsal> | You can do really complicated stuff and sometimes it's *hugely* helpful. Here, it's not doing a whole lot for you at the moment. |
2020-12-30 19:49:47 +0100 | Franciman | (~francesco@host-95-250-152-231.retail.telecomitalia.it) (Quit: Leaving) |
2020-12-30 19:49:56 +0100 | Lord_of_Life | (~Lord@unaffiliated/lord-of-life/x-0885362) (Ping timeout: 240 seconds) |
2020-12-30 19:49:56 +0100 | Lord_of_Life_ | Lord_of_Life |
2020-12-30 19:50:49 +0100 | LKoen | (~LKoen@126.170.9.109.rev.sfr.net) (Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.”) |
2020-12-30 19:50:52 +0100 | son0p | (~son0p@181.136.122.143) |
2020-12-30 19:50:52 +0100 | stef204 | (~stef204@unaffiliated/stef-204/x-384198) (Quit: WeeChat 3.0) |
2020-12-30 19:51:52 +0100 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) (Ping timeout: 256 seconds) |
2020-12-30 19:52:52 +0100 | <raothorn22> | dsal right of course, but my types are going to get a lot more complicated. I basically want to write my function so that it won't break if I added another field to GamePhase |
2020-12-30 19:53:26 +0100 | <raothorn22> | I don't think I want to do anything more complicated than basic updating though. Thanks, you helped a lot |
2020-12-30 19:53:36 +0100 | <dsal> | raothorn22: `g{turnPhase=Phase2}` is that. :) |
2020-12-30 19:54:10 +0100 | ADG1089__ | (~aditya@223.235.213.117) |
2020-12-30 19:54:46 +0100 | <raothorn22> | oh right, I had learned about the record update syntax but I forgot! Thanks! |
2020-12-30 19:58:40 +0100 | <dsal> | lens becomes really important when you have nested structures. |
2020-12-30 19:59:04 +0100 | <merijn> | Well...it *might* become really important :p |
2020-12-30 19:59:19 +0100 | <dsal> | Yeah, I meant to not be clear. |
2020-12-30 19:59:24 +0100 | <dsal> | er, absolute/ |
2020-12-30 20:01:38 +0100 | raothorn22 | (6b4dc5da@mobile-107-77-197-218.mobile.att.net) (Remote host closed the connection) |
2020-12-30 20:01:56 +0100 | fionnan | (~fionnan@109.255.20.201) |
2020-12-30 20:03:37 +0100 | berberman | (~berberman@unaffiliated/berberman) |
2020-12-30 20:04:51 +0100 | berberman_ | (~berberman@unaffiliated/berberman) (Ping timeout: 268 seconds) |
2020-12-30 20:05:21 +0100 | tsrt^ | (tsrt@ip98-184-89-2.mc.at.cox.net) |
2020-12-30 20:08:16 +0100 | cole-h | (~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) |
2020-12-30 20:10:48 +0100 | <ph88^> | is it still possible to pattern match when using guards ? |
2020-12-30 20:11:30 +0100 | <__monty__> | ph88^: Yes. |
2020-12-30 20:12:07 +0100 | <ephemient> | > let isRightEven (Right x) | even x = True; isRightEven _ = False in isRightEven (Right 1) |
2020-12-30 20:12:09 +0100 | <lambdabot> | False |
2020-12-30 20:13:06 +0100 | <monochrom> | Look for "pattern guards" in either the Haskell 2020 Report or the GHC User's Guide. |
2020-12-30 20:13:12 +0100 | <ph88^> | thanks |
2020-12-30 20:14:03 +0100 | <__monty__> | Surely you mean 2010 report? |
2020-12-30 20:14:26 +0100 | <monochrom> | Err yeah 2010 |
2020-12-30 20:14:35 +0100 | <monochrom> | @quote monochrom flies |
2020-12-30 20:14:35 +0100 | <lambdabot> | monochrom says: Time flies like an Arrow. Space leaks like a Monad. |
2020-12-30 20:15:20 +0100 | <monochrom> | @quote monochrom flies.*syntax |
2020-12-30 20:15:20 +0100 | <lambdabot> | monochrom says: Time flies like an arrow. Fruit flies like a banana. Syntax rules like a macro. |
2020-12-30 20:18:43 +0100 | geowiesnot | (~user@87-89-181-157.abo.bbox.fr) |
2020-12-30 20:19:01 +0100 | knupfer | (~Thunderbi@200116b82c163800e085017ed5c7df7b.dip.versatel-1u1.de) |
2020-12-30 20:20:38 +0100 | b4er | (~b5er_@91.193.4.138) |
2020-12-30 20:22:52 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Remote host closed the connection) |
2020-12-30 20:23:55 +0100 | michalz | (~user@185.246.204.91) (Remote host closed the connection) |
2020-12-30 20:24:02 +0100 | justsomeguy | (~justsomeg@unaffiliated/--/x-3805311) () |
2020-12-30 20:25:21 +0100 | <exarkun> | if I want to ask for the digest size of SHA256 ... `hashDigestSize $ undefined :: SHA256` ? |
2020-12-30 20:25:51 +0100 | juuandyy | (~juuandyy@90.166.144.65) (Ping timeout: 272 seconds) |
2020-12-30 20:27:24 +0100 | ADG1089__ | (~aditya@223.235.213.117) (Remote host closed the connection) |
2020-12-30 20:29:41 +0100 | geowiesnot | (~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 256 seconds) |
2020-12-30 20:30:13 +0100 | acarrico | (~acarrico@dhcp-68-142-39-249.greenmountainaccess.net) (Ping timeout: 264 seconds) |
2020-12-30 20:30:41 +0100 | <idnar> | exarkun: I think `hashDigestSize SHA256`` |
2020-12-30 20:32:15 +0100 | ADG1089__ | (~aditya@223.235.213.117) |
2020-12-30 20:32:42 +0100 | <idnar> | @hoogle (a -> b -> a) -> Map k a -> Map k b -> Map k a |
2020-12-30 20:32:43 +0100 | <lambdabot> | Data.Map.Internal intersectionWith :: Ord k => (a -> b -> c) -> Map k a -> Map k b -> Map k c |
2020-12-30 20:32:43 +0100 | <lambdabot> | Data.Map.Lazy intersectionWith :: Ord k => (a -> b -> c) -> Map k a -> Map k b -> Map k c |
2020-12-30 20:32:43 +0100 | <lambdabot> | Data.Map.Strict intersectionWith :: Ord k => (a -> b -> c) -> Map k a -> Map k b -> Map k c |
2020-12-30 20:33:47 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 260 seconds) |
2020-12-30 20:33:48 +0100 | <exarkun> | idnar: oooh |
2020-12-30 20:34:03 +0100 | <exarkun> | because SHA256 is the type and the no-argument constructor |
2020-12-30 20:34:14 +0100 | <exarkun> | I missed that 2nd fact |
2020-12-30 20:34:17 +0100 | <idnar> | exarkun: yeah |
2020-12-30 20:34:36 +0100 | <exarkun> | that's certainly nicer. |
2020-12-30 20:34:38 +0100 | <exarkun> | thanks |
2020-12-30 20:36:21 +0100 | dfeuer | (~dfeuer@pool-108-18-223-60.washdc.fios.verizon.net) (Ping timeout: 265 seconds) |
2020-12-30 20:37:45 +0100 | bitmagie | (~Thunderbi@200116b80684bd0008a0a917606ec592.dip.versatel-1u1.de) |
2020-12-30 20:40:16 +0100 | jle` | (~mstksg@unaffiliated/mstksg) (Ping timeout: 240 seconds) |
2020-12-30 20:41:20 +0100 | geekosaur | (42d52137@66.213.33.55) (Ping timeout: 245 seconds) |
2020-12-30 20:42:20 +0100 | jle` | (~mstksg@unaffiliated/mstksg) |
2020-12-30 20:42:53 +0100 | <idnar> | @pl \a b -> b |
2020-12-30 20:42:53 +0100 | <lambdabot> | const id |
2020-12-30 20:43:06 +0100 | <idnar> | @pl \a b -> a |
2020-12-30 20:43:06 +0100 | <lambdabot> | const |
2020-12-30 20:46:03 +0100 | <idnar> | @type \f x -> f x $> x |
2020-12-30 20:46:05 +0100 | <lambdabot> | error: |
2020-12-30 20:46:05 +0100 | <lambdabot> | • Variable not in scope: ($>) :: t1 -> t -> t2 |
2020-12-30 20:46:05 +0100 | <lambdabot> | • Perhaps you meant one of these: |
2020-12-30 20:46:44 +0100 | <idnar> | @type \f x -> x <$ f x |
2020-12-30 20:46:45 +0100 | <lambdabot> | Functor f => (t -> f b) -> t -> f t |
2020-12-30 20:48:11 +0100 | tstat | (~tstat@165.227.66.131) (Quit: ZNC 1.6.5 - http://znc.in) |
2020-12-30 20:48:19 +0100 | bitmagie | (~Thunderbi@200116b80684bd0008a0a917606ec592.dip.versatel-1u1.de) (Quit: bitmagie) |
2020-12-30 20:49:10 +0100 | <idnar> | @hoogle Functor f => (t -> f b) -> t -> f t |
2020-12-30 20:49:11 +0100 | <lambdabot> | No results found |
2020-12-30 20:49:23 +0100 | <tomsmeding> | idnar: anything in particular that you're looking for? |
2020-12-30 20:49:24 +0100 | hnOsmium0001 | (uid453710@gateway/web/irccloud.com/x-iakwekdkzgcrclln) |
2020-12-30 20:49:45 +0100 | juuandyy | (~juuandyy@90.166.144.65) |
2020-12-30 20:52:03 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 20:52:27 +0100 | jyri-matti | (uid479350@gateway/web/irccloud.com/x-sdpspavvezzlrhxl) (Quit: Connection closed for inactivity) |
2020-12-30 20:53:08 +0100 | <idnar> | tomsmeding: I just wrote `f x $> x` for the third time |
2020-12-30 20:53:35 +0100 | knupfer | (~Thunderbi@200116b82c163800e085017ed5c7df7b.dip.versatel-1u1.de) (Quit: knupfer) |
2020-12-30 20:53:43 +0100 | acarrico | (~acarrico@dhcp-68-142-39-249.greenmountainaccess.net) |
2020-12-30 20:53:49 +0100 | knupfer | (~Thunderbi@200116b82c1638008142ece12d3b6b6b.dip.versatel-1u1.de) |
2020-12-30 20:54:15 +0100 | fmeyer | (~fmeyer@p57ab40e7.dip0.t-ipconnect.de) |
2020-12-30 20:54:28 +0100 | geekosaur | (42d52137@66.213.33.55) |
2020-12-30 20:54:49 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 264 seconds) |
2020-12-30 20:55:26 +0100 | <idnar> | `writeTVar v x $> x` in this case |
2020-12-30 20:56:15 +0100 | <tomsmeding> | ah, I see how that could be useful indeed |
2020-12-30 20:57:04 +0100 | <exarkun> | Hm. Now I need a merkle tree... |
2020-12-30 20:59:58 +0100 | Sheilong | (uid293653@gateway/web/irccloud.com/x-htiyqqtzxccutmly) (Quit: Connection closed for inactivity) |
2020-12-30 21:00:23 +0100 | acidjnk_new | (~acidjnk@p200300d0c704e799613ed27d32309497.dip0.t-ipconnect.de) |
2020-12-30 21:01:22 +0100 | materialfuture[m | (materialfu@gateway/shell/matrix.org/x-cwhzlrxokybvzeoj) |
2020-12-30 21:01:26 +0100 | pfurla | (~pfurla@ool-182ed2e2.dyn.optonline.net) (Ping timeout: 272 seconds) |
2020-12-30 21:02:08 +0100 | justsomeguy | (~justsomeg@2603:9000:960a:fc00:c4d2:5b73:c7b7:3a2b) |
2020-12-30 21:02:08 +0100 | justsomeguy | (~justsomeg@2603:9000:960a:fc00:c4d2:5b73:c7b7:3a2b) (Changing host) |
2020-12-30 21:02:08 +0100 | justsomeguy | (~justsomeg@unaffiliated/--/x-3805311) |
2020-12-30 21:02:13 +0100 | tstat | (~tstat@104.131.113.212) |
2020-12-30 21:02:41 +0100 | fmeyer | (~fmeyer@p57ab40e7.dip0.t-ipconnect.de) ("Leaving") |
2020-12-30 21:03:06 +0100 | Franciman | (~francesco@host-95-250-152-231.retail.telecomitalia.it) |
2020-12-30 21:03:13 +0100 | pfurla | (~pfurla@ool-182ed2e2.dyn.optonline.net) |
2020-12-30 21:03:20 +0100 | morph_ | (~morph@2a01:110f:bb3:7e00:38c9:9227:a2b5:d96d) |
2020-12-30 21:04:14 +0100 | juuandyy | (~juuandyy@90.166.144.65) (Ping timeout: 256 seconds) |
2020-12-30 21:04:27 +0100 | <dminuoso> | @type \f x -> x <$ f x |
2020-12-30 21:04:27 +0100 | ohmysomuchuser | (~nickednam@037008230172.dynamic-3-poz-k-1-2-0.vectranet.pl) |
2020-12-30 21:04:28 +0100 | <lambdabot> | Functor f => (t -> f b) -> t -> f t |
2020-12-30 21:04:34 +0100 | <dminuoso> | type Lens s t a b = forall f . Functor f => (a -> f b) -> s -> f t |
2020-12-30 21:04:37 +0100 | <dminuoso> | Mmm. This is a valid lens. :) |
2020-12-30 21:06:23 +0100 | <c_wraith> | I'm not sure that's true |
2020-12-30 21:06:33 +0100 | <c_wraith> | It type-checks, but lenses have laws |
2020-12-30 21:06:33 +0100 | Shiranai | (beed0d8f@gateway/web/cgi-irc/kiwiirc.com/ip.190.237.13.143) |
2020-12-30 21:07:45 +0100 | morph_ | (~morph@2a01:110f:bb3:7e00:38c9:9227:a2b5:d96d) ("Leaving") |
2020-12-30 21:09:32 +0100 | christo_ | (~chris@81.96.113.213) (Remote host closed the connection) |
2020-12-30 21:10:01 +0100 | ph88_ | (~ph88@2a02:8109:9e00:7e5c:b472:19b8:2fa3:f30b) |
2020-12-30 21:12:12 +0100 | <idnar> | > let l = \f x -> x <$ f x in view l (set l 10 20) |
2020-12-30 21:12:14 +0100 | juuandyy | (~juuandyy@90.166.144.65) |
2020-12-30 21:12:15 +0100 | <lambdabot> | 20 |
2020-12-30 21:12:49 +0100 | cr3 | (~cr3@192-222-143-195.qc.cable.ebox.net) (Ping timeout: 264 seconds) |
2020-12-30 21:13:08 +0100 | <idnar> | > let l = \f x -> x <$ f x in view l (set l "a" 20) |
2020-12-30 21:13:10 +0100 | <lambdabot> | 20 |
2020-12-30 21:13:55 +0100 | ph88^ | (~ph88@2a02:8109:9e00:7e5c:41c2:9b01:cf42:baca) (Ping timeout: 268 seconds) |
2020-12-30 21:15:11 +0100 | o1lo01ol1o | (~o1lo01ol1@dsl-51-169.bl26.telepac.pt) (Remote host closed the connection) |
2020-12-30 21:15:22 +0100 | machinedgod | (~machinedg@24.105.81.50) |
2020-12-30 21:15:50 +0100 | <idnar> | > let l = \f x -> x <$ f x in set l (view l 20) 20 |
2020-12-30 21:15:53 +0100 | <lambdabot> | 20 |
2020-12-30 21:17:39 +0100 | <idnar> | not lawful |
2020-12-30 21:17:49 +0100 | son0p | (~son0p@181.136.122.143) (Ping timeout: 260 seconds) |
2020-12-30 21:18:00 +0100 | coot | (~coot@37.30.60.60.nat.umts.dynamic.t-mobile.pl) |
2020-12-30 21:18:42 +0100 | Cale | (~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com) (Remote host closed the connection) |
2020-12-30 21:19:16 +0100 | son0p | (~son0p@181.136.122.143) |
2020-12-30 21:19:56 +0100 | crblmr | (~carbolyme@matrix.dropacid.net) (Ping timeout: 240 seconds) |
2020-12-30 21:21:05 +0100 | <idnar> | `Lens s s s t` compiles but can't be lawful- |
2020-12-30 21:21:44 +0100 | crblmr | (~carbolyme@matrix.dropacid.net) |
2020-12-30 21:23:17 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 21:23:20 +0100 | cheater | (~user@unaffiliated/cheater) |
2020-12-30 21:25:56 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds) |
2020-12-30 21:27:40 +0100 | Kaivo | (~Kaivo@104-200-86-99.mc.derytele.com) |
2020-12-30 21:27:42 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Ping timeout: 260 seconds) |
2020-12-30 21:27:54 +0100 | <dminuoso> | Mmm fair point |
2020-12-30 21:33:03 +0100 | rayyyy1 | (~nanoz@gateway/tor-sasl/nanoz) (Ping timeout: 240 seconds) |
2020-12-30 21:33:41 +0100 | Cale | (~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com) |
2020-12-30 21:33:42 +0100 | cfricke | (~cfricke@unaffiliated/cfricke) (Quit: WeeChat 3.0) |
2020-12-30 21:35:44 +0100 | _ht | (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
2020-12-30 21:36:26 +0100 | o1lo01ol1o | (~o1lo01ol1@dsl-51-169.bl26.telepac.pt) |
2020-12-30 21:37:13 +0100 | juuandyy | (~juuandyy@90.166.144.65) (Quit: Konversation terminated!) |
2020-12-30 21:40:08 +0100 | <Shiranai> | after reading learn you a haskell, what can I read/do to improve my haskell skillz? |
2020-12-30 21:40:49 +0100 | <Shiranai> | I am an amateur but would also like to learn about the theorical category theory/type theory side of it |
2020-12-30 21:40:49 +0100 | ddellacosta | (dd@gateway/vpn/mullvad/ddellacosta) (Quit: WeeChat 2.8) |
2020-12-30 21:40:55 +0100 | <Uniaika> | Shiranai: https://twitter.com/TechnoEmpress/status/1164766723234340866 |
2020-12-30 21:43:58 +0100 | ddellacosta | (dd@gateway/vpn/mullvad/ddellacosta) |
2020-12-30 21:44:01 +0100 | <Shiranai> | thanks, I'll check the joyofhaskell book, not that interested in webdev tho |
2020-12-30 21:45:04 +0100 | o1lo01ol_ | (~o1lo01ol1@bl11-140-216.dsl.telepac.pt) |
2020-12-30 21:45:35 +0100 | <monochrom> | Yeah that list looks suspicious like "I want to be profitable". |
2020-12-30 21:47:28 +0100 | o1lo01ol1o | (~o1lo01ol1@dsl-51-169.bl26.telepac.pt) (Ping timeout: 246 seconds) |
2020-12-30 21:47:49 +0100 | <sm[m]> | Shiranai: Typeclassopedia |
2020-12-30 21:49:02 +0100 | <Shiranai> | sm[m]: brilliant! Thanks, exactly the kind of stuff I was looking for |
2020-12-30 21:50:44 +0100 | ransom | (~c4264035@8.47.12.52) |
2020-12-30 21:51:27 +0100 | <sm[m]> | and all the haddocks for related libs in base - I'm not sure what to call them - things like Data.Functor, Control.Applicative, Control.Monad.. |
2020-12-30 21:51:43 +0100 | ces | (~ces@fsf/member/ces) |
2020-12-30 21:52:16 +0100 | crblmr | (~carbolyme@matrix.dropacid.net) (Ping timeout: 240 seconds) |
2020-12-30 21:52:56 +0100 | crblmr | (~carbolyme@matrix.dropacid.net) |
2020-12-30 21:52:59 +0100 | <Shiranai> | alright, I'll give those a check too! thanks |
2020-12-30 21:53:07 +0100 | ericsagnes | (~ericsagne@2405:6580:0:5100:2d54:ddf7:e8d2:c4c3) (Ping timeout: 260 seconds) |
2020-12-30 21:53:28 +0100 | frankdmartinez | (~user@5.181.234.188) |
2020-12-30 21:53:32 +0100 | <sm[m]> | and of course, real project code to see how these look in action |
2020-12-30 21:54:40 +0100 | geowiesnot | (~user@87-89-181-157.abo.bbox.fr) |
2020-12-30 21:56:32 +0100 | <frankdmartinez> | Hello, is there a way to get GHCI to output the type-deduction/inference steps it goes thru when evaluating an expression? |
2020-12-30 21:57:17 +0100 | carthia | (~carthia@gateway/tor-sasl/carthia) |
2020-12-30 21:58:10 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@static-198-54-134-148.cust.tzulo.com) (Quit: Leaving) |
2020-12-30 21:58:25 +0100 | <__monty__> | That would be cool but I don't believe there is. |
2020-12-30 22:00:01 +0100 | pragma- | (~chaos@unaffiliated/pragmatic-chaos) |
2020-12-30 22:00:05 +0100 | <pragma-> | hi there nf |
2020-12-30 22:00:58 +0100 | <nf> | hi |
2020-12-30 22:01:04 +0100 | ADG1089__ | (~aditya@223.235.213.117) (Quit: Konversation terminated!) |
2020-12-30 22:01:47 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 22:03:11 +0100 | usr256 | (~usr25@unaffiliated/usr25) |
2020-12-30 22:03:41 +0100 | <Cale> | There are some typechecker tracing flags, but it just emits a lot of incoherent debug print gibberish that can't be interpreted without carefully looking at the GHC source code. Nothing like a nice derivation. |
2020-12-30 22:04:31 +0100 | <Cale> | (but if you're trying to fix a bug in GHC, it might be better than nothing) |
2020-12-30 22:04:36 +0100 | ericsagnes | (~ericsagne@2405:6580:0:5100:408c:5ab0:3607:c803) |
2020-12-30 22:05:17 +0100 | usr25 | (~usr25@unaffiliated/usr25) (Ping timeout: 265 seconds) |
2020-12-30 22:06:43 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
2020-12-30 22:06:52 +0100 | <monochrom> | If you don't mind doing basic type inference by hand, see my http://www.vex.net/~trebla/haskell/type-inference.html |
2020-12-30 22:07:39 +0100 | dfeuer | (~dfeuer@pool-108-18-223-60.washdc.fios.verizon.net) |
2020-12-30 22:08:14 +0100 | justsomeguy | (~justsomeg@unaffiliated/--/x-3805311) () |
2020-12-30 22:08:29 +0100 | cr3 | (~cr3@192-222-143-195.qc.cable.ebox.net) |
2020-12-30 22:09:26 +0100 | zincy_ | (~tom@2a00:23c8:970a:3501:38a6:4546:df42:c1cb) |
2020-12-30 22:10:44 +0100 | <nh> | hi nf |
2020-12-30 22:10:50 +0100 | <nf> | hi |
2020-12-30 22:11:06 +0100 | <nh> | have you done much linear types stuff yet |
2020-12-30 22:11:38 +0100 | <nf> | i have not |
2020-12-30 22:12:00 +0100 | <nh> | you should watch this QualifiedDo talk if you haven't already https://www.youtube.com/watch?v=TH3cYp3349A |
2020-12-30 22:12:08 +0100 | <nh> | pretty cool |
2020-12-30 22:12:18 +0100 | <nf> | why thank you |
2020-12-30 22:12:38 +0100 | <Uniaika> | (are you two siblings or something?) |
2020-12-30 22:12:59 +0100 | <nh> | no he copied me |
2020-12-30 22:13:08 +0100 | <nf> | no he copied me |
2020-12-30 22:13:11 +0100 | <nh> | see |
2020-12-30 22:13:42 +0100 | Guest67343 | (~textual@zrcout.mskcc.org) (Quit: Textual IRC Client: www.textualapp.com) |
2020-12-30 22:13:46 +0100 | <Uniaika> | sorry hendrix but I'm going to have to trust the Frenchman in this situation |
2020-12-30 22:13:58 +0100 | <pragma-> | I can confirm that nh came first. |
2020-12-30 22:14:36 +0100 | <nf> | (ok let's stop spamming maybe) |
2020-12-30 22:14:52 +0100 | <nh> | Uniaika: that's not a wise long term strategy |
2020-12-30 22:15:19 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 22:15:32 +0100 | <pragma-> | nh registered Aug 08 03:14:16 2015. nf registered Mar 24 02:20:41 2018. |
2020-12-30 22:16:04 +0100 | <Uniaika> | nh: that is why all my plans are short-term, and gloriously end in a burst of sparkles and flaming jet fuel |
2020-12-30 22:16:43 +0100 | <nh> | sounds exciting |
2020-12-30 22:19:22 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
2020-12-30 22:19:25 +0100 | Shiranai | (beed0d8f@gateway/web/cgi-irc/kiwiirc.com/ip.190.237.13.143) (Quit: Connection closed) |
2020-12-30 22:26:54 +0100 | <ph88_> | can someone explains what is so great about linear types in ghc 9 _ |
2020-12-30 22:28:09 +0100 | <monochrom> | It is not great. |
2020-12-30 22:28:28 +0100 | <ph88_> | ?? |
2020-12-30 22:28:35 +0100 | <monochrom> | .. |
2020-12-30 22:28:44 +0100 | <ph88_> | why they put it in then ? |
2020-12-30 22:29:14 +0100 | <monochrom> | Someone's fascination with linear types. |
2020-12-30 22:29:14 +0100 | <Rembane> | For science! |
2020-12-30 22:29:43 +0100 | <Rembane> | OTOH, they are cleaning up lots of the GHC code to make it easier to change, so there are many good side effects of that implementation. |
2020-12-30 22:29:54 +0100 | <ephemient> | it may be practical to use, but not yet |
2020-12-30 22:29:57 +0100 | <ephemient> | *some day |
2020-12-30 22:30:12 +0100 | <Rembane> | This sounds a bit like the dependent types capabilities of GHC |
2020-12-30 22:30:29 +0100 | <monochrom> | It is unbeneficial to use. It doesn't increase code optimizations or safety. |
2020-12-30 22:30:46 +0100 | ohmysomuchuser | nickednamed |
2020-12-30 22:31:33 +0100 | <ph88_> | so it's to clean up ghc code ?? |
2020-12-30 22:32:16 +0100 | geowiesnot | (~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 246 seconds) |
2020-12-30 22:32:50 +0100 | rmk236 | (~lcampos@2a02:908:3616:b100:849c:a12b:ff95:e193) (Quit: Leaving.) |
2020-12-30 22:33:10 +0100 | <ph88_> | i thought it was a big deal as it was announced :( |
2020-12-30 22:34:58 +0100 | petersen | (~petersen@redhat/juhp) (Quit: petersen) |
2020-12-30 22:35:39 +0100 | petersen | (~petersen@redhat/juhp) |
2020-12-30 22:36:28 +0100 | usr256 | (~usr25@unaffiliated/usr25) (Quit: Leaving) |
2020-12-30 22:38:49 +0100 | Franciman | (~francesco@host-95-250-152-231.retail.telecomitalia.it) (Quit: Leaving) |
2020-12-30 22:39:12 +0100 | <frankdmartinez> | Cale: Thanks. |
2020-12-30 22:39:33 +0100 | <frankdmartinez> | monochrom: That might be a good-enough-for-now approach, thanks. |
2020-12-30 22:40:57 +0100 | mastarija | (~mastarija@93-136-141-206.adsl.net.t-com.hr) |
2020-12-30 22:41:01 +0100 | usr25 | (~usr25@unaffiliated/usr25) |
2020-12-30 22:42:23 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) (Remote host closed the connection) |
2020-12-30 22:43:48 +0100 | geekosaur | (42d52137@66.213.33.55) (Remote host closed the connection) |
2020-12-30 22:44:06 +0100 | Younder | (~john@33.51-174-155.customer.lyse.net) |
2020-12-30 22:44:12 +0100 | DavidEichmann | (~david@98.27.93.209.dyn.plus.net) (Remote host closed the connection) |
2020-12-30 22:49:49 +0100 | aveltras | (uid364989@gateway/web/irccloud.com/x-twzhylkueocqmpyy) |
2020-12-30 22:50:34 +0100 | chang | (~textual@host-173-230-65-85.njjcmar.clients.pavlovmedia.com) |
2020-12-30 22:52:50 +0100 | _noblegas | (uid91066@gateway/web/irccloud.com/x-rwqmwswwleosbyhn) (Quit: Connection closed for inactivity) |
2020-12-30 22:55:20 +0100 | knupfer | (~Thunderbi@200116b82c1638008142ece12d3b6b6b.dip.versatel-1u1.de) (Remote host closed the connection) |
2020-12-30 22:55:28 +0100 | knupfer | (~Thunderbi@200116b82c1638002156902e5c178367.dip.versatel-1u1.de) |
2020-12-30 22:57:05 +0100 | mp___ | (~mp@hell.cx) |
2020-12-30 22:59:02 +0100 | christo | (~chris@81.96.113.213) |
2020-12-30 23:00:02 +0100 | knupfer | (~Thunderbi@200116b82c1638002156902e5c178367.dip.versatel-1u1.de) (Ping timeout: 264 seconds) |
2020-12-30 23:00:19 +0100 | petersen | (~petersen@redhat/juhp) (Quit: petersen) |
2020-12-30 23:00:34 +0100 | Rudd0 | (~Rudd0@185.189.115.108) |
2020-12-30 23:01:00 +0100 | petersen | (~petersen@redhat/juhp) |
2020-12-30 23:02:03 +0100 | mp___ | (~mp@hell.cx) (Ping timeout: 256 seconds) |
2020-12-30 23:03:49 +0100 | hiroaki_ | (~hiroaki@ip4d168e73.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
2020-12-30 23:07:53 +0100 | Younder | (~john@33.51-174-155.customer.lyse.net) (Quit: Leaving) |
2020-12-30 23:09:57 +0100 | coot | (~coot@37.30.60.60.nat.umts.dynamic.t-mobile.pl) (Quit: coot) |
2020-12-30 23:12:19 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
2020-12-30 23:14:39 +0100 | nbloomf | (~nbloomf@2600:1700:ad14:3020:2994:ee4e:2fd6:b5cb) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 23:16:41 +0100 | hiroaki_ | (~hiroaki@ip4d16fa3b.dynamic.kabel-deutschland.de) |
2020-12-30 23:17:11 +0100 | frankdma` | (~user@c-69-249-137-255.hsd1.pa.comcast.net) |
2020-12-30 23:17:29 +0100 | argento | (~argent0@168.227.97.23) (Ping timeout: 272 seconds) |
2020-12-30 23:18:08 +0100 | crblmr | (~carbolyme@matrix.dropacid.net) (Ping timeout: 256 seconds) |
2020-12-30 23:20:07 +0100 | justsomeguy | (~justsomeg@216.186.218.241) |
2020-12-30 23:20:07 +0100 | justsomeguy | (~justsomeg@216.186.218.241) (Changing host) |
2020-12-30 23:20:07 +0100 | justsomeguy | (~justsomeg@unaffiliated/--/x-3805311) |
2020-12-30 23:20:19 +0100 | crblmr | (~carbolyme@matrix.dropacid.net) |
2020-12-30 23:20:37 +0100 | frankdmartinez | (~user@5.181.234.188) (Ping timeout: 264 seconds) |
2020-12-30 23:21:16 +0100 | <Athas> | Are the GHC 9 linear types documented in the user manual yet? |
2020-12-30 23:28:31 +0100 | eruiucuiviucuiv | (dd73e7a2@gateway/web/cgi-irc/kiwiirc.com/ip.221.115.231.162) |
2020-12-30 23:28:40 +0100 | <yushyin> | Athas: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/linear_types.html |
2020-12-30 23:33:29 +0100 | fendor | (~fendor@77.119.128.173.wireless.dyn.drei.com) (Remote host closed the connection) |
2020-12-30 23:33:50 +0100 | <Athas> | Lovely, thanks! |
2020-12-30 23:34:24 +0100 | son0p | (~son0p@181.136.122.143) (Quit: leaving) |
2020-12-30 23:35:12 +0100 | <Athas> | The endless linear arrow syntax debate ended with... 'a %1 -> b'? |
2020-12-30 23:35:33 +0100 | heatsink | (~heatsink@2600:1700:bef1:5e10:c4d1:58bf:ee47:d219) |
2020-12-30 23:35:40 +0100 | plutoniix | (~q@ppp-27-55-80-50.revip3.asianet.co.th) (Ping timeout: 265 seconds) |
2020-12-30 23:35:58 +0100 | Rudd0^ | (~Rudd0@185.189.115.103) |
2020-12-30 23:36:54 +0100 | <merijn> | Athas: Isn't it pretty? :p |
2020-12-30 23:37:42 +0100 | <Athas> | I suppose there is a strong overlap between people who want to use linear types in Haskell and people who like UnicodeSyntax, where it's much prettier anyway. |
2020-12-30 23:38:01 +0100 | <Athas> | I guess this is to possibly support other multiplicities in the future? |
2020-12-30 23:38:48 +0100 | <merijn> | Athas: What's it in unicode syntax, then? |
2020-12-30 23:38:53 +0100 | Rudd0 | (~Rudd0@185.189.115.108) (Ping timeout: 256 seconds) |
2020-12-30 23:39:15 +0100 | <Athas> | ⊸ |
2020-12-30 23:39:17 +0100 | <__monty__> | Looks like not only other multiplicities but also multiplicity polymorphism. |
2020-12-30 23:39:22 +0100 | <Athas> | The lollipop operator. |
2020-12-30 23:39:31 +0100 | <b4er> | There's already quite a lot of multiplicities, not sure how many more you want |
2020-12-30 23:39:51 +0100 | nbloomf | (~nbloomf@2600:1700:ad14:3020:2994:ee4e:2fd6:b5cb) |
2020-12-30 23:41:12 +0100 | <Athas> | Can linear functions be point-free? This documentation is phrased in terms of constraints about how the parameter name is used syntactically. |
2020-12-30 23:41:14 +0100 | <frankdma`> | Sorry, as a new intiate into the wonderful world of Haskell, what benefit is gained by linear types? And, since my first reaction to that syntax is "eww", why was that chosen? |
2020-12-30 23:41:41 +0100 | chang | (~textual@host-173-230-65-85.njjcmar.clients.pavlovmedia.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2020-12-30 23:42:16 +0100 | <Athas> | frankdma`: there is a 100+ comment long GitHub thread about the syntax. I think the reason is that Haskell's lexical rules forbid most syntaxes that might be more "natural", and people can just use the Unicode version anyway. |
2020-12-30 23:42:48 +0100 | <b4er> | It makes compiler optimizations (eg. in-place mutations) much, much easier to implement (correctly) |
2020-12-30 23:43:01 +0100 | <Athas> | Really, if you want multiplicity-polymorphism, then a "good" syntax would be something like 'a -[1]> b', but that's a mixfix operator, which Haskell doesn't allow. |
2020-12-30 23:43:28 +0100 | <dsal> | Athas: super obvious to the reader, though. |
2020-12-30 23:43:41 +0100 | <b4er> | Or you can restructure APIs using linear types to force certain usage patterns (eg. closing handles and such) |
2020-12-30 23:43:44 +0100 | <Athas> | b4er: really? I thought it was mostly about writing unsafe code and then securing it with types to prevent unsafe usage. |
2020-12-30 23:44:20 +0100 | <Athas> | Yes, that latter one is what I've seen people talk about. Are there examples where linear types help optimisations? |
2020-12-30 23:44:35 +0100 | <monochrom> | Actual extra code optimizations and actual extra safety are not coming any time soon. |
2020-12-30 23:44:58 +0100 | Melanie_ | (~Melanie@192-0-134-138.cpe.teksavvy.com) |
2020-12-30 23:44:58 +0100 | <b4er> | Athas, why would it not? |
2020-12-30 23:45:22 +0100 | <b4er> | You got a type with a promise that it gets used only once, so you can reuse that memory safely after that. |
2020-12-30 23:45:27 +0100 | <Athas> | b4er: I just can't think of any offhand. |
2020-12-30 23:45:33 +0100 | Sheilong | (uid293653@gateway/web/irccloud.com/x-lomouarpoiwiahvm) |
2020-12-30 23:45:50 +0100 | <dolio> | Writing things point free is just using various higher order functions, so there doesn't seem to be any reason why you couldn't write linear versions, so long as they are well typed. |
2020-12-30 23:45:57 +0100 | <Athas> | Sure, but Haskell is lazy, so have no idea whether the memory that contains the argument has room for a closure or whatever else you need to put there for the result. |
2020-12-30 23:46:09 +0100 | <Athas> | You'll certainly need to do strictness analysis too. |
2020-12-30 23:46:25 +0100 | <frankdma`> | Athas: Where can I find that comment thread so I can follow the reasoning? |
2020-12-30 23:46:33 +0100 | <monochrom> | Without linear types, today here and now, in fact since several years ago already, if you code up "f :: Int -> Int; f 0 = 4; f n = f (n-1)", n is already in-place mutated, in fact living in a register, no linear typing necessary. |
2020-12-30 23:46:39 +0100 | <Athas> | frankdma`: have fun: https://github.com/ghc-proposals/ghc-proposals/pull/111 |
2020-12-30 23:47:04 +0100 | <frankdma`> | Athas: thanks! |
2020-12-30 23:47:05 +0100 | <Athas> | I haven't read all of it myself. |
2020-12-30 23:47:09 +0100 | <monochrom> | And safety, if you throw IO exceptions, the safety promises of linear typing is broken. |
2020-12-30 23:47:27 +0100 | <yushyin> | frankdma`: see also https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst#lexical… |
2020-12-30 23:48:07 +0100 | <Athas> | I can see using linear types to provide a safe streaming/array API that internally uses unsafe in-place updates. I don't see GHC automatically optimising array code to be in-place, just because you declare your functions linear. |
2020-12-30 23:48:08 +0100 | <b4er> | monochrom, but it gets easier to implement. With your `f` the compiler needs to figure it out by analysing at expressions |
2020-12-30 23:48:31 +0100 | plutoniix | (~q@node-uil.pool-125-24.dynamic.totinternet.net) |
2020-12-30 23:49:01 +0100 | <Athas> | What does it mean that "all fields in algebraic data types are linear"? I can see how it matters for the constructor, but is there more to it? |
2020-12-30 23:49:06 +0100 | <dsal> | I like it when the compiler thinks about my code in ways I don't have to. |
2020-12-30 23:49:59 +0100 | <dsal> | A linear type might make it harder for me to do things I don't intend to do, but for optimizations, I'd rather not tell the compiler what the code is already telling it. |
2020-12-30 23:51:10 +0100 | nickednamed | (~nickednam@037008230172.dynamic-3-poz-k-1-2-0.vectranet.pl) (Quit: Lost terminal) |
2020-12-30 23:51:40 +0100 | __monty__ | (~toonn@unaffiliated/toonn) (Quit: leaving) |
2020-12-30 23:51:42 +0100 | <monochrom> | The real killer optimization promise for linear typing is that your code says it inputs an immutable array and outputs an immutable array of the same type and size, but linearly, for example you're sorting it, so the compiler can use a mutable array behind your back. |
2020-12-30 23:52:07 +0100 | <monochrom> | But I wouldn't hold my breath to wait for GHC to actually do it. |
2020-12-30 23:53:10 +0100 | elfets | (~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) (Quit: Leaving) |
2020-12-30 23:53:25 +0100 | <Athas> | Any code that is sensitive enough to cares about avoiding that copy would want a guarantee that it doesn't happen, rather than relying on a black-box optimiser. |
2020-12-30 23:53:57 +0100 | <Athas> | Especially since linear types make it so relatively easy to just write the imperative code, and then give it a nicer and safe linear interface. |
2020-12-30 23:54:18 +0100 | <tdammers> | a language specification can mandate certain optimizations. like a scheme implementation MUST perform TCO, it's in the spec |
2020-12-30 23:55:01 +0100 | <b4er> | Imagine optimizing/rewriting for linear types just to be like "I can put the cool arrow and it type-checks but it doesn't actually more efficient translations" |
2020-12-30 23:56:48 +0100 | <justsomeguy> | Why are linear types something that Haskellers want in the language? |
2020-12-30 23:57:20 +0100 | <b4er> | Rust. |
2020-12-30 23:57:39 +0100 | <tdammers> | I've actually run into a practical use case |
2020-12-30 23:57:57 +0100 | <Athas> | tdammers: the Scheme specification of TCO is already a bit clumsy I think. It's not clear to me how you'd describe any mandated linearity optimisations. |
2020-12-30 23:58:02 +0100 | <monochrom> | I am one of the haskellers who don't actively want it. |
2020-12-30 23:58:28 +0100 | <tdammers> | Athas: I'm just saying that in general, making some optimizations mandatory in a language spec isn't unheard of |
2020-12-30 23:58:29 +0100 | <Athas> | justsomeguy: I don't want it, but there are people who write code where linear types are useful for describing resource-safe APIs. |
2020-12-30 23:58:43 +0100 | <Athas> | I think Tweag.io put the most work into it. |
2020-12-30 23:59:02 +0100 | <tdammers> | and, yeah, indeed, resource-safe APIs, especially when you need deterministic deallocations |
2020-12-30 23:59:23 +0100 | <Athas> | tdammers: I would say that TCO isn't an optimisation; it's a cost model. It says that certain patterns of recursive functions must have O(1) space usage. |
2020-12-30 23:59:29 +0100 | <justsomeguy> | I guess I should look into the problems that tweag.io want to solve with it. |
2020-12-30 23:59:30 +0100 | <merijn> | That's one of the only reasons I kinda like the idea of linear types anyway |