IRCBrowse

2021/02/14

2021-02-14 00:01:18 +0100frozenErebus(~frozenEre@94.128.81.133) (Ping timeout: 246 seconds)
2021-02-14 00:01:50 +0100sagax(~sagax_nb@213.138.71.146) (Quit: Konversation terminated!)
2021-02-14 00:05:40 +0100neiluj(~jco@91-167-203-101.subs.proxad.net)
2021-02-14 00:05:40 +0100neiluj(~jco@91-167-203-101.subs.proxad.net) (Changing host)
2021-02-14 00:05:40 +0100neiluj(~jco@unaffiliated/neiluj)
2021-02-14 00:06:32 +0100conal(~conal@64.71.133.70)
2021-02-14 00:06:34 +0100olligobber(olligobber@gateway/vpn/privateinternetaccess/olligobber)
2021-02-14 00:08:31 +0100xcmw(~textual@dyn-72-33-2-47.uwnet.wisc.edu)
2021-02-14 00:09:07 +0100mirrorbird(~psutcliff@2a00:801:44d:603d:d116:d5a1:4a2f:a08f) (Quit: Leaving)
2021-02-14 00:11:25 +0100heatsink(~heatsink@2600:1700:bef1:5e10:606c:d5c5:bedc:297d) (Remote host closed the connection)
2021-02-14 00:13:45 +0100fendor(~fendor@77.119.131.57.wireless.dyn.drei.com) (Read error: Connection reset by peer)
2021-02-14 00:14:24 +0100kenran(~kenran@i577BCD12.versanet.de) (Remote host closed the connection)
2021-02-14 00:18:21 +0100justanotheruser(~justanoth@unaffiliated/justanotheruser)
2021-02-14 00:19:09 +0100Tario(~Tario@201.192.165.173) (Ping timeout: 246 seconds)
2021-02-14 00:23:33 +0100__monty__(~toonn@unaffiliated/toonn) (Quit: leaving)
2021-02-14 00:23:41 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-02-14 00:25:21 +0100forgottenone(~forgotten@176.42.25.228) (Quit: Konversation terminated!)
2021-02-14 00:26:24 +0100Tario(~Tario@200.119.186.127)
2021-02-14 00:28:05 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 00:35:32 +0100gehmehgeh(~ircuser1@gateway/tor-sasl/gehmehgeh) (Quit: Leaving)
2021-02-14 00:40:25 +0100vicfred(~vicfred@unaffiliated/vicfred) (Quit: Leaving)
2021-02-14 00:41:35 +0100hyperisco(~hyperisco@104-195-141-253.cpe.teksavvy.com) (Read error: Connection reset by peer)
2021-02-14 00:41:43 +0100vicfred(~vicfred@unaffiliated/vicfred)
2021-02-14 00:43:04 +0100f-a(~f-a@151.46.73.235) (Quit: leaving)
2021-02-14 00:43:44 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 00:44:08 +0100luftmensch(63be4e3e@99-190-78-62.lightspeed.tukrga.sbcglobal.net)
2021-02-14 00:47:16 +0100luftmensch(63be4e3e@99-190-78-62.lightspeed.tukrga.sbcglobal.net) (Client Quit)
2021-02-14 00:48:33 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 264 seconds)
2021-02-14 00:50:11 +0100knupfer(~Thunderbi@i577BCEB5.versanet.de) (Ping timeout: 272 seconds)
2021-02-14 00:50:13 +0100Tario(~Tario@200.119.186.127) (Read error: Connection reset by peer)
2021-02-14 00:50:29 +0100kam1(~kam1@5.125.240.66)
2021-02-14 00:51:55 +0100Tario(~Tario@201.192.165.173)
2021-02-14 00:52:16 +0100tomboy64(~tomboy64@unaffiliated/tomboy64)
2021-02-14 00:52:45 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 01:00:59 +0100jb55(~jb55@gateway/tor-sasl/jb55) (Read error: Connection reset by peer)
2021-02-14 01:00:59 +0100teardown(~user@gateway/tor-sasl/mrush) (Write error: Connection reset by peer)
2021-02-14 01:00:59 +0100srk(~sorki@gateway/tor-sasl/sorki) (Read error: Connection reset by peer)
2021-02-14 01:00:59 +0100hexo(~hexo@gateway/tor-sasl/hexo) (Remote host closed the connection)
2021-02-14 01:00:59 +0100Unhammer(~Unhammer@gateway/tor-sasl/unhammer) (Remote host closed the connection)
2021-02-14 01:01:00 +0100denisse(~spaceCat@gateway/tor-sasl/alephzer0) (Read error: Connection reset by peer)
2021-02-14 01:01:00 +0100cantstanya(~chatting@gateway/tor-sasl/cantstanya) (Read error: Connection reset by peer)
2021-02-14 01:01:00 +0100vgtw(~vgtw@gateway/tor-sasl/vgtw) (Read error: Connection reset by peer)
2021-02-14 01:01:00 +0100xelxebar(~xelxebar@gateway/tor-sasl/xelxebar) (Read error: Connection reset by peer)
2021-02-14 01:01:00 +0100geyaeb(~geyaeb@gateway/tor-sasl/geyaeb) (Read error: Connection reset by peer)
2021-02-14 01:01:00 +0100ChaiTRex(~ChaiTRex@gateway/tor-sasl/chaitrex) (Read error: Connection reset by peer)
2021-02-14 01:01:00 +0100andreas303(~andreas@gateway/tor-sasl/andreas303) (Read error: Connection reset by peer)
2021-02-14 01:01:00 +0100hekkaidekapus_(~tchouri@gateway/tor-sasl/hekkaidekapus) (Write error: Broken pipe)
2021-02-14 01:01:00 +0100finn_elija(~finn_elij@gateway/tor-sasl/finnelija/x-67402716) (Write error: Connection reset by peer)
2021-02-14 01:01:00 +0100gioyik(~gioyik@gateway/tor-sasl/gioyik) (Write error: Connection reset by peer)
2021-02-14 01:01:25 +0100aliuser(~aliuser@45.83.27.135)
2021-02-14 01:01:29 +0100aliuser(~aliuser@45.83.27.135) (K-Lined)
2021-02-14 01:02:01 +0100LittleFox(~littlefox@rondra.lf-net.org) (Quit: ZNC 1.7.2+deb3 - https://znc.in)
2021-02-14 01:02:02 +0100Deide(~Deide@217.155.19.23) (Quit: Seeee yaaaa)
2021-02-14 01:02:07 +0100ph88^(~ph88@2a02:8109:9e00:7e5c:d5a3:7dbb:e434:b544) (Ping timeout: 272 seconds)
2021-02-14 01:02:12 +0100LittleFox(~littlefox@rondra.lf-net.org)
2021-02-14 01:02:35 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 01:02:44 +0100LittleFox(~littlefox@rondra.lf-net.org) (Client Quit)
2021-02-14 01:02:54 +0100LittleFox(~littlefox@rondra.lf-net.org)
2021-02-14 01:02:57 +0100ph88^(~ph88@2a02:8109:9e00:7e5c:d5a3:7dbb:e434:b544)
2021-02-14 01:03:29 +0100xelxebar(~xelxebar@gateway/tor-sasl/xelxebar)
2021-02-14 01:03:33 +0100hexo(~hexo@gateway/tor-sasl/hexo)
2021-02-14 01:03:35 +0100srk(~sorki@gateway/tor-sasl/sorki)
2021-02-14 01:04:13 +0100geyaeb(~geyaeb@gateway/tor-sasl/geyaeb)
2021-02-14 01:04:16 +0100gioyik(~gioyik@gateway/tor-sasl/gioyik)
2021-02-14 01:04:24 +0100finn_elija(~finn_elij@gateway/tor-sasl/finnelija/x-67402716)
2021-02-14 01:04:32 +0100ChaiTRex(~ChaiTRex@gateway/tor-sasl/chaitrex)
2021-02-14 01:04:36 +0100jb55(~jb55@gateway/tor-sasl/jb55)
2021-02-14 01:04:39 +0100denisse(~spaceCat@gateway/tor-sasl/alephzer0)
2021-02-14 01:04:41 +0100andreas303(~andreas@gateway/tor-sasl/andreas303)
2021-02-14 01:05:51 +0100jb55(~jb55@gateway/tor-sasl/jb55) (Remote host closed the connection)
2021-02-14 01:06:19 +0100jb55(~jb55@gateway/tor-sasl/jb55)
2021-02-14 01:07:09 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 264 seconds)
2021-02-14 01:10:52 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 01:11:12 +0100xcmw(~textual@dyn-72-33-2-47.uwnet.wisc.edu) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-02-14 01:11:36 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds)
2021-02-14 01:11:46 +0100teardown(~user@gateway/tor-sasl/mrush)
2021-02-14 01:11:49 +0100heatsink(~heatsink@2600:1700:bef1:5e10:606c:d5c5:bedc:297d)
2021-02-14 01:15:10 +0100hiroaki(~hiroaki@ip4d166d67.dynamic.kabel-deutschland.de) (Quit: Leaving)
2021-02-14 01:16:50 +0100heatsink(~heatsink@2600:1700:bef1:5e10:606c:d5c5:bedc:297d) (Ping timeout: 264 seconds)
2021-02-14 01:17:09 +0100hiroaki(~hiroaki@ip4d166d67.dynamic.kabel-deutschland.de)
2021-02-14 01:17:20 +0100vgtw(~vgtw@gateway/tor-sasl/vgtw)
2021-02-14 01:18:15 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 01:19:45 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net) (Ping timeout: 240 seconds)
2021-02-14 01:19:51 +0100atraii(~atraii@2601:681:8800:a991:b78:7e8b:3676:bb2c) (Ping timeout: 272 seconds)
2021-02-14 01:20:33 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net)
2021-02-14 01:20:54 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-02-14 01:25:14 +0100hekkaidekapus_(~tchouri@gateway/tor-sasl/hekkaidekapus)
2021-02-14 01:25:59 +0100sh9(~sh9@softbank060116136158.bbtec.net)
2021-02-14 01:26:14 +0100jb55(~jb55@gateway/tor-sasl/jb55) (Ping timeout: 268 seconds)
2021-02-14 01:27:34 +0100Unhammer(~Unhammer@gateway/tor-sasl/unhammer)
2021-02-14 01:27:52 +0100cantstanya(~chatting@gateway/tor-sasl/cantstanya)
2021-02-14 01:32:21 +0100dhil(~dhil@80.208.56.181) (Ping timeout: 264 seconds)
2021-02-14 01:32:38 +0100jumper149(~jumper149@130.75.103.194) (Ping timeout: 272 seconds)
2021-02-14 01:33:07 +0100pineapples[m](pineapples@gateway/shell/matrix.org/x-pbxgbqdlizpfukkk)
2021-02-14 01:33:52 +0100dcoutts_(~duncan@85.186.125.91.dyn.plus.net)
2021-02-14 01:35:01 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 01:35:48 +0100dcoutts(~dcoutts@unaffiliated/dcoutts) (Ping timeout: 246 seconds)
2021-02-14 01:36:12 +0100dcoutts(~dcoutts@unaffiliated/dcoutts)
2021-02-14 01:36:25 +0100dcoutts__(~duncan@85.186.125.91.dyn.plus.net) (Ping timeout: 240 seconds)
2021-02-14 01:36:29 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 01:37:32 +0100stef204(~stef204@unaffiliated/stef-204/x-384198) (Ping timeout: 260 seconds)
2021-02-14 01:38:13 +0100 <pineapples[m]> Is there a reason that the folding function that foldr and foldl both take, has reversed order? i.e., for foldr, the first argument is of type `(a -> b -> b)`, such that `a` represents the type of the current element of the list, and `b` represents the type of the accumulator, but for `foldl`, the type is instead `(b -> a -> b)`, such that the accumulator comes on the right? Was this just done to make things easier to
2021-02-14 01:38:13 +0100 <pineapples[m]> remember? Or for tail recursion optimization? I'm finding this difficult to remember...
2021-02-14 01:38:28 +0100 <pineapples[m]> * Is there a reason that the folding function that foldr and foldl both take, has reversed order? i.e., for `foldr`, the first argument is of type `(a -> b -> b)`, such that `a` represents the type of the current element of the list, and `b` represents the type of the accumulator, but for `foldl`, the type is instead `(b -> a -> b)`, such that the accumulator comes on the right? Was this just done to make things
2021-02-14 01:38:28 +0100 <pineapples[m]> easier to remember? Or for tail recursion optimization? I'm finding this difficult to remember...
2021-02-14 01:38:41 +0100 <pineapples[m]> * Is there a reason that the folding function that foldr and foldl both take, has reversed order? i.e., for `foldr`, the first argument is of type `(a -> b -> b)`, such that `a` represents the type of the current element of the list, and `b` represents the type of the accumulator, but for `foldl`, the type is instead `(b -> a -> b)`, such that the accumulator comes on the left? Was this just done to make things easier
2021-02-14 01:38:41 +0100 <pineapples[m]> to remember? Or for tail recursion optimization? I'm finding this difficult to remember...
2021-02-14 01:38:45 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 01:39:33 +0100jb55(~jb55@gateway/tor-sasl/jb55)
2021-02-14 01:41:16 +0100conal(~conal@64.71.133.70) (Read error: Connection reset by peer)
2021-02-14 01:42:39 +0100 <monochrom> No important reason. But I find this order a good mnemonic.
2021-02-14 01:42:54 +0100 <monochrom> I heard that the ocaml library uses the opposite order.
2021-02-14 01:43:01 +0100 <monochrom> It really doesn't matter.
2021-02-14 01:44:05 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-02-14 01:45:29 +0100conal(~conal@64.71.133.70)
2021-02-14 01:45:32 +0100 <hpc> if it helps, foldr follows the type's order
2021-02-14 01:45:35 +0100 <hpc> like maybe, either, etc
2021-02-14 01:45:48 +0100 <hpc> and curry, i suppose
2021-02-14 01:45:53 +0100 <hpc> :t maybe
2021-02-14 01:45:54 +0100 <lambdabot> b -> (a -> b) -> Maybe a -> b
2021-02-14 01:46:22 +0100 <hpc> data Maybe a = Nothing | Just a
2021-02-14 01:46:44 +0100 <hpc> to come up with the type for maybe, go through the types of the constructors for Maybe in order, and replace (Maybe a) with b
2021-02-14 01:46:50 +0100 <hpc> do the same thing for [] and you have foldr
2021-02-14 01:46:52 +0100 <hpc> :t foldr
2021-02-14 01:46:53 +0100 <lambdabot> Foldable t => (a -> b -> b) -> b -> t a -> b
2021-02-14 01:46:57 +0100 <pineapples[m]> hpc: what do you mean by the type's order?
2021-02-14 01:47:12 +0100 <hpc> data [] a = [] | (:) a [a]
2021-02-14 01:47:46 +0100 <hpc> oh, that's annoying, foldr's arguments are backwards
2021-02-14 01:48:33 +0100 <hpc> but basically, the way you remember (a -> b -> b) is from the type of (:)
2021-02-14 01:48:35 +0100 <hpc> :t (:)
2021-02-14 01:48:37 +0100 <lambdabot> a -> [a] -> [a]
2021-02-14 01:48:50 +0100 <hpc> mentally replace [a] with b, and there you go
2021-02-14 01:48:57 +0100 <monochrom> It's OK, it's the a->b->b order we have in mind, and it follows (:)'s order.
2021-02-14 01:49:37 +0100 <monochrom> And foldl's is the accumulator steamrolling from left to right so it's b->a->b.
2021-02-14 01:49:55 +0100 <pineapples[m]> Right, for `foldr` it's `a -> b -> b`, so the replacement works with (:)
2021-02-14 01:49:58 +0100dxld(~dxld@rush.pub.dxld.at) (Remote host closed the connection)
2021-02-14 01:50:06 +0100 <pineapples[m]> `foldl` is `b -> a -> b`
2021-02-14 01:50:07 +0100 <pineapples[m]> Hmm
2021-02-14 01:50:16 +0100 <monochrom> So that's easy to remember.
2021-02-14 01:50:20 +0100 <hpc> for extra credit, extend foldr to work on trees :D
2021-02-14 01:51:12 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 246 seconds)
2021-02-14 01:51:15 +0100 <hpc> a nice property foldr has too, is foldr (:) [] = id
2021-02-14 01:51:22 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-02-14 01:51:32 +0100conal(~conal@64.71.133.70) (Quit: Computer has gone to sleep.)
2021-02-14 01:52:05 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2021-02-14 01:53:06 +0100dxld(~dxld@80-109-136-248.cable.dynamic.surfer.at)
2021-02-14 01:54:58 +0100neiluj(~jco@unaffiliated/neiluj) (Ping timeout: 256 seconds)
2021-02-14 01:55:00 +0100heatsink(~heatsink@2600:1700:bef1:5e10:606c:d5c5:bedc:297d)
2021-02-14 01:55:11 +0100conal(~conal@64.71.133.70)
2021-02-14 01:57:56 +0100xcmw(~textual@dyn-72-33-2-47.uwnet.wisc.edu)
2021-02-14 02:00:59 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 02:02:22 +0100jedws(~jedws@101.184.202.248)
2021-02-14 02:03:20 +0100Feuermagier(~Feuermagi@2a02:2488:4211:3400:246e:bf09:8453:9d6) (Remote host closed the connection)
2021-02-14 02:13:34 +0100m0rphism1(~m0rphism@HSI-KBW-085-216-104-059.hsi.kabelbw.de) (Ping timeout: 268 seconds)
2021-02-14 02:14:28 +0100jamm_(~jamm@unaffiliated/jamm)
2021-02-14 02:15:52 +0100cole-h(~cole-h@c-73-48-197-220.hsd1.ca.comcast.net)
2021-02-14 02:15:59 +0100rajivr(uid269651@gateway/web/irccloud.com/x-pdqpqnvxjwncrovd)
2021-02-14 02:18:29 +0100tremon(~aschuring@217-63-61-89.cable.dynamic.v4.ziggo.nl) (Quit: getting boxed in)
2021-02-14 02:18:57 +0100jamm_(~jamm@unaffiliated/jamm) (Ping timeout: 260 seconds)
2021-02-14 02:19:21 +0100Guest_70(d4e848ca@212.232.72.202) (Quit: Connection closed)
2021-02-14 02:23:37 +0100libertyprime(~libertypr@124.197.60.232) (Remote host closed the connection)
2021-02-14 02:25:41 +0100ezrakilty(~ezrakilty@75-172-120-208.tukw.qwest.net) (Remote host closed the connection)
2021-02-14 02:25:44 +0100Rudd0(~Rudd0@185.189.115.108) (Ping timeout: 240 seconds)
2021-02-14 02:27:23 +0100elfets(~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) (Quit: Leaving)
2021-02-14 02:29:32 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 02:31:01 +0100tribble2(~tribble2@unaffiliated/tribble2)
2021-02-14 02:35:32 +0100plutoniix(~q@node-ug9.pool-125-24.dynamic.totinternet.net)
2021-02-14 02:38:29 +0100hiroaki(~hiroaki@ip4d166d67.dynamic.kabel-deutschland.de) (Ping timeout: 272 seconds)
2021-02-14 02:40:23 +0100 <minoru_shiraeesh> are there good, easy to follow resources explaining how the `evaluate` function works?
2021-02-14 02:40:46 +0100 <c_wraith> evaluate is a weird thing to need. Are you sure that's what you actually want?
2021-02-14 02:40:54 +0100 <minoru_shiraeesh> it is mentioned briefly in the book I'm reading
2021-02-14 02:41:01 +0100 <minoru_shiraeesh> here is a snippet: https://paste.tomsmeding.com/BWPp6agN
2021-02-14 02:41:21 +0100 <minoru_shiraeesh> it is mentioned in the context of exceptions
2021-02-14 02:41:41 +0100 <minoru_shiraeesh> catching them to be specific
2021-02-14 02:41:56 +0100 <c_wraith> I suppose that *is* the one case where its details are actually important
2021-02-14 02:42:13 +0100 <dmj`> minoru_shiraeesh: http://hackage.haskell.org/package/base-4.14.1.0/docs/Control-Exception.html#v:evaluate has good docs
2021-02-14 02:42:46 +0100 <c_wraith> you can't say that. If you point out that the documentation is actually good, the mob will come after you
2021-02-14 02:44:07 +0100 <koz_> [0 .. (- 1)]
2021-02-14 02:44:13 +0100 <koz_> > [0 .. (- 1)]
2021-02-14 02:44:15 +0100 <lambdabot> []
2021-02-14 02:46:06 +0100 <dmj`> c_wraith: let them come
2021-02-14 02:47:29 +0100carlomagno1(~cararell@148.87.23.12) (Remote host closed the connection)
2021-02-14 02:48:02 +0100jedws(~jedws@101.184.202.248) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-02-14 02:48:11 +0100Tuplanolla(~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) (Quit: Leaving.)
2021-02-14 02:49:05 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net) (Ping timeout: 240 seconds)
2021-02-14 02:49:47 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net)
2021-02-14 02:51:40 +0100usr25(~usr25@unaffiliated/usr25) (Quit: Leaving)
2021-02-14 02:51:44 +0100 <minoru_shiraeesh> so the `catch` becomes useless if you use `return` instead of `evaluate`, that's such a subtlety
2021-02-14 02:52:10 +0100 <c_wraith> that particular point isn't the subtlety. That's crucial for understanding haskell
2021-02-14 02:52:12 +0100 <minoru_shiraeesh> it would be good if compiler helped to prevent useless catches
2021-02-14 02:52:38 +0100 <c_wraith> the subtlety is that evaluate x is different from return $! x
2021-02-14 02:53:25 +0100 <minoru_shiraeesh> dmj`: thanks for the link btw
2021-02-14 02:53:52 +0100 <dmj`> minoru_shiraeesh: cheers
2021-02-14 02:54:06 +0100dmj`buttons vest back up
2021-02-14 02:55:55 +0100Sheilong(uid293653@gateway/web/irccloud.com/x-wprlceqhkwfmdjez) (Quit: Connection closed for inactivity)
2021-02-14 02:59:57 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 264 seconds)
2021-02-14 03:01:28 +0100 <minoru_shiraeesh> intuitively one would expect catch to work with return, the `catch` function returns a description of an action to take, it could as well add "oh, btw, this thing catches this exception when run"
2021-02-14 03:01:49 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 03:02:17 +0100 <c_wraith> intuitively, return does nothing to a pure computation. If it's a bottom, it stays a bottom.
2021-02-14 03:03:02 +0100 <minoru_shiraeesh> yeah, when you return something, you get a description of an action
2021-02-14 03:03:11 +0100 <c_wraith> actually, the monad laws are kind of precise there.
2021-02-14 03:03:46 +0100 <c_wraith> return undefined >> const (pure ()) must be equivalent to const (pure ()) undefined
2021-02-14 03:03:58 +0100 <c_wraith> but you're asking for return to do more than that
2021-02-14 03:04:22 +0100 <minoru_shiraeesh> when you streamline that description through `catch`, it would make sense to expect it to add its logic to the description, right? Maybe there is something wrong with the mental model I'm working with.
2021-02-14 03:05:21 +0100 <c_wraith> catch's model is "if executing this IO action raises an exception of the expected type, return Left of that exception"
2021-02-14 03:05:29 +0100 <minoru_shiraeesh> I mean, do you agree that this thing doesn't make much sense and you just have to memorize it?
2021-02-14 03:05:34 +0100 <c_wraith> note that it's about executing IO, not evaluating expressions
2021-02-14 03:06:03 +0100 <c_wraith> If the IO action you pass to it doesn't raise any exceptions, that's not catch doing anything wrong
2021-02-14 03:06:22 +0100 <c_wraith> and pure/return can't raise exceptions in pure code, as doing so would violate the monad laws
2021-02-14 03:06:53 +0100ph88^(~ph88@2a02:8109:9e00:7e5c:d5a3:7dbb:e434:b544) (Ping timeout: 272 seconds)
2021-02-14 03:07:09 +0100 <c_wraith> the critical part is separating execution from evaluation
2021-02-14 03:07:21 +0100 <c_wraith> they are separate processes
2021-02-14 03:07:37 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 272 seconds)
2021-02-14 03:07:39 +0100 <c_wraith> (that's pretty critical for working with Haskell in general)
2021-02-14 03:07:49 +0100 <monochrom> It makes a lot of sense to me. What you're looking at is turning some bottoms (but not all) into exceptions. That's going to exceed every simple model.
2021-02-14 03:08:50 +0100 <zebrag> What is it with G being always below F? Is it because if you are forgetful you are necessarily deemed lesser than if you are free. (Don't answer that.)
2021-02-14 03:09:19 +0100 <monochrom> I thought F was below G.
2021-02-14 03:10:01 +0100 <MarcelineVQ> weird, for me f and g are right next to each other
2021-02-14 03:10:03 +0100 <minoru_shiraeesh> hmm, looks like there is some incompatibility between monads and exceptions
2021-02-14 03:10:36 +0100 <monochrom> No, it's an incompatibility between purity and exceptions.
2021-02-14 03:11:06 +0100DataComputist(~lumeng@50.43.26.251) (Remote host closed the connection)
2021-02-14 03:11:51 +0100 <monochrom> bottom is in the pure world, exception is in the control-flow world. But some people still want to convert the former to the latter.
2021-02-14 03:12:12 +0100 <monochrom> OK, it can be done, but it is not going to be intuitive. People deserve the mess they asked for.
2021-02-14 03:12:28 +0100 <zebrag> Well it's below if you like your natural transforms downward, personally I like them horizontal.
2021-02-14 03:13:10 +0100 <minoru_shiraeesh> c_wraith: "and pure/return can't raise exceptions in pure code, as doing so would violate the monad laws"
2021-02-14 03:13:15 +0100 <minoru_shiraeesh> I don't get this part
2021-02-14 03:13:29 +0100 <minoru_shiraeesh> they don't raise exception immediately
2021-02-14 03:13:34 +0100 <minoru_shiraeesh> *exceptions
2021-02-14 03:13:39 +0100 <c_wraith> the expression (return undefined) cannot raise an exception.
2021-02-14 03:13:43 +0100 <c_wraith> that monad laws forbid it
2021-02-14 03:13:52 +0100 <dsal> I managed to build a program on my new Mac (and have it run) using nix. I look forward to a future where it's not so emulated.
2021-02-14 03:14:10 +0100 <zebrag> It's below there: https://bartoszmilewski.com/2016/04/18/adjunctions/
2021-02-14 03:14:40 +0100jedws(~jedws@101.184.202.248)
2021-02-14 03:15:50 +0100 <c_wraith> therefore (catch (return undefined)) cannot catch anything. That's just how it goes.
2021-02-14 03:15:57 +0100 <minoru_shiraeesh> pure/return just give you a description of an action, right? but the action itself can raise exceptions - not immediately, when constructing the structure, but later, when run
2021-02-14 03:16:26 +0100 <monochrom> zebrag, if one day you become as famous as Bartosz, and someone sees you drawing horizontally, therefore, I don't know, maybe you put F on the left and G on the right, and someone asks "why not the other way round?", what should I answer? You see what I mean?
2021-02-14 03:17:00 +0100 <c_wraith> minoru_shiraeesh: no, they give you an action, not a description of one.
2021-02-14 03:17:21 +0100 <monochrom> You make an arbitrary choice that completely doesn't matter, then you become a big shot, then someone is going to overthink your arbitrary choice.
2021-02-14 03:18:16 +0100 <minoru_shiraeesh> yes, they give an action, and what's wrong with adding "I'm going to return this action, and this action may raise an exception"?
2021-02-14 03:18:51 +0100 <minoru_shiraeesh> adding this clause to the description of an action is not the same as raising an exception when constructing an action, right?
2021-02-14 03:18:59 +0100 <c_wraith> because that would violate the monad laws
2021-02-14 03:19:16 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-02-14 03:19:19 +0100 <c_wraith> return x >>= f must behave the same as f x
2021-02-14 03:19:33 +0100xff0x(~xff0x@2001:1a81:52bc:5400:1105:83cf:5342:8ee4) (Ping timeout: 272 seconds)
2021-02-14 03:20:06 +0100wz1000(~wz1000@static.11.113.47.78.clients.your-server.de) (Ping timeout: 246 seconds)
2021-02-14 03:20:33 +0100 <sclv> is bodigrim on irc?
2021-02-14 03:21:02 +0100xff0x(~xff0x@2001:1a81:52f8:8e00:3f0c:a02c:d901:27bc)
2021-02-14 03:22:40 +0100 <minoru_shiraeesh> c_wraith: "return x >>= f must behave the same as f x" - how does this apply to the context of `evaluate` and exceptions?
2021-02-14 03:22:59 +0100 <minoru_shiraeesh> you put `catch` in place of `f`?
2021-02-14 03:23:25 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Ping timeout: 240 seconds)
2021-02-14 03:23:25 +0100 <minoru_shiraeesh> hmm, no
2021-02-14 03:25:19 +0100 <minoru_shiraeesh> if the `x` is going to raise an exception, then they will behave the same way, no?
2021-02-14 03:25:40 +0100 <c_wraith> consider f = const (return ())
2021-02-14 03:26:13 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 03:26:40 +0100 <minoru_shiraeesh> so f doesn't evaluate `x`?
2021-02-14 03:26:44 +0100 <c_wraith> nope
2021-02-14 03:28:07 +0100 <minoru_shiraeesh> ok, but where is the violation of monad laws if `return` were to raise "catchable" exceptions?
2021-02-14 03:29:05 +0100 <c_wraith> f = const (return ()) ; x = undefined ; returnOrThrow x >>= f is bottom, f x is not
2021-02-14 03:30:35 +0100 <zebrag> monochrom: indeed. I don't know why I made my silly comment in the first place. Maybe because it was a good mnemonic for the Bartosz's diagrams.
2021-02-14 03:30:41 +0100Lord_of_Life_(~Lord@unaffiliated/lord-of-life/x-0885362)
2021-02-14 03:31:58 +0100 <minoru_shiraeesh> `returnOrThrow` throws immediately?
2021-02-14 03:32:12 +0100 <c_wraith> if it doesn't, it's identical to the current return
2021-02-14 03:32:16 +0100Lord_of_Life(~Lord@unaffiliated/lord-of-life/x-0885362) (Ping timeout: 240 seconds)
2021-02-14 03:32:16 +0100Lord_of_Life_Lord_of_Life
2021-02-14 03:32:17 +0100 <minoru_shiraeesh> and `catch` catches exceptions that were immediately thrown?
2021-02-14 03:32:29 +0100 <minoru_shiraeesh> I think I understand now
2021-02-14 03:32:55 +0100 <c_wraith> it really isn't a conspiracy to get you. That's just what it has to do
2021-02-14 03:33:52 +0100 <minoru_shiraeesh> and the first thing that comes to mind in this sutuation is to introduce a function something like `catchWhenRun`
2021-02-14 03:34:33 +0100 <minoru_shiraeesh> evaluation an expression just to catch an expression looks like a perversion
2021-02-14 03:34:44 +0100 <swarmcollective> c_wraith, would you explain "bottom" used here `returnOrThrow x >>= f is bottom, f x is not` ? I am not familiar with that term in that context.
2021-02-14 03:34:46 +0100 <minoru_shiraeesh> it's supposed to be lazy
2021-02-14 03:36:56 +0100clog(~nef@bespin.org) (Ping timeout: 240 seconds)
2021-02-14 03:37:34 +0100 <c_wraith> Bottom is a general term for any sort of non-returning behavior. Could be an infinite loop, could be an exception, etc
2021-02-14 03:38:04 +0100xcmw(~textual@dyn-72-33-2-47.uwnet.wisc.edu) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-02-14 03:38:30 +0100plutoniix(~q@node-ug9.pool-125-24.dynamic.totinternet.net) (Quit: Leaving)
2021-02-14 03:38:51 +0100 <c_wraith> \f -> catch (f >>= evaluate)
2021-02-14 03:39:00 +0100Sheilong(uid293653@gateway/web/irccloud.com/x-iidzzuqrwayebdaf)
2021-02-14 03:39:18 +0100 <c_wraith> :t \x -> catch (x >>= evaluate)
2021-02-14 03:39:19 +0100 <lambdabot> Exception e => IO a -> (e -> IO a) -> IO a
2021-02-14 03:39:32 +0100 <c_wraith> there you go. Your catch that always forces the evaluation.
2021-02-14 03:39:37 +0100 <swarmcollective> Ah, thank you!
2021-02-14 03:39:51 +0100 <c_wraith> Here's the thing: That's *not* really what catch is for.
2021-02-14 03:40:10 +0100 <c_wraith> catch is *really* for IO exception. the FileNotFounds of the world.
2021-02-14 03:40:25 +0100seemtav_(~seemtav3@bcde0474.skybroadband.com) (Ping timeout: 240 seconds)
2021-02-14 03:41:20 +0100 <c_wraith> that was sort of monochrom's point about purity and exceptions being a weird mix
2021-02-14 03:42:12 +0100 <c_wraith> We allow raising exceptions from pure code, which is sort of a weird thing.
2021-02-14 03:42:20 +0100 <c_wraith> So catching them is also sort of a weird thing.
2021-02-14 03:44:44 +0100 <minoru_shiraeesh> I meant something like a "lazy catch"
2021-02-14 03:44:59 +0100 <c_wraith> that's sort of time travel
2021-02-14 03:44:59 +0100 <minoru_shiraeesh> "lazy catch" for "lazy exceptions"
2021-02-14 03:45:11 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr)
2021-02-14 03:46:21 +0100 <minoru_shiraeesh> the "catch" that doesn't force anything, just defers catching for later
2021-02-14 03:46:52 +0100 <c_wraith> so... time travel
2021-02-14 03:47:23 +0100 <minoru_shiraeesh> I don't see how it is time travel
2021-02-14 03:49:28 +0100 <minoru_shiraeesh> imagine writing let x = try somethingThatRaises; case x of ... and then you pattern-match on either
2021-02-14 03:49:51 +0100hiptobecubic(~john@unaffiliated/hiptobecubic) (Ping timeout: 246 seconds)
2021-02-14 03:49:51 +0100 <c_wraith> consider setting mutable variables from the handler. If you haven't inspected the result, what do you read from the mutable variable?
2021-02-14 03:51:29 +0100 <minoru_shiraeesh> why suppose that I haven't inspected the result?
2021-02-14 03:51:37 +0100 <c_wraith> because that's the only time laziness matters
2021-02-14 03:52:19 +0100 <minoru_shiraeesh> you can return either and then pattern match it, right?
2021-02-14 03:52:36 +0100 <minoru_shiraeesh> and you can encode a lazy logic like that
2021-02-14 03:53:10 +0100 <minoru_shiraeesh> that's basically what catching an exception is, isn' it?
2021-02-14 03:53:10 +0100 <c_wraith> If you're going to be inspecting it immediately, what's wrong with my suggestion above?
2021-02-14 03:53:38 +0100 <minoru_shiraeesh> what suggestion?
2021-02-14 03:55:01 +0100 <c_wraith> well, I suggested \x -> catch (x >>= evaluate), but maybe you'd prefer \x -> try (x >>= evaluate)
2021-02-14 03:56:16 +0100 <minoru_shiraeesh> do I have to use `evaluate` with `try` too?
2021-02-14 03:56:34 +0100 <c_wraith> it's also for IO exceptions, yes
2021-02-14 03:58:47 +0100xcmw(~textual@dyn-72-33-2-47.uwnet.wisc.edu)
2021-02-14 04:00:05 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2021-02-14 04:00:50 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 272 seconds)
2021-02-14 04:03:34 +0100alx741(~alx741@186.178.108.225)
2021-02-14 04:04:21 +0100ezrakilty(~ezrakilty@75-172-120-208.tukw.qwest.net)
2021-02-14 04:05:28 +0100__minoru__shirae(~shiraeesh@109.166.57.144)
2021-02-14 04:07:09 +0100minoru_shiraeesh(~shiraeesh@109.166.57.144) (Ping timeout: 264 seconds)
2021-02-14 04:08:57 +0100ezrakilty(~ezrakilty@75-172-120-208.tukw.qwest.net) (Ping timeout: 264 seconds)
2021-02-14 04:10:06 +0100Feuermagier(~Feuermagi@2a02:2488:4211:3400:246e:bf09:8453:9d6)
2021-02-14 04:14:30 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 04:15:23 +0100stef204(~stef204@unaffiliated/stef-204/x-384198)
2021-02-14 04:16:48 +0100idhugo(~idhugo@80-62-117-97-mobile.dk.customer.tdc.net)
2021-02-14 04:16:57 +0100Sheilong(uid293653@gateway/web/irccloud.com/x-iidzzuqrwayebdaf) ()
2021-02-14 04:19:42 +0100dyeplexer(~lol@unaffiliated/terpin)
2021-02-14 04:19:45 +0100 <__minoru__shirae> looks like `try` acts the "lazy catch" I was talking about
2021-02-14 04:19:56 +0100 <__minoru__shirae> *act like
2021-02-14 04:20:01 +0100 <__minoru__shirae> *acts like
2021-02-14 04:20:58 +0100Gurkenglas(~Gurkengla@unaffiliated/gurkenglas)
2021-02-14 04:21:36 +0100 <__minoru__shirae> turns out the documentation recommends `try` over `catch` for regular exceptions, and recommends `catch` for asynchronous exceptions.
2021-02-14 04:22:24 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 246 seconds)
2021-02-14 04:24:50 +0100 <__minoru__shirae> and to add to the confusion `try` is implemented using `catch`?
2021-02-14 04:24:54 +0100 <__minoru__shirae> try a = catch (Right `liftM` a) (return . Left)
2021-02-14 04:27:17 +0100 <__minoru__shirae> (╯°□°）╯︵ ┻━┻
2021-02-14 04:27:38 +0100 <glguy> __minoru__shirae, why is that confusing?
2021-02-14 04:28:18 +0100 <__minoru__shirae> glguy: we were discussing this snippet from a book: https://paste.tomsmeding.com/BWPp6agN
2021-02-14 04:29:41 +0100 <glguy> OK. Yes, you'd prefer to use try or catch in: try (evaluate x)
2021-02-14 04:29:46 +0100 <monochrom> try is not lazier than catch
2021-02-14 04:29:53 +0100FinnElija(~finn_elij@gateway/tor-sasl/finnelija/x-67402716)
2021-02-14 04:29:53 +0100finn_elijaGuest80175
2021-02-14 04:29:53 +0100FinnElijafinn_elija
2021-02-14 04:30:03 +0100 <glguy> the difference in try and catch is about how long async exceptions are masked
2021-02-14 04:30:08 +0100 <monochrom> nor does it kill laziness
2021-02-14 04:30:08 +0100 <glguy> nothing about laziness at all
2021-02-14 04:30:32 +0100 <monochrom> try (return (div 1 0)) still doesn't do what you think.
2021-02-14 04:30:51 +0100 <monochrom> Have you actually written actual code to test any of your understanding?
2021-02-14 04:31:52 +0100 <__minoru__shirae> so, that weird behavior in the example from the book is related exactly to `return` and `catch`? If you don't use `return` - there's no weirdness like that, right?
2021-02-14 04:32:08 +0100 <__minoru__shirae> I think it's getting clearer to me now
2021-02-14 04:32:17 +0100 <glguy> __minoru__shirae, what was the alernative to return you're thinking of?
2021-02-14 04:32:49 +0100 <__minoru__shirae> using try with an action in the middle of a do block
2021-02-14 04:33:42 +0100Guest80175(~finn_elij@gateway/tor-sasl/finnelija/x-67402716) (Ping timeout: 268 seconds)
2021-02-14 04:35:39 +0100 <__minoru__shirae> monochrom: no, I haven't
2021-02-14 04:35:49 +0100 <monochrom> I wonder why.
2021-02-14 04:36:56 +0100 <__minoru__shirae> too tedious I think
2021-02-14 04:37:39 +0100 <__minoru__shirae> and it's not convenient to write functions in ghci
2021-02-14 04:37:53 +0100 <monochrom> So use an editor and :load
2021-02-14 04:38:14 +0100 <monochrom> OK I'm done. This is counterproductive.
2021-02-14 04:39:07 +0100wideEyedPupil(~wideEyedP@121.211.80.53)
2021-02-14 04:40:21 +0100machinedgod(~machinedg@135-23-192-217.cpe.pppoe.ca) (Quit: leaving)
2021-02-14 04:40:36 +0100wideEyedPupil(~wideEyedP@121.211.80.53) ()
2021-02-14 04:41:16 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 04:41:25 +0100hololeap(~hololeap@unaffiliated/hololeap) (Ping timeout: 240 seconds)
2021-02-14 04:42:05 +0100Gurkenglas(~Gurkengla@unaffiliated/gurkenglas) (Ping timeout: 240 seconds)
2021-02-14 04:42:15 +0100 <__minoru__shirae> monochrom: I can run functions, but I can't have an actual conversation with a compiler, right?
2021-02-14 04:43:16 +0100 <__minoru__shirae> it's the conversation that I'm interested in
2021-02-14 04:43:39 +0100ph88^(~ph88@2a02:8109:9e00:7e5c:d5a3:7dbb:e434:b544)
2021-02-14 04:44:12 +0100 <__minoru__shirae> ok, gonna try anyway
2021-02-14 04:45:06 +0100average(uid473595@gateway/web/irccloud.com/x-eraxnppaxgxfmpke) (Quit: Connection closed for inactivity)
2021-02-14 04:45:17 +0100hololeap(~hololeap@unaffiliated/hololeap)
2021-02-14 04:45:45 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 240 seconds)
2021-02-14 04:45:56 +0100hololeap(~hololeap@unaffiliated/hololeap) (Max SendQ exceeded)
2021-02-14 04:46:25 +0100hololeap(~hololeap@unaffiliated/hololeap)
2021-02-14 04:50:45 +0100ransom(~c4264035@2a09:bac0:98::830:8634)
2021-02-14 04:55:45 +0100idhugo(~idhugo@80-62-117-97-mobile.dk.customer.tdc.net) (Ping timeout: 240 seconds)
2021-02-14 04:59:16 +0100Tario(~Tario@201.192.165.173) (Ping timeout: 240 seconds)
2021-02-14 04:59:25 +0100theDon(~td@muedsl-82-207-238-227.citykom.de) (Ping timeout: 240 seconds)
2021-02-14 05:01:23 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 05:01:35 +0100theDon(~td@94.134.91.232)
2021-02-14 05:02:04 +0100geyaeb(~geyaeb@gateway/tor-sasl/geyaeb) (Remote host closed the connection)
2021-02-14 05:02:30 +0100geyaeb(~geyaeb@gateway/tor-sasl/geyaeb)
2021-02-14 05:02:59 +0100Tario(~Tario@201.192.165.173)
2021-02-14 05:03:37 +0100 <__minoru__shirae> ok, tried it, `try` works without `evaluate`
2021-02-14 05:04:28 +0100Lycurgus(~niemand@cpe-45-46-139-165.buffalo.res.rr.com)
2021-02-14 05:05:48 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 246 seconds)
2021-02-14 05:07:50 +0100borne(~fritjof@2a06:8782:ffbb:1337:9d49:b858:e7dc:a61e) (Ping timeout: 264 seconds)
2021-02-14 05:08:09 +0100Rudd0(~Rudd0@185.189.115.108)
2021-02-14 05:10:35 +0100average(uid473595@gateway/web/irccloud.com/x-xocrlotfjlxduqbi)
2021-02-14 05:12:11 +0100 <c_wraith> I'd double-check that.
2021-02-14 05:12:12 +0100ubert(~Thunderbi@p200300ecdf25d9cde6b318fffe838f33.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2021-02-14 05:12:15 +0100ubert1(~Thunderbi@p200300ecdf25d9afe6b318fffe838f33.dip0.t-ipconnect.de)
2021-02-14 05:12:30 +0100Kilomomo(~anon@186.113.173.107) ()
2021-02-14 05:12:32 +0100polyrain(~polyrain@124.177.21.171)
2021-02-14 05:13:35 +0100polyrain(~polyrain@124.177.21.171) (Client Quit)
2021-02-14 05:14:35 +0100ubert1ubert
2021-02-14 05:16:49 +0100zaquest(~notzaques@5.128.210.178) (Remote host closed the connection)
2021-02-14 05:16:59 +0100pavonia(~user@unaffiliated/siracusa) (Quit: Bye!)
2021-02-14 05:18:41 +0100 <c_wraith> __minoru__shirae: https://paste.tomsmeding.com/mDdF21aR I don't think that's true
2021-02-14 05:18:42 +0100zaquest(~notzaques@5.128.210.178)
2021-02-14 05:23:15 +0100 <__minoru__shirae> c_wraith: I'm trying to understand your example
2021-02-14 05:23:21 +0100 <__minoru__shirae> here is what I tried: https://paste.tomsmeding.com/jS1AForg
2021-02-14 05:23:52 +0100elliott__(~elliott@pool-108-51-101-42.washdc.fios.verizon.net) (Quit: WeeChat 3.0)
2021-02-14 05:24:32 +0100 <c_wraith> so, this is still the difference between execution and evaluation
2021-02-14 05:24:36 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 05:25:04 +0100 <c_wraith> Have you seen the distinction between those described in a Haskell context?
2021-02-14 05:26:40 +0100elliott__(~elliott@pool-108-51-101-42.washdc.fios.verizon.net)
2021-02-14 05:26:58 +0100 <__minoru__shirae> no, what is it?
2021-02-14 05:27:29 +0100 <__minoru__shirae> I'm relieved that I don't have to use `evaluate` each time I use `try`
2021-02-14 05:27:40 +0100 <c_wraith> You don't need to use evaluate for catch, either
2021-02-14 05:27:42 +0100 <__minoru__shirae> I think I misunderstood you
2021-02-14 05:27:53 +0100 <c_wraith> you need to use evaluate for converting evaluation to execution
2021-02-14 05:28:21 +0100 <__minoru__shirae> wait, for `catch` I have to use `evaluate` instead of `return`
2021-02-14 05:28:26 +0100 <c_wraith> Nope
2021-02-14 05:28:36 +0100 <c_wraith> Your code would work with catch, too
2021-02-14 05:28:44 +0100 <c_wraith> without any use of evaluate
2021-02-14 05:29:02 +0100 <__minoru__shirae> there is no `return` in there
2021-02-14 05:29:14 +0100 <c_wraith> so?
2021-02-14 05:29:26 +0100 <__minoru__shirae> the example doesn't apply
2021-02-14 05:29:29 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 265 seconds)
2021-02-14 05:30:13 +0100 <c_wraith> I feel like you're thinking in circles really hard
2021-02-14 05:31:40 +0100 <c_wraith> Evaluation is the majority of what goes on in Haskell. It's what happens when an expression is forced to WHNF
2021-02-14 05:32:01 +0100 <c_wraith> Execution is what the runtime does with IO actions
2021-02-14 05:32:18 +0100 <__minoru__shirae> I think the cause of misunderstanding is that there is a mismatch on the levels or the contexts we are talking about
2021-02-14 05:32:29 +0100borne(~fritjof@200116b8647b450069fc6bd724c60777.dip.versatel-1u1.de)
2021-02-14 05:32:58 +0100 <c_wraith> try and catch work the same way. They deal with exceptions raised in the *execution* of the IO action passed to them.
2021-02-14 05:33:06 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 05:33:31 +0100 <__minoru__shirae> you switched the context and said "You don't need to use evaluate for catch, either" - but I was still in the previous context, and in that context that phrase sounds like you're trying to confuse me
2021-02-14 05:33:33 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Read error: Connection reset by peer)
2021-02-14 05:33:42 +0100 <c_wraith> If that IO action produces a value which contains an unevaluated expression that will raise an exception when it's evaluated... Well, it's not their job to handle it.
2021-02-14 05:33:59 +0100Lycurgus(~niemand@cpe-45-46-139-165.buffalo.res.rr.com) (Quit: Exeunt)
2021-02-14 05:34:09 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 05:34:11 +0100 <c_wraith> evaluate is a function that produces an IO action that evaluates an expression when it's executed.
2021-02-14 05:34:41 +0100 <c_wraith> that's handy when you want to convert evaluation to execution in order to raise an exception as the result of evaluation during execution
2021-02-14 05:35:20 +0100 <c_wraith> But if you only care about exceptions as the result of executing other IO actions, there's no need
2021-02-14 05:38:57 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 264 seconds)
2021-02-14 05:41:21 +0100 <__minoru__shirae> c_wraith: I get that you're trying to explain something to me, but you're doing it in such confusing manner that you just confuse me more, but I heard new keywords, so that's nice.
2021-02-14 05:42:01 +0100 <c_wraith> Nah, I'm not being confusing :)
2021-02-14 05:43:10 +0100polyrain(~polyrain@2001:8003:e4d8:4101:cd73:c730:3a58:912c)
2021-02-14 05:43:45 +0100 <c_wraith> Look, here's your code using catch: https://paste.tomsmeding.com/mwwvvajN
2021-02-14 05:43:47 +0100 <c_wraith> It's fine
2021-02-14 05:44:10 +0100 <c_wraith> the exception is raised during execution, so you're good
2021-02-14 05:45:02 +0100 <swarmcollective> c_wraith, to clarify for myself, evaluation produces one (or more?) thunks, and execution would produce a value (or record)? Am I in the ball-park at least?
2021-02-14 05:45:39 +0100 <c_wraith> The difference is what drives them, not what they produce
2021-02-14 05:46:30 +0100ph88(~ph88@ip5f5af71a.dynamic.kabel-deutschland.de)
2021-02-14 05:46:32 +0100 <c_wraith> execution is driven by being part of main. The runtime takes care of the details there.
2021-02-14 05:46:48 +0100 <c_wraith> evaluation is driven by pattern-matching
2021-02-14 05:46:57 +0100 <swarmcollective> Ohhhhh! :)
2021-02-14 05:47:29 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 05:47:52 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 05:48:44 +0100 <c_wraith> at a sufficiently wide perspective, evaluation is always driven by execution
2021-02-14 05:49:08 +0100 <c_wraith> after all, if you didn't need to do IO with a value, there would never be any demand to evaluate it.
2021-02-14 05:49:15 +0100 <__minoru__shirae> can you rewrite it so that there is `return` in there? https://paste.tomsmeding.com/mwwvvajN
2021-02-14 05:49:20 +0100ransom(~c4264035@2a09:bac0:98::830:8634) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-02-14 05:49:34 +0100 <c_wraith> why would I?
2021-02-14 05:49:40 +0100 <c_wraith> return doesn't do anything
2021-02-14 05:49:44 +0100 <c_wraith> that's the whole point of it
2021-02-14 05:50:03 +0100 <swarmcollective> Evaluation determins what steps to take and execution takes the steps? Evaluation would is unecessary when there is no execution?
2021-02-14 05:50:17 +0100ph88^(~ph88@2a02:8109:9e00:7e5c:d5a3:7dbb:e434:b544) (Ping timeout: 272 seconds)
2021-02-14 05:50:27 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 05:50:53 +0100 <c_wraith> swarmcollective: hmm. No, evaluation is its own thing. Once something kicks it off, it handles things until the value is reduced to WHNF
2021-02-14 05:51:03 +0100 <__minoru__shirae> I think that weird behavior is caused by `return`
2021-02-14 05:51:26 +0100 <swarmcollective> Thank you. Much appreciated, c_wraith
2021-02-14 05:51:33 +0100 <__minoru__shirae> I'm trying to add `return` there, but get type errors
2021-02-14 05:52:07 +0100clog(~nef@bespin.org)
2021-02-14 05:52:49 +0100 <c_wraith> swarmcollective: so like.. "main = let x = 1 + 2 in print x". Execution says "print the value named x". Evaluation says "x is the result of applying (+) to 1 and 2"
2021-02-14 05:53:23 +0100 <swarmcollective> Yes, makes sense!
2021-02-14 05:55:09 +0100 <swarmcollective> and "main = let x = 1 + 2 in print 0": Execution says "print the value 0". Evaluation says "I'm bored." since x is not used and 0 is const. :)
2021-02-14 05:55:20 +0100kam1(~kam1@5.125.240.66) (Read error: Connection reset by peer)
2021-02-14 05:55:25 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 05:55:41 +0100 <c_wraith> pretty much. There's evaluation going on under the hood that I ignored, since print = putStrLn . show
2021-02-14 05:55:47 +0100 <c_wraith> but you've got the right idea
2021-02-14 05:56:44 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 05:57:09 +0100danso(~dan@d67-193-121-2.home3.cgocable.net) (Read error: Connection reset by peer)
2021-02-14 05:57:25 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 05:57:40 +0100danso(~dan@2001:1970:52e7:d000:96b8:6dff:feb3:c009)
2021-02-14 05:57:53 +0100raym(~ray@45.64.220.98)
2021-02-14 05:58:15 +0100danso(~dan@2001:1970:52e7:d000:96b8:6dff:feb3:c009) (Client Quit)
2021-02-14 05:58:42 +0100danso(~dan@2001:1970:52e7:d000:96b8:6dff:feb3:c009)
2021-02-14 05:58:58 +0100motherfsck(~motherfsc@unaffiliated/motherfsck) (Ping timeout: 265 seconds)
2021-02-14 05:59:48 +0100 <c_wraith> __minoru__shirae: https://paste.tomsmeding.com/52rbE2mX
2021-02-14 06:01:36 +0100 <__minoru__shirae> c_wraith: the exception is raised during execution, so you're good
2021-02-14 06:02:06 +0100 <__minoru__shirae> the thing is that it is also catched, but the example says that it shouldn't?
2021-02-14 06:02:14 +0100 <__minoru__shirae> I mean the book says
2021-02-14 06:02:26 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 06:03:30 +0100motherfsck(~motherfsc@unaffiliated/motherfsck)
2021-02-14 06:03:34 +0100 <c_wraith> I'm pretty sure you'll find the book says something else
2021-02-14 06:04:10 +0100desophos(~desophos@2601:249:1680:a570:b92b:7f69:c86c:e272)
2021-02-14 06:05:02 +0100hnOsmium0001(uid453710@gateway/web/irccloud.com/x-nldpnezpjzmypwhq) (Quit: Connection closed for inactivity)
2021-02-14 06:05:03 +0100 <c_wraith> Indeed. the book says that (return (n / d)) doesn't raise ArithException when it's executed and d=0
2021-02-14 06:05:12 +0100 <__minoru__shirae> so how do I reconcile this example from the book https://paste.tomsmeding.com/BWPp6agN with the other one https://paste.tomsmeding.com/mwwvvajN ?
2021-02-14 06:05:29 +0100 <c_wraith> execution vs evaluation
2021-02-14 06:05:54 +0100 <c_wraith> return does nothing when executed
2021-02-14 06:06:01 +0100 <c_wraith> When it does nothing, no exception is raised
2021-02-14 06:06:31 +0100 <c_wraith> readFile, on the other hand, does something when it's executed
2021-02-14 06:06:42 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 246 seconds)
2021-02-14 06:06:44 +0100 <__minoru__shirae> hmm, "n / d" doesn't do any IO - that's one difference
2021-02-14 06:07:08 +0100 <c_wraith> you're so close
2021-02-14 06:07:16 +0100 <__minoru__shirae> yeah, I think I vaguely understand
2021-02-14 06:08:07 +0100 <c_wraith> try/catch handle exceptions raised *by the IO*.
2021-02-14 06:08:25 +0100conal(~conal@64.71.133.70) (Ping timeout: 240 seconds)
2021-02-14 06:08:25 +0100 <c_wraith> return does no IO. So it can't raise an exception
2021-02-14 06:08:50 +0100 <swarmcollective> In my limited understanding: `return` doesn't really care much about the "parameter" to the right, it is just saying "Ok, I'm done working *in* the context of the Monad".
2021-02-14 06:08:50 +0100 <c_wraith> readFile tries to open the file when it's executed. It will raise an exception if it fails to do that for some reason
2021-02-14 06:10:09 +0100Tario(~Tario@201.192.165.173) (Ping timeout: 264 seconds)
2021-02-14 06:10:29 +0100Rudd0(~Rudd0@185.189.115.108) (Ping timeout: 256 seconds)
2021-02-14 06:11:48 +0100Wuzzy(~Wuzzy@p57a2e574.dip0.t-ipconnect.de) (Remote host closed the connection)
2021-02-14 06:12:12 +0100hnOsmium0001(uid453710@gateway/web/irccloud.com/x-ernfxztrwrfkcllh)
2021-02-14 06:13:40 +0100 <__minoru__shirae> so there is a big difference between performing IO and forcing something to WHNF - from the exceptions standpoint and I think it is messy
2021-02-14 06:14:12 +0100 <c_wraith> yes, and yes
2021-02-14 06:14:28 +0100MarcelineVQ(~anja@198.254.199.42) (Ping timeout: 272 seconds)
2021-02-14 06:14:30 +0100 <c_wraith> as was brought up before, exceptions don't really fit into a lazy world
2021-02-14 06:14:44 +0100 <c_wraith> There are... problems.
2021-02-14 06:14:53 +0100 <c_wraith> A lot more than just this
2021-02-14 06:15:36 +0100 <c_wraith> which is why it's recommended that pure code not raise exceptions that you're intended to handle.
2021-02-14 06:15:42 +0100MarcelineVQ(~anja@198.254.199.42)
2021-02-14 06:16:36 +0100 <__minoru__shirae> you meant to say "not intended to handle"?
2021-02-14 06:17:16 +0100raym(~ray@45.64.220.98) (Quit: leaving)
2021-02-14 06:18:04 +0100 <c_wraith> few people are concerned when you have (error "this shouldn't have happened, this is a bug in function X") inside function X.
2021-02-14 06:18:43 +0100 <c_wraith> IE, it's an exception you're not expected to handle. You're expected to fix it so it isn't raised anymore
2021-02-14 06:19:36 +0100 <c_wraith> Some people don't like that, but most people accept it as easier than handling the issue some other way when the underlying cause is a bug
2021-02-14 06:20:18 +0100 <c_wraith> On the other hand, something like the way (!!) uses an exception to indicate the index was negative or too big? That's kind of bad.
2021-02-14 06:20:20 +0100kam1(~kam1@5.125.240.66)
2021-02-14 06:20:37 +0100Noldorin(~noldorin@unaffiliated/noldorin) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
2021-02-14 06:20:49 +0100 <c_wraith> It makes people want to catch the exception. An out of range index isn't a bug in the indexing code.
2021-02-14 06:20:53 +0100kam1(~kam1@5.125.240.66) (Client Quit)
2021-02-14 06:21:23 +0100 <c_wraith> This is the sort of thing that causes problems.
2021-02-14 06:21:29 +0100 <swarmcollective> It would be less bad if (!!) returned Maybe a, but the author didn't want to introduce Maybe in that case?
2021-02-14 06:22:10 +0100 <c_wraith> So no, I said what I meant. It's recommended that pure code should not raise exceptions that the caller might want to handle.
2021-02-14 06:22:13 +0100 <__minoru__shirae> how about the likes of FileNotFoundException? are there people having issue with that?
2021-02-14 06:22:33 +0100 <c_wraith> I *really* hope FileNotFoundException isn't raised by pure functions.
2021-02-14 06:22:51 +0100 <__minoru__shirae> oh, I forgot that we are talking about pure functions
2021-02-14 06:22:52 +0100 <c_wraith> If it is, yes - a lot of people would be concerned.
2021-02-14 06:23:06 +0100 <c_wraith> Raising it from an IO action is perfectly fine, though
2021-02-14 06:23:49 +0100conal(~conal@64.71.133.70)
2021-02-14 06:23:52 +0100 <c_wraith> swarmcollective: yeah, (!!) is one of the family of partial functions in Prelude that are sometimes convenient enough to be worth using, despite the ways they aren't perfect design.
2021-02-14 06:23:55 +0100lordyod(~lordyod@c-67-169-144-132.hsd1.ca.comcast.net)
2021-02-14 06:25:20 +0100 <swarmcollective> The pure code using (!!) should ensure that the index value is within range, making exception handling irrelevant? Which is a great place to be. I've always been able to fix my code when seeing exceptions like `head`, empty list) or (!!) index out of bounds.
2021-02-14 06:26:05 +0100 <c_wraith> I mean, yeah. That's the way it works in practice. But it's a little unpleasant to push those preconditions onto the caller without specifying it in the type
2021-02-14 06:26:32 +0100 <c_wraith> Here's an example of something using error internally as a "this should never happen" case: https://gist.github.com/chowells79/996f2749b088d287937e3eff11055522
2021-02-14 06:26:57 +0100 <c_wraith> (see line 49 - I may have overdocumented it just to make sure I never had to remember how it works from scratch again)
2021-02-14 06:28:34 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 06:28:57 +0100 <swarmcollective> Especially where the behavior *seems* inconsistent. For example `take i xs` and `drop i xs` where i > length xs is acceptable, returning []. I kind of get why. `head` and (!!) are expected to return a sane single value. `take` and `drop` are expected to return a list.
2021-02-14 06:29:33 +0100vicfred(~vicfred@unaffiliated/vicfred) (Quit: Leaving)
2021-02-14 06:30:31 +0100 <c_wraith> I won't argue that head and (!!) don't have problems. I just think of them as convenience hacks when I'm ok with being sloppy :)
2021-02-14 06:30:53 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds)
2021-02-14 06:31:50 +0100polyrain(~polyrain@2001:8003:e4d8:4101:cd73:c730:3a58:912c) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-02-14 06:32:21 +0100 <swarmcollective> Optimizing for the 98+% case. :)
2021-02-14 06:32:24 +0100conal(~conal@64.71.133.70) (Quit: Computer has gone to sleep.)
2021-02-14 06:32:57 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 264 seconds)
2021-02-14 06:34:05 +0100Jd007(~Jd007@162.156.11.151) (Quit: Jd007)
2021-02-14 06:34:44 +0100Tario(~Tario@201.192.165.173)
2021-02-14 06:35:29 +0100Saukk(~Saukk@83-148-239-3.dynamic.lounea.fi)
2021-02-14 06:37:54 +0100 <desophos> hi, i'm having some confusion with generating functions using QuickCheck. i have a function whose logic requires an argument function `f :: [a] -> [b]` such that `length (f x) == length x` for all x. is this possible? is there a better way to go about this? i just need my generated function to preserve the length of the input list. i'm using `suchThat` to generate other constrained values but i can't figure out how to define
2021-02-14 06:37:54 +0100 <desophos> this particular constraint, since i want it to hold true over all inputs (i know this can't be directly computed because there are infinite inputs, but maybe it can be proven? idk)
2021-02-14 06:42:24 +0100 <desophos> hmm, i can specify that the length of both input and output should be 2, if that would make this easier
2021-02-14 06:44:57 +0100borne(~fritjof@200116b8647b450069fc6bd724c60777.dip.versatel-1u1.de) (Ping timeout: 260 seconds)
2021-02-14 06:46:40 +0100borne(~fritjof@200116b864bdfd0063240409dc9964f8.dip.versatel-1u1.de)
2021-02-14 06:47:22 +0100ph88(~ph88@ip5f5af71a.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds)
2021-02-14 06:49:56 +0100petersen(~petersen@redhat/juhp) (Ping timeout: 240 seconds)
2021-02-14 06:50:48 +0100Saukk(~Saukk@83-148-239-3.dynamic.lounea.fi) (Remote host closed the connection)
2021-02-14 06:55:29 +0100banux1(~banux@195.140.213.38) (Remote host closed the connection)
2021-02-14 06:56:24 +0100Neuromancer(~Neuromanc@unaffiliated/neuromancer)
2021-02-14 06:56:35 +0100kam1(~kam1@5.125.240.66)
2021-02-14 06:57:35 +0100kam1(~kam1@5.125.240.66) (Read error: Connection reset by peer)
2021-02-14 07:01:44 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2021-02-14 07:04:25 +0100hololeap(~hololeap@unaffiliated/hololeap) (Ping timeout: 240 seconds)
2021-02-14 07:05:56 +0100borne(~fritjof@200116b864bdfd0063240409dc9964f8.dip.versatel-1u1.de) (Ping timeout: 240 seconds)
2021-02-14 07:07:18 +0100hololeap(~hololeap@unaffiliated/hololeap)
2021-02-14 07:16:22 +0100ixaxaar(~ixaxaar@49.207.197.94)
2021-02-14 07:20:34 +0100raym(~ray@45.64.220.98)
2021-02-14 07:30:32 +0100andreas303(~andreas@gateway/tor-sasl/andreas303) (Remote host closed the connection)
2021-02-14 07:31:08 +0100andreas303(~andreas@gateway/tor-sasl/andreas303)
2021-02-14 07:32:26 +0100 <desophos> for the record, i ended up using a newtype where i generate the test input for the function under test (`xs`) and then generate an f `suchThat (\f -> all ((== 2) . length) (map f (pairs xs))`
2021-02-14 07:32:52 +0100 <desophos> ^ in its Arbitrary instance
2021-02-14 07:33:56 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 07:34:13 +0100 <swarmcollective> desophos, that is interesting. I'd like to learn more about QuickCheck; I've done minimal testing in Haskell thus far.
2021-02-14 07:34:15 +0100 <desophos> idk if tuple newtypes that represent the arguments to a function under test are an anti-pattern, but i've found them very useful
2021-02-14 07:34:45 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 07:35:12 +0100bitmagie(~Thunderbi@200116b80679950091e8a387e741c6b0.dip.versatel-1u1.de)
2021-02-14 07:35:18 +0100 <__minoru__shirae> c_wraith: I revisited our conversation and I think I'm less confused now, thanks for the help
2021-02-14 07:35:42 +0100 <swarmcollective> desophus, do you have a one line example of the "tuple newtype" ?
2021-02-14 07:35:57 +0100 <desophos> newtype ChunkArgs a = ChunkArgs (Int, [a])
2021-02-14 07:36:07 +0100 <c_wraith> Sorry for jumping around as much as I did. you could have been better served by a more compact explanation
2021-02-14 07:37:04 +0100 <desophos> and then i define an Arbitrary instance for it with custom constraints for the function
2021-02-14 07:37:41 +0100bitmagie(~Thunderbi@200116b80679950091e8a387e741c6b0.dip.versatel-1u1.de) (Client Quit)
2021-02-14 07:38:12 +0100 <swarmcollective> When I try to use newtype with a tuple, I get: Illegal binding of built-in syntax: (,)
2021-02-14 07:38:43 +0100 <desophos> this is my full implementation: https://paste.tomsmeding.com/8AZappu1
2021-02-14 07:41:07 +0100stef204(~stef204@unaffiliated/stef-204/x-384198) (Ping timeout: 272 seconds)
2021-02-14 07:42:09 +0100 <c_wraith> desophos: what are you trying to do with n there? Unless I'm misreading something, the only value that can satisfy those constraints is len
2021-02-14 07:42:24 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 07:43:22 +0100ransom(~c4264035@2a09:bac0:98::830:8634)
2021-02-14 07:43:23 +0100 <desophos> i'm trying to get a value `0 < y <= len` that evenly divides len
2021-02-14 07:43:58 +0100 <c_wraith> oh.
2021-02-14 07:44:15 +0100Tario(~Tario@201.192.165.173) (Read error: Connection reset by peer)
2021-02-14 07:44:32 +0100Tario(~Tario@201.192.165.173)
2021-02-14 07:44:36 +0100 <c_wraith> that'd be way more efficient to do by factoring and choosing one of the factors.
2021-02-14 07:44:45 +0100 <__minoru__shirae> c_wraith: good to know about execution and evaluation, as I said, I can run code in terminal, but I can't have a conversation with a compilator.
2021-02-14 07:44:48 +0100them_(~them_@217.146.82.202)
2021-02-14 07:44:58 +0100 <__minoru__shirae> *compiler
2021-02-14 07:47:23 +0100urodna(~urodna@unaffiliated/urodna) (Quit: urodna)
2021-02-14 07:49:20 +0100 <desophos> hmm, despite learning haskell, i'm not enough of a mathematician to write a factoring algorithm off the top of my head
2021-02-14 07:49:34 +0100 <swarmcollective> It doesn't appear as though one can use `fst` and `snd` to access the properties of a tuple newtype. HaskellWiki does not address this. :/
2021-02-14 07:49:39 +0100 <swarmcollective> Any pointers?
2021-02-14 07:50:26 +0100 <c_wraith> newtypes are totally separate types.
2021-02-14 07:50:35 +0100 <c_wraith> fst and snd only work with (a, b)
2021-02-14 07:50:52 +0100 <c_wraith> (The whole point of a newtype is that it's a *new* type)
2021-02-14 07:51:05 +0100Tario(~Tario@201.192.165.173) (Ping timeout: 240 seconds)
2021-02-14 07:51:06 +0100 <desophos> i use pattern matching to extract the values
2021-02-14 07:51:15 +0100__minoru__shirae(~shiraeesh@109.166.57.144) (Ping timeout: 272 seconds)
2021-02-14 07:51:48 +0100 <swarmcollective> Yeah, pattern matching makes sense now that you say it. Thank you.
2021-02-14 07:51:58 +0100 <desophos> `f args = ... where ChunkArgs (n, xs) = args`
2021-02-14 07:54:09 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 246 seconds)
2021-02-14 07:58:36 +0100 <swarmcollective> Is there overhead with using `newtype Thing = MkThing (String, String)` compared to `type Thing = (String, String)`? I can see the benefit in the source code being a bit more explicit in providing the MkThing in pattern matching; perhaps there are other benefits as well?
2021-02-14 07:59:40 +0100 <c_wraith> newtypes have no direct runtime overhead - there's no runtime representation of their constructor
2021-02-14 08:00:07 +0100 <c_wraith> But they can have an impact if you map their constructor over something. That will require rebuilding the data structure, even though no values are changing
2021-02-14 08:00:27 +0100 <swarmcollective> Perfect. So, newtype provides a more strict type checking by nature without adding overhead, it sounds.
2021-02-14 08:01:01 +0100__minoru__shirae(~shiraeesh@109.166.57.144)
2021-02-14 08:01:34 +0100 <ski> `f args = ... where ChunkArgs (n, xs) = args' is equivalent to `f (ChunkArgs (n,xs)) = ...'. or `f args@(ChunkArgs (n,xs)) = ...', if you actually wanted to name the whole thing as well
2021-02-14 08:02:25 +0100bitmagie(~Thunderbi@200116b80679950091e8a387e741c6b0.dip.versatel-1u1.de)
2021-02-14 08:02:36 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-02-14 08:02:41 +0100 <swarmcollective> I was using `type Thing = (String, [String])` in (_, otherChannel) = partition ((==) channelName . fst) $ watching dashboardState
2021-02-14 08:02:50 +0100 <swarmcollective> Where watching :: [Thing]
2021-02-14 08:03:23 +0100 <ski> `(==) channelName' could also be spelled `(channelName ==)'
2021-02-14 08:04:00 +0100bitmagie(~Thunderbi@200116b80679950091e8a387e741c6b0.dip.versatel-1u1.de) (Client Quit)
2021-02-14 08:04:06 +0100 <swarmcollective> I won't be able to use function composition `((==) channelName . fst)` once switching to `newtype Thing = MkThing (String, [String])` unless I'm missing something (which is likely)
2021-02-14 08:04:36 +0100 <ski> you could define `unThing :: Thing -> (String,[String])'
2021-02-14 08:05:25 +0100 <ski> also, if you're only picking one of the partitions, you could use `filter' instead
2021-02-14 08:05:36 +0100 <swarmcollective> then ((channelName ==) . fst . unThing) $ watching dashboardState
2021-02-14 08:06:26 +0100 <swarmcollective> Oh! That's true! Pebkac + copy / paste issue there. ;)
2021-02-14 08:06:30 +0100 <ski> > partition even [0 .. 9]
2021-02-14 08:06:31 +0100 <lambdabot> ([0,2,4,6,8],[1,3,5,7,9])
2021-02-14 08:06:54 +0100 <ski> otherChannel = filter ((channelName /=) . fst . unThing) (watching dashboardState)
2021-02-14 08:07:47 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 08:08:10 +0100 <desophos> thanks ski! i forgot about that, that makes it much more concise
2021-02-14 08:09:48 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 08:09:48 +0100 <swarmcollective> ski <- Thanks + 1
2021-02-14 08:09:49 +0100heatsink(~heatsink@2600:1700:bef1:5e10:606c:d5c5:bedc:297d) (Remote host closed the connection)
2021-02-14 08:11:18 +0100forgottenone(~forgotten@176.42.25.228)
2021-02-14 08:12:13 +0100jamestmartin(james@jtmar.me)
2021-02-14 08:13:27 +0100ezrakilty(~ezrakilty@75-172-120-208.tukw.qwest.net)
2021-02-14 08:13:35 +0100 <swarmcollective> As some of the types I'm working with have more than two and `fst` and `snd` are less concise, I opted for: "otherChannel = filter ((channelName /=) . nameFromChannel) $ watching dashboardState"
2021-02-14 08:14:00 +0100 <swarmcollective> I believe the (something)From(SomeNewType) will work consistently in this module.
2021-02-14 08:14:32 +0100 <ski> looks reasonable
2021-02-14 08:14:47 +0100 <ski> (apart from the `$', that is)
2021-02-14 08:15:43 +0100frozenErebus(~frozenEre@94.128.81.133)
2021-02-14 08:16:09 +0100forgottenone(~forgotten@176.42.25.228) (Remote host closed the connection)
2021-02-14 08:16:15 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 08:17:01 +0100Lowl3v3l(~Lowl3v3l@dslb-002-203-233-121.002.203.pools.vodafone-ip.de)
2021-02-14 08:17:36 +0100ezrakilty(~ezrakilty@75-172-120-208.tukw.qwest.net) (Ping timeout: 240 seconds)
2021-02-14 08:18:11 +0100forgottenone(~forgotten@176.42.25.228)
2021-02-14 08:20:26 +0100hexfive(~hexfive@50.35.83.177) (Quit: i must go. my people need me.)
2021-02-14 08:21:08 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 272 seconds)
2021-02-14 08:27:21 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 08:29:47 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 08:30:24 +0100ransom_(~c4264035@c-73-243-2-10.hsd1.co.comcast.net)
2021-02-14 08:30:44 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 08:30:52 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 08:31:14 +0100Lowl3v3l(~Lowl3v3l@dslb-002-203-233-121.002.203.pools.vodafone-ip.de) (Remote host closed the connection)
2021-02-14 08:31:56 +0100ransom(~c4264035@2a09:bac0:98::830:8634) (Ping timeout: 240 seconds)
2021-02-14 08:32:40 +0100coot(~coot@37.30.55.141.nat.umts.dynamic.t-mobile.pl) (Quit: coot)
2021-02-14 08:33:25 +0100berberman_(~berberman@unaffiliated/berberman) (Quit: ZNC 1.8.2 - https://znc.in)
2021-02-14 08:33:51 +0100berberman(~berberman@unaffiliated/berberman)
2021-02-14 08:33:57 +0100 <ibloom> Has anyone written a haskell library for Metal shaders?
2021-02-14 08:35:08 +0100 <ibloom> Googling this I'm getting machine shops and stuff :)
2021-02-14 08:41:40 +0100_noblegas(uid91066@gateway/web/irccloud.com/x-twmjqwcrorjsfymz)
2021-02-14 08:48:58 +0100desophos(~desophos@2601:249:1680:a570:b92b:7f69:c86c:e272) (Quit: Leaving)
2021-02-14 08:49:45 +0100cole-h(~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) (Ping timeout: 264 seconds)
2021-02-14 08:55:06 +0100average(uid473595@gateway/web/irccloud.com/x-xocrlotfjlxduqbi) (Quit: Connection closed for inactivity)
2021-02-14 08:58:24 +0100average(uid473595@gateway/web/irccloud.com/x-lumfcglyvjlqciwx)
2021-02-14 09:01:05 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2021-02-14 09:03:36 +0100frozenErebus(~frozenEre@94.128.81.133) (Ping timeout: 240 seconds)
2021-02-14 09:03:48 +0100 <koz_> ibloom: I'm not aware of one.
2021-02-14 09:04:17 +0100 <ibloom> Hmmm... they finally totally dump OpenCL unfortunately.
2021-02-14 09:04:27 +0100 <ibloom> *dumped
2021-02-14 09:05:32 +0100 <ibloom> it's so sad that we have 3 baseline GPU languages for different platforms.
2021-02-14 09:05:46 +0100 <ibloom> it's like back to the 80's
2021-02-14 09:07:36 +0100ransom_(~c4264035@c-73-243-2-10.hsd1.co.comcast.net) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-02-14 09:09:55 +0100stiell(~stian@fsf/member/stiell)
2021-02-14 09:12:23 +0100Varis(~Tadas@unaffiliated/varis)
2021-02-14 09:19:01 +0100wz1000(~wz1000@static.11.113.47.78.clients.your-server.de)
2021-02-14 09:23:19 +0100aggin(~ecm@103.88.87.1)
2021-02-14 09:25:20 +0100tribble2(~tribble2@unaffiliated/tribble2) (Read error: Connection reset by peer)
2021-02-14 09:34:07 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 09:34:40 +0100__minoru__shirae(~shiraeesh@109.166.57.144) (Remote host closed the connection)
2021-02-14 09:35:25 +0100__minoru__shirae(~shiraeesh@109.166.57.144)
2021-02-14 09:36:51 +0100forgottenone(~forgotten@176.42.25.228) (Read error: Connection reset by peer)
2021-02-14 09:36:56 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 09:37:43 +0100forgottenone(~forgotten@176.42.25.228)
2021-02-14 09:44:05 +0100forgottenone(~forgotten@176.42.25.228) (Ping timeout: 272 seconds)
2021-02-14 09:49:10 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-02-14 09:49:24 +0100hekkaidekapus{(~tchouri@gateway/tor-sasl/hekkaidekapus)
2021-02-14 09:51:54 +0100hekkaidekapus_(~tchouri@gateway/tor-sasl/hekkaidekapus) (Ping timeout: 268 seconds)
2021-02-14 09:54:19 +0100__minoru__shirae(~shiraeesh@109.166.57.144) (Ping timeout: 256 seconds)
2021-02-14 09:54:33 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 264 seconds)
2021-02-14 09:57:39 +0100gioyik(~gioyik@gateway/tor-sasl/gioyik) (Quit: WeeChat 3.0)
2021-02-14 10:00:03 +0100_ht(~quassel@82-169-194-8.biz.kpn.net)
2021-02-14 10:00:03 +0100tomferon[m](tomferonmo@gateway/shell/matrix.org/x-vhvkjejfaetfyvlx) (Quit: Idle for 30+ days)
2021-02-14 10:00:20 +0100tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz)
2021-02-14 10:06:17 +0100forgottenone(~forgotten@176.42.25.228)
2021-02-14 10:09:23 +0100kmein(~weechat@static.173.83.99.88.clients.your-server.de) (Quit: ciao kakao)
2021-02-14 10:11:21 +0100kmein(~weechat@static.173.83.99.88.clients.your-server.de)
2021-02-14 10:12:15 +0100_ht(~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection)
2021-02-14 10:14:43 +0100_ht(~quassel@82-169-194-8.biz.kpn.net)
2021-02-14 10:17:54 +0100coot(~coot@37.30.55.141.nat.umts.dynamic.t-mobile.pl)
2021-02-14 10:20:25 +0100m0rphism1(~m0rphism@HSI-KBW-085-216-104-059.hsi.kabelbw.de)
2021-02-14 10:25:12 +0100gehmehgeh(~ircuser1@gateway/tor-sasl/gehmehgeh)
2021-02-14 10:28:17 +0100hekkaidekapus{(~tchouri@gateway/tor-sasl/hekkaidekapus) (Ping timeout: 268 seconds)
2021-02-14 10:28:47 +0100hekkaidekapus{(~tchouri@gateway/tor-sasl/hekkaidekapus)
2021-02-14 10:29:42 +0100forgottenone(~forgotten@176.42.25.228) (Ping timeout: 272 seconds)
2021-02-14 10:32:01 +0100 <[exa]> ibloom: why not vulkan & spir-v?
2021-02-14 10:34:52 +0100nicecoats(~nicecoats@h8.138.213.151.dynamic.ip.windstream.net)
2021-02-14 10:35:02 +0100hnOsmium0001(uid453710@gateway/web/irccloud.com/x-ernfxztrwrfkcllh) (Quit: Connection closed for inactivity)
2021-02-14 10:38:21 +0100Lowl3v3l(~Lowl3v3l@dslb-002-203-233-121.002.203.pools.vodafone-ip.de)
2021-02-14 10:39:28 +0100Narinas(~Narinas@189.223.179.61.dsl.dyn.telnor.net)
2021-02-14 10:39:38 +0100Gurkenglas(~Gurkengla@dslb-092-075-179-204.092.075.pools.vodafone-ip.de)
2021-02-14 10:43:54 +0100_ht(~quassel@82-169-194-8.biz.kpn.net) (Read error: Connection reset by peer)
2021-02-14 10:45:00 +0100aggin(~ecm@103.88.87.1) (Quit: WeeChat 3.0.1)
2021-02-14 10:47:48 +0100_ht(~quassel@82.169.194.8)
2021-02-14 10:51:50 +0100idhugo(~idhugo@80-62-117-97-mobile.dk.customer.tdc.net)
2021-02-14 10:57:57 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 10:58:54 +0100fendor(~fendor@77.119.131.57.wireless.dyn.drei.com)
2021-02-14 11:00:49 +0100nicecoats(~nicecoats@h8.138.213.151.dynamic.ip.windstream.net) (Quit: Textual IRC Client: www.textualapp.com)
2021-02-14 11:04:10 +0100Tuplanolla(~Tuplanoll@91-159-68-239.elisa-laajakaista.fi)
2021-02-14 11:04:12 +0100frozenErebus(~frozenEre@94.128.81.133)
2021-02-14 11:04:23 +0100Rudd0(~Rudd0@185.189.115.103)
2021-02-14 11:07:29 +0100iqubic(~user@2601:602:9500:4870:4339:c0b6:b79f:872d)
2021-02-14 11:09:44 +0100ezrakilty(~ezrakilty@75-172-120-208.tukw.qwest.net)
2021-02-14 11:12:16 +0100Sonderblade(~helloman@94.191.137.213.mobile.tre.se)
2021-02-14 11:12:24 +0100Sonderblade(~helloman@94.191.137.213.mobile.tre.se) (Client Quit)
2021-02-14 11:12:35 +0100heatsink(~heatsink@2600:1700:bef1:5e10:f066:c875:bf57:1bea)
2021-02-14 11:14:29 +0100knupfer(~Thunderbi@200116b82ce187003420f2975f416810.dip.versatel-1u1.de)
2021-02-14 11:15:17 +0100aramend(~aramend@5.186.119.223.cgn.fibianet.dk)
2021-02-14 11:15:31 +0100aramend(~aramend@5.186.119.223.cgn.fibianet.dk) (Client Quit)
2021-02-14 11:16:45 +0100hololeap(~hololeap@unaffiliated/hololeap) (Ping timeout: 264 seconds)
2021-02-14 11:17:26 +0100heatsink(~heatsink@2600:1700:bef1:5e10:f066:c875:bf57:1bea) (Ping timeout: 264 seconds)
2021-02-14 11:19:05 +0100borne(~fritjof@200116b864bdfd0069fc6bd724c60777.dip.versatel-1u1.de)
2021-02-14 11:20:49 +0100hololeap(~hololeap@unaffiliated/hololeap)
2021-02-14 11:21:07 +0100hololeap(~hololeap@unaffiliated/hololeap) (Max SendQ exceeded)
2021-02-14 11:21:38 +0100hololeap(~hololeap@unaffiliated/hololeap)
2021-02-14 11:22:08 +0100_ht(~quassel@82.169.194.8) (Remote host closed the connection)
2021-02-14 11:23:12 +0100knupfer(~Thunderbi@200116b82ce187003420f2975f416810.dip.versatel-1u1.de) (Ping timeout: 260 seconds)
2021-02-14 11:23:47 +0100borne(~fritjof@200116b864bdfd0069fc6bd724c60777.dip.versatel-1u1.de) (Ping timeout: 260 seconds)
2021-02-14 11:24:30 +0100_ht(~quassel@82-169-194-8.biz.kpn.net)
2021-02-14 11:25:18 +0100borne(~fritjof@200116b864bdfd0069fc6bd724c60777.dip.versatel-1u1.de)
2021-02-14 11:28:25 +0100frozenErebus(~frozenEre@94.128.81.133) (Ping timeout: 240 seconds)
2021-02-14 11:30:15 +0100borne(~fritjof@200116b864bdfd0069fc6bd724c60777.dip.versatel-1u1.de) (Quit: WeeChat 3.0)
2021-02-14 11:32:08 +0100frozenErebus(~frozenEre@94.128.81.133)
2021-02-14 11:32:21 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds)
2021-02-14 11:35:24 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 11:37:21 +0100leah2(~leah@vuxu.org) (Ping timeout: 272 seconds)
2021-02-14 11:37:27 +0100hololeap(~hololeap@unaffiliated/hololeap) (Ping timeout: 256 seconds)
2021-02-14 11:38:34 +0100hololeap(~hololeap@unaffiliated/hololeap)
2021-02-14 11:39:35 +0100son0p(~son0p@181.58.39.182)
2021-02-14 11:39:41 +0100denisse(~spaceCat@gateway/tor-sasl/alephzer0) (Remote host closed the connection)
2021-02-14 11:39:57 +0100denisse(~spaceCat@gateway/tor-sasl/alephzer0)
2021-02-14 11:41:25 +0100kam1(~kam1@83.123.32.229)
2021-02-14 11:41:57 +0100st8less(~st8less@inet-167-224-197-181.isp.ozarksgo.net) (Quit: WeeChat 2.9)
2021-02-14 11:42:31 +0100kam1(~kam1@83.123.32.229) (Read error: Connection reset by peer)
2021-02-14 11:42:45 +0100 <merijn> ibloom: It's a bit unclear if you're talking, like, a DSL for creating Metal shaders or just a library to run existing ones (in whatever language Metal uses)?
2021-02-14 11:45:47 +0100Lord_of_Life(~Lord@unaffiliated/lord-of-life/x-0885362) (Read error: Connection reset by peer)
2021-02-14 11:46:05 +0100frozenErebus(~frozenEre@94.128.81.133) (Ping timeout: 240 seconds)
2021-02-14 11:49:10 +0100leah2(~leah@vuxu.org)
2021-02-14 11:49:23 +0100Lord_of_Life(~Lord@unaffiliated/lord-of-life/x-0885362)
2021-02-14 11:49:58 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-02-14 11:51:26 +0100knu10(58823d80@gateway/web/cgi-irc/kiwiirc.com/ip.88.130.61.128)
2021-02-14 11:51:27 +0100Lord_of_Life(~Lord@unaffiliated/lord-of-life/x-0885362) (Read error: Connection reset by peer)
2021-02-14 11:52:43 +0100frozenErebus(~frozenEre@94.128.81.133)
2021-02-14 11:52:54 +0100Lord_of_Life(~Lord@unaffiliated/lord-of-life/x-0885362)
2021-02-14 11:54:43 +0100 <knu10> Is it possible to get a representation of a promoted constructor? Like Generics Rep, but for kinds other than *
2021-02-14 11:55:11 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 265 seconds)
2021-02-14 11:56:00 +0100 <merijn> knu10: Wow...that's a cursed question
2021-02-14 11:56:18 +0100 <knu10> I'd like to write a type family which converts a Symbol to an appropriate promoted constructor but don't want to write a line for every promoted constructor and I want to avoid TH
2021-02-14 11:57:09 +0100 <merijn> I think you want Idris :p
2021-02-14 11:57:20 +0100 <knu10> So I thought I could convert the Symbol to an Representation and then turn it back into the promoted constructor
2021-02-14 11:57:44 +0100 <knu10> Well, it's still all on the type level, no terms involved
2021-02-14 11:58:09 +0100fendor_(~fendor@77.119.131.224.wireless.dyn.drei.com)
2021-02-14 11:58:31 +0100 <merijn> Sure, but with Idris you can at just directly use the term level stuff at the type level
2021-02-14 11:58:55 +0100 <knu10> I'm lazy, don't force me
2021-02-14 11:58:59 +0100__monty__(~toonn@unaffiliated/toonn)
2021-02-14 11:59:05 +0100 <knu10> :)
2021-02-14 11:59:12 +0100 <merijn> knu10: Your question is, essentially, "has anyone duplicated all this term level generics stuff at the type level?" to which I'm pretty sure the answer is: No
2021-02-14 11:59:20 +0100 <merijn> Alternative answer: Ew...god, no
2021-02-14 12:00:05 +0100 <knu10> Hm, so perhaps I'll have to use TH.
2021-02-14 12:00:23 +0100gehmehgeh(~ircuser1@gateway/tor-sasl/gehmehgeh) (Remote host closed the connection)
2021-02-14 12:00:41 +0100fendor(~fendor@77.119.131.57.wireless.dyn.drei.com) (Ping timeout: 256 seconds)
2021-02-14 12:01:19 +0100 <merijn> I would probably recommend instead consulting your diety/spiritual advisor of choice and reevaluating your life's choices leading to this question, but to each their own ;)
2021-02-14 12:01:33 +0100 <knu10> I had assumed, that it's quite a common case to want to convert a Symbol to a promoted constructor.
2021-02-14 12:01:49 +0100gehmehgeh(~ircuser1@gateway/tor-sasl/gehmehgeh)
2021-02-14 12:01:59 +0100 <knu10> It's the kind of question which I ponder on sundays and on vacation.
2021-02-14 12:02:37 +0100 <merijn> I mean, I think it *can* be done, but it'd involve a hell of a lot of TH *and* hasochism
2021-02-14 12:02:47 +0100jb55(~jb55@gateway/tor-sasl/jb55) (Remote host closed the connection)
2021-02-14 12:03:12 +0100jb55(~jb55@gateway/tor-sasl/jb55)
2021-02-14 12:03:45 +0100coot(~coot@37.30.55.141.nat.umts.dynamic.t-mobile.pl) (Quit: coot)
2021-02-14 12:03:50 +0100 <knu10> Well, a bit of a challenge is good for mental health
2021-02-14 12:06:41 +0100 <knu10> Hm, or I make the promoted constructors "sloppy kinded", i.e. make only one constructor which takes a symbol and checks against a list of valid symbols to typerror if not found.
2021-02-14 12:07:04 +0100 <knu10> I.e. stringly typed on the type level.
2021-02-14 12:07:47 +0100jamm_(~jamm@unaffiliated/jamm)
2021-02-14 12:08:54 +0100Guest64938(~textual@2603-7000-3040-0000-0036-b491-5ac9-398e.res6.spectrum.com) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-02-14 12:09:11 +0100jamm__(~jamm@unaffiliated/jamm)
2021-02-14 12:10:07 +0100 <Uniaika> https://lukelau.me/haskell/posts/making-the-most-of-cabal/
2021-02-14 12:10:13 +0100 <Uniaika> jlombera pointed out that you can in fact, pretty much replicate Stackage in Cabal by freezing with a specific Stackage LTS, by downloading a config file provided:
2021-02-14 12:10:16 +0100 <Uniaika> that's nice!!
2021-02-14 12:10:18 +0100 <Uniaika> curl https://www.stackage.org/lts-15.15/cabal.config > cabal.project.freeze
2021-02-14 12:12:12 +0100 <maerwald> Uniaika: that's only half the way
2021-02-14 12:12:38 +0100jamm_(~jamm@unaffiliated/jamm) (Ping timeout: 264 seconds)
2021-02-14 12:13:18 +0100heatsink(~heatsink@2600:1700:bef1:5e10:f066:c875:bf57:1bea)
2021-02-14 12:13:19 +0100 <maerwald> but if you don't have a stack.yaml, then it's probably fine
2021-02-14 12:13:50 +0100 <Uniaika> maerwald: I'd also love to have a way to distribute LTSs for cabal
2021-02-14 12:14:11 +0100Tops2(~Tobias@dyndsl-095-033-023-209.ewe-ip-backbone.de)
2021-02-14 12:14:31 +0100 <Uniaika> like "import https://packages.company.tld/haskell/lts-company.cabal.project" in the cabal.project
2021-02-14 12:15:05 +0100kenran(~kenran@i59F67B96.versanet.de)
2021-02-14 12:15:15 +0100 <merijn> Uniaika: I mean, isn't that better address by having a company hackage server only having those packages imported and not using Hackage at all?
2021-02-14 12:15:30 +0100Franciman(~francesco@host-82-49-79-189.retail.telecomitalia.it)
2021-02-14 12:15:34 +0100 <maerwald> Uniaika: https://github.com/haskell/cabal/issues/6528
2021-02-14 12:16:06 +0100Tops21(~Tobias@dyndsl-095-033-023-209.ewe-ip-backbone.de)
2021-02-14 12:16:25 +0100 <merijn> maerwald: Wouldn't hold my breath >.>
2021-02-14 12:16:43 +0100kafl(~kafl@unaffiliated/kafl)
2021-02-14 12:16:51 +0100 <maerwald> merijn: why? I don't think it's hard to implement
2021-02-14 12:17:01 +0100 <Uniaika> merijn: having worked in a company that used stack LTSs rather than a custom hackage server, it's better to have to edit a yaml file to point to the proper commits/tags in the git rather than making releases for every project
2021-02-14 12:17:08 +0100 <merijn> maerwald: Who would implement it?
2021-02-14 12:17:13 +0100 <maerwald> merijn: me
2021-02-14 12:17:28 +0100 <maerwald> but I'm not gonna if there's no response from the maintainers
2021-02-14 12:17:37 +0100 <merijn> maerwald: There won't be
2021-02-14 12:17:44 +0100 <maerwald> Then I'm not gonna
2021-02-14 12:17:49 +0100Tops22(~Tobias@dyndsl-095-033-023-209.ewe-ip-backbone.de)
2021-02-14 12:18:02 +0100heatsink(~heatsink@2600:1700:bef1:5e10:f066:c875:bf57:1bea) (Ping timeout: 264 seconds)
2021-02-14 12:18:07 +0100 <merijn> maerwald: phadej stopped working on cabal-install because he (justifiably) felt abandonned
2021-02-14 12:18:09 +0100kritzefitz(~kritzefit@212.86.56.80) (Remote host closed the connection)
2021-02-14 12:19:06 +0100 <maerwald> Uniaika: "enterprise environments" :p
2021-02-14 12:19:13 +0100 <merijn> maerwald: Since hvr has been absent/busy for well over a year that means there's no regular maintainer and none of the occasional contributors feel empowered/authorised to take control
2021-02-14 12:19:26 +0100Tops2(~Tobias@dyndsl-095-033-023-209.ewe-ip-backbone.de) (Ping timeout: 256 seconds)
2021-02-14 12:19:28 +0100 <maerwald> that's a CLC matter imo
2021-02-14 12:20:14 +0100 <merijn> maerwald: The issues has been handed to the Haskell Foundation to deal with, but considering a significant portion of the board is stack fanboys...
2021-02-14 12:20:45 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-02-14 12:20:52 +0100 <maerwald> means we should join the foundation
2021-02-14 12:21:08 +0100Tops21(~Tobias@dyndsl-095-033-023-209.ewe-ip-backbone.de) (Ping timeout: 256 seconds)
2021-02-14 12:21:23 +0100 <merijn> maerwald: As for your proposal, I see one problem
2021-02-14 12:21:44 +0100 <merijn> maerwald: cabal.project.freeze is part of critical path
2021-02-14 12:21:56 +0100 <merijn> maerwald: I don't think network requests are acceptable
2021-02-14 12:22:31 +0100 <maerwald> Why?
2021-02-14 12:22:37 +0100 <merijn> maerwald: hvr spend *a lot* of work on the critical path/recompilation detection to keep it under 100ms so "cabal run", etc. can be suitably used interactively
2021-02-14 12:22:49 +0100 <maerwald> it's already slow af
2021-02-14 12:22:52 +0100 <maerwald> but yeah
2021-02-14 12:22:59 +0100jedws(~jedws@101.184.202.248) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-02-14 12:23:00 +0100 <merijn> maerwald: having to do a network request for plan.json is bad
2021-02-14 12:23:02 +0100 <merijn> maerwald: How so?
2021-02-14 12:23:08 +0100 <maerwald> you can reduce it with caching and HEAD request
2021-02-14 12:23:19 +0100 <merijn> I use no-op and interactive use of cabal daily
2021-02-14 12:23:56 +0100frozenErebus(~frozenEre@94.128.81.133) (Ping timeout: 240 seconds)
2021-02-14 12:24:17 +0100 <maerwald> given that it's an optional feature I'm pretty sure ppl using it will be aware that it causes a network request
2021-02-14 12:24:22 +0100 <merijn> maerwald: I have a pretty big project and a few hundred dependencies and no-op build/run overhead is under 100ms for me, so I'm curious what makes you say it's slow?
2021-02-14 12:24:36 +0100 <maerwald> if you don't use the feature, you're not affected
2021-02-14 12:24:42 +0100 <maerwald> so I don't see a conflict of interest
2021-02-14 12:25:21 +0100 <merijn> maerwald: Well, if you say this is so desirable, then your basically sacrificing the interactive use for everyone who is interested in using this
2021-02-14 12:25:24 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 246 seconds)
2021-02-14 12:26:34 +0100 <maerwald> stack already does this, it works well, I don't know of any issues with speed there
2021-02-14 12:27:18 +0100saitamaplus(uid272474@gateway/web/irccloud.com/x-zjttagjjvsylgivd)
2021-02-14 12:28:58 +0100 <merijn> Pretty sure stack only fetches each snapshot once and caches it, because they're immutable and only a version bump affects them
2021-02-14 12:29:20 +0100 <merijn> So if you are willing to require the remote snapshot/freeze never changes, then it's easy to do without affecting latency, sure
2021-02-14 12:29:21 +0100 <maerwald> a resolver can be a url
2021-02-14 12:30:00 +0100 <merijn> I dunno the details of how stack approaches this
2021-02-14 12:30:14 +0100 <maerwald> yeah, I don't see any major issue here
2021-02-14 12:30:29 +0100 <maerwald> there are some tradeoffs to make, but nothing that affects users not interested in it
2021-02-14 12:30:38 +0100 <merijn> I'd want to see how it affects the latency first, tbh
2021-02-14 12:30:47 +0100knu10(58823d80@gateway/web/cgi-irc/kiwiirc.com/ip.88.130.61.128) (Quit: Connection closed)
2021-02-14 12:31:12 +0100 <maerwald> refetch policy could simply be provided by command line
2021-02-14 12:31:28 +0100 <Uniaika> < maerwald> Uniaika: "enterprise environments" :p // gotta hit the proper keywords ;)
2021-02-14 12:31:44 +0100 <Uniaika> < maerwald> that's a CLC matter imo // see the libraries@ thread about it
2021-02-14 12:31:52 +0100 <maerwald> yes, I commented there
2021-02-14 12:33:08 +0100 <Uniaika> ah sorry
2021-02-14 12:34:16 +0100 <maerwald> Go ecosystem is more towards authorship (with it's hilarious github import feature)... haskell could have something similar, but hackage is not that
2021-02-14 12:34:52 +0100 <merijn> Well, you know, if someone is willing to pay me to work on cabal-install I'll happily declare myself cabal czar after my thesis is out the door :p
2021-02-14 12:35:13 +0100 <Franciman> what is enterprise environments?
2021-02-14 12:35:27 +0100 <maerwald> merijn: once your thesis is out the door, you'll quit programming due to depression after looking at your TODO-after-thesis.md
2021-02-14 12:35:27 +0100 <dcoutts> merijn: that's not a bad idea :-)
2021-02-14 12:35:36 +0100xcmw(~textual@dyn-72-33-2-47.uwnet.wisc.edu) (Quit: Textual IRC Client: www.textualapp.com)
2021-02-14 12:36:22 +0100pera(~pera@unaffiliated/pera)
2021-02-14 12:37:04 +0100 <merijn> dcoutts: I know, but my work doesn't pay me to work on Haskell (at least, not intentionally :p) and doing that in my spare time/weekend sounds like a one way trip to burnout-ville
2021-02-14 12:37:35 +0100 <dcoutts> merijn: you said "if someone is willing to pay". That's an important part of it.
2021-02-14 12:37:39 +0100 <Franciman> maerwald, my politics for adding custom behaviours to cabal is to try to write a wrapper, when possible
2021-02-14 12:37:43 +0100 <Uniaika> merijn: open a patreon
2021-02-14 12:37:47 +0100 <Uniaika> or a ko-fi
2021-02-14 12:37:48 +0100 <Franciman> if everybody likes what you do, probably it gets merged
2021-02-14 12:37:52 +0100 <Uniaika> I'll send some bucks
2021-02-14 12:37:56 +0100 <merijn> dcoutts: tbh, I've been worried about Oleg's situation for a few months
2021-02-14 12:38:04 +0100 <Franciman> i think that a wrapper works fine for that issue
2021-02-14 12:38:39 +0100coot(~coot@37.30.55.141.nat.umts.dynamic.t-mobile.pl)
2021-02-14 12:38:44 +0100 <merijn> Uniaika: Building something like that up to a satisfiable amount takes a lot of time, so that's unrealistic
2021-02-14 12:39:42 +0100__minoru__shirae(~shiraeesh@109.166.57.144)
2021-02-14 12:40:00 +0100coot(~coot@37.30.55.141.nat.umts.dynamic.t-mobile.pl) (Client Quit)
2021-02-14 12:40:21 +0100 <maerwald> I have motivation to work on cabal-install, but not the capacity :o
2021-02-14 12:40:57 +0100 <madnificent> Is there a way to have a type `data Thing = AThing | BThing` and then further have an `data ExtendedThing = AThing | BThing | CThing` ? I was assuming I'd be allowed to `data ExtendedThing = Thing | CThing`?
2021-02-14 12:42:07 +0100 <Franciman> if I find a way to get around the problem of revisions that stackage mantainers so much whine about
2021-02-14 12:42:14 +0100 <Franciman> i shall have news
2021-02-14 12:42:24 +0100 <merijn> Franciman: Easy
2021-02-14 12:42:28 +0100 <merijn> Franciman: Include index-state
2021-02-14 12:42:42 +0100 <Franciman> merijn, problem
2021-02-14 12:42:45 +0100 <Franciman> it is a global setting
2021-02-14 12:42:49 +0100 <madnificent> So, I vaguely know that what I'm writing mixes things up. But it's the closest I got to expressing my vague goal and I'm hoping someone will smugly point me to how this sort of case is wrong thinking and will link me to some article or keywords to help my search.
2021-02-14 12:42:54 +0100 <merijn> Franciman: https://cabal.readthedocs.io/en/latest/cabal-project.html?highlight=index-state#cfg-field-index-st…
2021-02-14 12:43:03 +0100 <Franciman> i suppose the stackage whiners want per package index state
2021-02-14 12:43:04 +0100 <merijn> Franciman: It's not, you can set it in cabal.project...
2021-02-14 12:43:08 +0100 <Franciman> no I mean
2021-02-14 12:43:13 +0100 <Franciman> I want to set it on a per package base
2021-02-14 12:43:51 +0100 <maerwald> hackage revisions were a huge design mistake, but there's no way back
2021-02-14 12:44:01 +0100jedws(~jedws@101.184.202.248)
2021-02-14 12:44:58 +0100 <Franciman> I guess it would have been better if they modified the number
2021-02-14 12:45:12 +0100 <Franciman> of he version
2021-02-14 12:45:12 +0100 <Franciman> but you can't change much things when doing a revision
2021-02-14 12:45:19 +0100 <Franciman> it should theoretically be safe
2021-02-14 12:45:29 +0100 <Franciman> but i still don't understand why stackage whines about it
2021-02-14 12:45:33 +0100 <Franciman> they say it broke things
2021-02-14 12:45:41 +0100 <Franciman> -> they skip tests for some packages anyways
2021-02-14 12:46:05 +0100 <dcoutts> Given that it's entirely optional and easy to ignore, I've never undersood why tool authors complain.
2021-02-14 12:46:06 +0100 <maerwald> Franciman: it does break things, because the revision is not part of the tarball on hackage
2021-02-14 12:46:36 +0100 <Franciman> maerwald, wut
2021-02-14 12:46:43 +0100 <maerwald> Franciman: yes
2021-02-14 12:46:47 +0100 <Franciman> and how does it work?
2021-02-14 12:46:53 +0100 <Franciman> do you have any link to learn about it?
2021-02-14 12:46:57 +0100 <maerwald> Franciman: hackage API allows you to fetch the latest revision
2021-02-14 12:47:21 +0100 <maerwald> so if you package hackage stuff, you have to account for the fact
2021-02-14 12:47:35 +0100 <maerwald> and you can see that by looking at all the .cabal metadata patches gentoo does
2021-02-14 12:48:15 +0100 <maerwald> instead they could use the hackage API, but yeah
2021-02-14 12:48:21 +0100Sgeo(~Sgeo@ool-18b98aa4.dyn.optonline.net) (Read error: Connection reset by peer)
2021-02-14 12:48:47 +0100 <maerwald> a source tarball being a self-contained consistent thing is an important property imo
2021-02-14 12:49:19 +0100__minoru__shirae(~shiraeesh@109.166.57.144) (Ping timeout: 265 seconds)
2021-02-14 12:49:33 +0100 <Franciman> also, changing things under others nose is not a good idea
2021-02-14 12:49:44 +0100 <Franciman> it is better to signal with a version change
2021-02-14 12:49:45 +0100 <dcoutts> Yes, it's crucial not to modify the original tarball. And of course hackage does not, it just provides the revisions as an optional thing that tools can choose to use or ignore.
2021-02-14 12:49:53 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-02-14 12:50:08 +0100 <Franciman> dcoutts, but as far as I understand, there have been cases of revisions breaking things
2021-02-14 12:50:14 +0100 <maerwald> also true
2021-02-14 12:50:26 +0100 <maerwald> which is why cabal.freeze requires index pinning to be reliable
2021-02-14 12:50:37 +0100 <dcoutts> Franciman: if you choose to use them, then yes it's both possible to fix mistakes and also possible to make mistakes.
2021-02-14 12:50:58 +0100 <maerwald> and it's also possible the revision never makes it into the upstream repo
2021-02-14 12:51:10 +0100 <Franciman> the problem is that RN stackage can reference revisions
2021-02-14 12:51:12 +0100 <Franciman> cabal can not
2021-02-14 12:51:17 +0100 <Franciman> cabal freeze*
2021-02-14 12:51:33 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-02-14 12:51:42 +0100 <dcoutts> there's no need to reference revisions, all revisions are the same version of the code. It's the same tarball.
2021-02-14 12:52:02 +0100 <Franciman> so what breaks?
2021-02-14 12:52:04 +0100 <maerwald> dcoutts: you just said revisions can introduce mistakes
2021-02-14 12:52:27 +0100 <maerwald> so with cabal you can't say "this revision is broken, don't use it" only implicitly via index state
2021-02-14 12:52:31 +0100 <maerwald> which is not enough control
2021-02-14 12:53:22 +0100 <maerwald> (I had a case of revision breaking build plan in production, because of another architecture that we didn't use)
2021-02-14 12:53:25 +0100 <dcoutts> If you choose to use the latest revision of a package metadata and that tightens the constraints such that your build plan no longer works then you have a choice: you can look at what the maintainers have done (perhaps there is a bug in some combination of versions that you're using) or you can choose to override the constraint in your cabal.project.
2021-02-14 12:53:56 +0100Bigcheese(~quassel@unaffiliated/bigcheese) (Remote host closed the connection)
2021-02-14 12:54:01 +0100 <__monty__> Hmm, so it may be better to just bump the version? Potentially carefully revising the bad version so less people experience problems?
2021-02-14 12:54:33 +0100 <maerwald> dcoutts: how can you override it? You can only override it by usint either a) index state (which is global per-project) or b) by adding source-repository
2021-02-14 12:54:35 +0100 <dcoutts> You always have the option to override the constraints. But if maintainers have tightened constraints then it's very often for a good reason and it's worth looking at.
2021-02-14 12:54:49 +0100 <maerwald> ah, you mean allow-newer/older?
2021-02-14 12:55:04 +0100Bigcheese(~quassel@unaffiliated/bigcheese)
2021-02-14 12:55:09 +0100 <dcoutts> maerwald: you can override specific constraints in specific packages. Yes, using allow-newer/older
2021-02-14 12:55:26 +0100 <Franciman> this is game changing
2021-02-14 12:55:29 +0100 <Franciman> thanks
2021-02-14 12:55:48 +0100 <dcoutts> "I want to ignore the upper boung constraint on foo in package bar"
2021-02-14 12:55:50 +0100 <Franciman> I can compare the revision with the old version
2021-02-14 12:55:57 +0100 <Franciman> and use allow- stuff
2021-02-14 12:56:02 +0100 <Franciman> to fake the revision control
2021-02-14 12:56:10 +0100Francimanis dreaming
2021-02-14 12:56:13 +0100hololeap(~hololeap@unaffiliated/hololeap) (Ping timeout: 256 seconds)
2021-02-14 12:56:37 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 272 seconds)
2021-02-14 12:56:55 +0100 <maerwald> but allow-newer doesn't allow a version range afaik
2021-02-14 12:56:58 +0100 <Franciman> maerwald, sorry, do you have al ink to hackage api?
2021-02-14 12:57:01 +0100hololeap(~hololeap@unaffiliated/hololeap)
2021-02-14 12:57:08 +0100 <Franciman> maerwald, well I could use the constraint options
2021-02-14 12:57:17 +0100 <dcoutts> maerwald: no, but why would it? You can already constraint further.
2021-02-14 12:57:17 +0100 <maerwald> yeah, it's a bit more finicky
2021-02-14 12:57:19 +0100 <Franciman> there is an option that allows adding further constraints that override
2021-02-14 12:57:43 +0100 <maerwald> Franciman: https://hackage.haskell.org/api
2021-02-14 12:57:44 +0100 <Franciman> ah you mean that using constraint, it is global
2021-02-14 12:57:49 +0100 <Franciman> thanks a lot
2021-02-14 12:58:45 +0100shailangsa(~shailangs@host86-186-177-153.range86-186.btcentralplus.com) (Ping timeout: 240 seconds)
2021-02-14 12:59:13 +0100 <Franciman> as a side note, I still do not understand if I can create my own stackage
2021-02-14 12:59:18 +0100 <Franciman> and make stack use my stackage
2021-02-14 12:59:25 +0100 <maerwald> Franciman: yes
2021-02-14 12:59:38 +0100Alleria(~textual@2603-7000-3040-0000-0036-b491-5ac9-398e.res6.spectrum.com)
2021-02-14 13:00:01 +0100AlleriaGuest4247
2021-02-14 13:00:12 +0100 <maerwald> https://docs.haskellstack.org/en/stable/yaml_configuration/#resolver
2021-02-14 13:00:27 +0100 <maerwald> it uses this pantry thing (awful if you ask me.. too much syntax/options)
2021-02-14 13:00:37 +0100 <maerwald> so you provide a snapshot url
2021-02-14 13:00:38 +0100 <Franciman> thanks, again
2021-02-14 13:00:57 +0100jedws(~jedws@101.184.202.248) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-02-14 13:01:34 +0100frozenErebus(~frozenEre@94.128.81.133)
2021-02-14 13:01:53 +0100bnbgg_(uid454564@gateway/web/irccloud.com/x-dlouokgmjjwefkhf)
2021-02-14 13:04:14 +0100Guest4247(~textual@2603-7000-3040-0000-0036-b491-5ac9-398e.res6.spectrum.com) (Ping timeout: 264 seconds)
2021-02-14 13:06:45 +0100 <ij> what does a priority queue do that Set doesn't?
2021-02-14 13:07:18 +0100 <ij> I don't have any particular priority queue in mind
2021-02-14 13:09:57 +0100justanotheruser(~justanoth@unaffiliated/justanotheruser) (Ping timeout: 260 seconds)
2021-02-14 13:10:14 +0100raehik1(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-02-14 13:11:10 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se)
2021-02-14 13:11:12 +0100__minoru__shirae(~shiraeesh@109.166.57.144)
2021-02-14 13:11:46 +0100petersen(~petersen@redhat/juhp)
2021-02-14 13:13:05 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds)
2021-02-14 13:14:01 +0100heatsink(~heatsink@2600:1700:bef1:5e10:f066:c875:bf57:1bea)
2021-02-14 13:14:45 +0100lawid_(~quassel@dslb-090-186-208-195.090.186.pools.vodafone-ip.de) (Ping timeout: 240 seconds)
2021-02-14 13:14:55 +0100 <dcoutts> ij: a heap is less ordered than an ordered search tree. Priority queues types typically use heap data structures. Ordered set types typically use ordered search trees.
2021-02-14 13:15:10 +0100 <dcoutts> https://en.wikipedia.org/wiki/Heap_(data_structure)
2021-02-14 13:15:13 +0100lawid(~quassel@dslb-090-186-198-195.090.186.pools.vodafone-ip.de)
2021-02-14 13:16:26 +0100 <dcoutts> The basic trade-off is that because heaps are less ordered than search trees, they provide fewer useful operations but the ones they do provide are faster (asymptotically).
2021-02-14 13:17:01 +0100coot(~coot@37.30.55.141.nat.umts.dynamic.t-mobile.pl)
2021-02-14 13:17:49 +0100 <ij> Data.PQueue shows that insert is faster (O(1), worst case O(log n), but deleteFindMin is O(log n) for both
2021-02-14 13:18:38 +0100heatsink(~heatsink@2600:1700:bef1:5e10:f066:c875:bf57:1bea) (Ping timeout: 264 seconds)
2021-02-14 13:19:58 +0100 <dcoutts> A nice way to look at it is this: you can build a heap in O(n) time, and then repeatedly extract the minimum element n times, each one O(log n) giving you O(n log n) total to sort. With an ordered tree it costs you O(n log n) to build in the first place and then O(n) to traverse to yield a sorted sequence.
2021-02-14 13:20:11 +0100olligobber(olligobber@gateway/vpn/privateinternetaccess/olligobber) (Remote host closed the connection)
2021-02-14 13:20:30 +0100 <dcoutts> So both give you O(n log n) to sort (as theory requires) but with a difference balance of where you pay the costs.
2021-02-14 13:20:42 +0100 <ij> that is a nice way to look at it!
2021-02-14 13:21:10 +0100 <dcoutts> this is the basis of the heap sort algorithm
2021-02-14 13:21:19 +0100leifm(~leif@dawn.whatbox.ca) (Ping timeout: 272 seconds)
2021-02-14 13:21:34 +0100leifm_(~leifm@dawn.whatbox.ca)
2021-02-14 13:21:38 +0100shailangsa(~shailangs@host86-185-98-28.range86-185.btcentralplus.com)
2021-02-14 13:22:15 +0100 <ij> I recently learned about it. It took me forever to figure out what the "heap order" for the data meant precisely. More than one tutorial seemed to gloss over it, when I was searching.
2021-02-14 13:22:36 +0100hololeap(~hololeap@unaffiliated/hololeap) (Ping timeout: 272 seconds)
2021-02-14 13:22:41 +0100Deide(~Deide@217.155.19.23)
2021-02-14 13:23:17 +0100hololeap(~hololeap@unaffiliated/hololeap)
2021-02-14 13:23:45 +0100 <dcoutts> ij: so you get why the heap order mean the elements are only partially ordered, not totally ordered like in a search tree.
2021-02-14 13:25:13 +0100 <ij> it seems that they just aren't built with with the preservation of sortedness, but it's easy to find the smallest one :)
2021-02-14 13:25:58 +0100 <dcoutts> Yes, and it's exactly because they're not totally ordered that they're cheaper to build.
2021-02-14 13:26:08 +0100 <ij> gotcha
2021-02-14 13:26:50 +0100 <dcoutts> Since the theory of sorting says any (comparison based) sort is O(n log n) minimum.
2021-02-14 13:26:57 +0100__minoru__shirae(~shiraeesh@109.166.57.144) (Ping timeout: 264 seconds)
2021-02-14 13:27:21 +0100shutdown_-h_now(~arjan@2001:1c06:2d0b:2312:40b3:9495:b829:f8f6)
2021-02-14 13:29:07 +0100atraii(~atraii@2601:681:8800:a991:b78:7e8b:3676:bb2c)
2021-02-14 13:33:07 +0100 <merijn> Franciman: "revisions can break things" <- well, consider this: A maintainer finds out their dependency bounds are wrong and lead to incorrect behaviour with dependency foo-1.0. They make a revision to disallow "foo-1.0". Someone was using this package and need foo-1.0 to get a working build plan. This build plan is now "broken" by the revision
2021-02-14 13:33:47 +0100 <merijn> Franciman: But can you *really* consider this as "the revision breaking things"? I'd say it's merely "the revision makes previously undetectable breakage, detectable"
2021-02-14 13:34:14 +0100atraii(~atraii@2601:681:8800:a991:b78:7e8b:3676:bb2c) (Ping timeout: 264 seconds)
2021-02-14 13:34:20 +0100 <merijn> People who complain about "revisions breaking things" seem to be blindly assuming "it compiled in the past, therefore it worked"
2021-02-14 13:34:25 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se) (Ping timeout: 240 seconds)
2021-02-14 13:34:41 +0100 <dcoutts> Exactly. And that's where you get to decide if you agree with the maintainer or want to override their advice.
2021-02-14 13:35:42 +0100 <pjb> merijn: isn't it the motto of haskel: "if it compiles, then it just works"?
2021-02-14 13:35:58 +0100 <merijn> It also strikes me there is considerable overlap between the "specifying upperbounds sucks, it's too much work!" and "why is half of hackage broken?!" crowds
2021-02-14 13:36:51 +0100 <merijn> "Well, well, well...if it isn't the consequences of my own actions!"
2021-02-14 13:37:02 +0100 <merijn> pjb: Yes, no, maybe, it depends
2021-02-14 13:37:27 +0100 <merijn> If *my* code compiles it works, if other peoples code compiles, that probably just means they did something dumb >.>
2021-02-14 13:38:40 +0100 <merijn> dcoutts: tbh, half the "problems" with cabal-install is just "people don't realise how hard long term packaging is, because most other tools just whiff on that goal entirely" >.>
2021-02-14 13:38:53 +0100 <dcoutts> yup
2021-02-14 13:39:10 +0100 <dcoutts> people believe it should be an easy problem
2021-02-14 13:39:14 +0100 <merijn> dcoutts: And one of these days I will finally get around to my sequence of blogposts of "cabal is right and the conveniences you demand are dumb"
2021-02-14 13:40:05 +0100 <merijn> dcoutts: Well, the problem is that pip/npm/gem are just "incrementally automating actions people do manually" without a consistent design, and if all you've got is a massive pile of hacks, then layering on more convenience hacks is reasonable, so that's what people do
2021-02-14 13:40:15 +0100 <dcoutts> you can probably put it more diplomatically ;-)
2021-02-14 13:40:33 +0100 <merijn> And then they try to transpose their "but it's only a little code to handle this specific edge case I want"
2021-02-14 13:40:44 +0100 <merijn> dcoutts: I could, but then no one would read it, so what'd the point be? :p
2021-02-14 13:41:07 +0100 <dcoutts> hah hah, ok, clickbait it is
2021-02-14 13:42:49 +0100 <merijn> No one's going to click "Cabal-install: a thoughtful overview of the difficulties of packaging" :p
2021-02-14 13:43:06 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-02-14 13:43:07 +0100 <dcoutts> clearly that is what I was doing wrong :-)
2021-02-14 13:43:47 +0100 <merijn> dcoutts: The average Haskeller was considerably difficult when you started on cabal-install :p
2021-02-14 13:43:51 +0100 <merijn> eh
2021-02-14 13:43:54 +0100 <merijn> s/difficult/different
2021-02-14 13:44:23 +0100 <merijn> Like, academics and compiler hackers in a time where npm had implanted terrible ideas in the heads of most beginners :p
2021-02-14 13:44:32 +0100 <merijn> s/had/hadn't
2021-02-14 13:44:38 +0100 <dcoutts> true
2021-02-14 13:44:40 +0100 <merijn> Typing is hard, maybe I should give up on it >.>
2021-02-14 13:47:14 +0100 <merijn> dcoutts: FWIW, cabal-install has consistently been the most reliable/predictable/consistent language tool I've worked with, which says something about the quality of its design. I think the biggest pain point is communicating the difficulty of the problem and design rationale for the current solution to beginners with essentially no frame of reference for these problems
2021-02-14 13:47:39 +0100 <dcoutts> aye, and some sharp corners still
2021-02-14 13:48:04 +0100 <merijn> Their reference is "but I can easily do this in pip" and not the "yeah, but that fundamentally breaks tons of things hiding in dark corner cases"
2021-02-14 13:48:26 +0100idhugo(~idhugo@80-62-117-97-mobile.dk.customer.tdc.net) (Remote host closed the connection)
2021-02-14 13:48:31 +0100idhugo_(~idhugo@80-62-117-97-mobile.dk.customer.tdc.net)
2021-02-14 13:48:42 +0100justanotheruser(~justanoth@unaffiliated/justanotheruser)
2021-02-14 13:52:36 +0100Alleria__(~textual@zrcout.mskcc.org)
2021-02-14 13:52:39 +0100hiroaki(~hiroaki@ip4d166d67.dynamic.kabel-deutschland.de)
2021-02-14 13:54:01 +0100 <merijn> dcoutts: btw, I know cabal(-install) leadership was put before the Haskell Foundation, but I dunno if that was anywhere public and if/where discussion about it would be, do you happen to know?
2021-02-14 13:55:01 +0100 <dcoutts> merijn: getting properly involved in that coversation is on my todo list for this weekend :-)
2021-02-14 13:55:15 +0100 <maerwald> merijn: you have made no argument why revisions are anything more than mere maintenance convenience for hackage trustees and are superior to doing a micro version bump with the fixed .cabal metadata
2021-02-14 13:55:53 +0100 <__monty__> maerwald: That would require everyone to cooperate and split their constraints to include the broken versions though.
2021-02-14 13:55:57 +0100 <dcoutts> maerwald: having a separation of role between people looking after individual packages and a whole collection is really useful.
2021-02-14 13:56:11 +0100 <merijn> maerwald: That would require a full new tarball release and blow up the index too
2021-02-14 13:56:14 +0100geekosaur(ac3a89e7@172.58.137.231)
2021-02-14 13:56:15 +0100 <maerwald> yes
2021-02-14 13:56:20 +0100 <merijn> maerwald: It's not just trustees, though
2021-02-14 13:56:28 +0100 <__monty__> maerwald: I do think it's reasonable to ask to be able to constrain revisions too though.
2021-02-14 13:56:30 +0100 <merijn> I bump my own upper bounds in revisions
2021-02-14 13:56:58 +0100 <maerwald> dcoutts: you can have that separation and still release a new tarball
2021-02-14 13:57:01 +0100 <dcoutts> This split role model works really well in lots of places: e.g. distros, and individual package maintainers can help too. They can always upload new micro versions if they prefer.
2021-02-14 13:57:19 +0100 <merijn> maerwald: What, exactly, is the advantage of your suggestion?
2021-02-14 13:57:21 +0100 <dcoutts> maerwald: non-maintainers should not be releasing tarballs. That's crossing a line.
2021-02-14 13:57:35 +0100 <merijn> maerwald: The disadvantage is "blows up the index size", I don't see any real advantage?
2021-02-14 13:58:02 +0100 <maerwald> merijn: a tarball is self consistent
2021-02-14 13:58:03 +0100 <merijn> If you, as maintainer, prefer micro updates you can still do that just fine?
2021-02-14 13:58:24 +0100 <maerwald> if you want to pull the latest package from hackage without cabal, you're up for a challenge
2021-02-14 13:58:29 +0100Varis(~Tadas@unaffiliated/varis) (Remote host closed the connection)
2021-02-14 13:58:46 +0100 <merijn> maerwald: It's just two fetch requests, iirc?
2021-02-14 13:58:54 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 13:59:02 +0100 <merijn> 1 for the tar ball, 1 for the revision
2021-02-14 13:59:10 +0100 <maerwald> yes
2021-02-14 13:59:22 +0100 <merijn> That doesn't seem like such a huge amount of work?
2021-02-14 13:59:33 +0100 <maerwald> merijn: gentoo hasn't managed to do it afais :)
2021-02-14 13:59:35 +0100 <__monty__> Don't you need the 01-index tarball thing too?
2021-02-14 13:59:37 +0100 <dcoutts> there's even a library available to do it properly (hackage-security)
2021-02-14 13:59:49 +0100 <merijn> dcoutts: Can you lemme know when you find out? (wrt cabal discussion) :)
2021-02-14 13:59:52 +0100Varis(~Tadas@unaffiliated/varis)
2021-02-14 13:59:57 +0100 <maerwald> merijn: I tried to implement it in exherbo and the patch was rejected
2021-02-14 14:00:07 +0100 <dcoutts> merijn: sure, are you volunteering? :-)
2021-02-14 14:00:42 +0100 <merijn> dcoutts: I am not not volunteering :p
2021-02-14 14:01:10 +0100 <dcoutts> merijn: part of it is just making sure we have enough people who feel empowered to do a release when needed. So it's not necessarily about taking over responsibility for everything.
2021-02-14 14:02:06 +0100grumble(~Thunderbi@freenode/staff/grumble) (Quit: ACCORDING TO ALL KNOWN LAWS OF AVIATION THERE IS NO WAY A BEE SHOULD BE ABLE TO FLY ITS WINGS ARE TOO SMALL TO GET ITS FAT LITTLE BODY OFF THE GROUND THE BEE OF COURSE FLIES ANYWAY BECAUSE BEES DON'T CARE WHAT HUMANS THINK IS IMPOSSIBLE)
2021-02-14 14:02:39 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr)
2021-02-14 14:02:54 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se)
2021-02-14 14:03:09 +0100 <merijn> dcoutts: I've tried to at least keep up to date with stuff in the time I've been to busy to actually hack on cabal-install, but I know that at least some of the people with commit bits (me, fgaz, some others) are unsure about how far that authority goes. OTOH, the commit bit ticket says "be bold", so I guess maybe it's just a matter of "Just Do It" ;)
2021-02-14 14:03:45 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 272 seconds)
2021-02-14 14:04:43 +0100 <merijn> dcoutts: In the past I'd just run patches by hvr, but he's clearly too busy these days.
2021-02-14 14:05:30 +0100 <maerwald> dcoutts: hackage trustees already have the power to do releases, when the maintainer isn't responding, btw. We're already crossing that line. And hackage is a shared resource. Maintaining build plans is clearly part of that
2021-02-14 14:06:07 +0100 <maerwald> merijn: versions (without revisions) is a cleaner API overall
2021-02-14 14:06:10 +0100 <merijn> __monty__: 01-index is the index of all packages, which includes revisions, but you don't need to fetch that just to get a specific tarball
2021-02-14 14:06:17 +0100frozenErebus(~frozenEre@94.128.81.133) (Ping timeout: 272 seconds)
2021-02-14 14:06:25 +0100Ariakenom(~Ariakenom@2001:9b1:efb:fc00:6820:5e7f:6476:59ce)
2021-02-14 14:06:44 +0100 <dcoutts> maerwald: really? for specific packages or for all packages? when did that change?
2021-02-14 14:07:05 +0100 <__monty__> merijn: Don't you need it to figure out the latest revision?
2021-02-14 14:08:00 +0100 <merijn> __monty__: There's an HTTP endpoint for that, I think?
2021-02-14 14:08:09 +0100 <maerwald> dcoutts: https://github.com/haskell-infra/hackage-trustees/blob/master/policy.md#3-source-changes-simple-pa…
2021-02-14 14:08:25 +0100 <merijn> dcoutts: As intermediate step instead of package take over
2021-02-14 14:08:39 +0100 <__monty__> maerwald: You didn't address the usability issue though. Do you really expect everyone to poke holes in their version constraints for every revision-equivalent version bump?
2021-02-14 14:08:58 +0100dhil(~dhil@80.208.56.181)
2021-02-14 14:09:02 +0100 <maerwald> __monty__: revisions are a usability issue.. every tool dealing with hackage tarballs needs to be aware of them
2021-02-14 14:09:22 +0100 <merijn> __monty__: Well, presumably those micro bumps are PVP compliant
2021-02-14 14:09:26 +0100 <dcoutts> maerwald: oh that, ok that's a bit different, and not so controversial
2021-02-14 14:09:33 +0100grumble(~Thunderbi@freenode/staff/grumble)
2021-02-14 14:09:41 +0100 <__monty__> merijn: Probably, since you can get it via hackage. Maybe it the problem was you can't get anything but no revision or latest revision without 01-index? I remember some discussion about this.
2021-02-14 14:10:02 +0100grumble(~Thunderbi@freenode/staff/grumble) (Client Quit)
2021-02-14 14:10:21 +0100geekosaur(ac3a89e7@172.58.137.231) (Quit: Connection closed)
2021-02-14 14:10:29 +0100 <merijn> __monty__: That's not true
2021-02-14 14:10:29 +0100 <maerwald> __monty__: the fact that you have to pin hackage index state for a freeze file to be reliable is another good case showing that although it seems simple, it even breaks the assumptions of the cabal maintainers
2021-02-14 14:10:33 +0100 <__monty__> merijn: Still requires people to make sure the pre-revision version does not pass their constraints.
2021-02-14 14:10:35 +0100grumble(~Thunderbi@freenode/staff/grumble)
2021-02-14 14:10:45 +0100 <merijn> __monty__: Why?
2021-02-14 14:11:08 +0100 <maerwald> (and: index state pinning has more side-effects)
2021-02-14 14:11:16 +0100 <maerwald> (you might not actually want that)
2021-02-14 14:11:30 +0100 <maerwald> so stuff now is more complicated, not less
2021-02-14 14:12:20 +0100 <dcoutts> a freeze file should probably just pin the index state too
2021-02-14 14:12:20 +0100 <__monty__> merijn: constraint ^>= 1.0, if this is revised you'll automatically get the fixed 1.0 instead, if a new version is released you have to change your constraint so 1.0 isn't allowed anymore, because another dependency could have naively added constraint == 1.0.
2021-02-14 14:12:45 +0100 <maerwald> dcoutts: well, you might want to pin a subset of hackage and have the rest rolling and up2date... but now you can't
2021-02-14 14:12:48 +0100 <merijn> __monty__: huh?
2021-02-14 14:13:03 +0100 <maerwald> unless you accept the fact that the next revision update may break your build plan
2021-02-14 14:13:32 +0100 <dcoutts> maerwald: well if you're managing your freeze file manutally you can do what you like. Your complaint seemed to be about what's a sensible default for most users.
2021-02-14 14:13:36 +0100 <__monty__> maerwald: I said I agree there should be something like constraints on revisions.
2021-02-14 14:13:47 +0100 <merijn> __monty__: Like?
2021-02-14 14:14:09 +0100 <__monty__> merijn: "Don't use revision 3 cause it's broken."
2021-02-14 14:14:20 +0100 <maerwald> dcoutts: well, I can't pin revisions, as was discussed before. This simple addition to hackage had far more implications than cabal devs anticipated
2021-02-14 14:14:21 +0100 <merijn> __monty__: I think you misunderstand maerwald's comment
2021-02-14 14:14:43 +0100heatsink(~heatsink@2600:1700:bef1:5e10:f066:c875:bf57:1bea)
2021-02-14 14:14:57 +0100 <__monty__> I'm open to being made to understand.
2021-02-14 14:14:59 +0100 <merijn> __monty__: "You need to change ^>= 1.0 if it's fixed with a new release" <- that's not what maerwald was talking about
2021-02-14 14:15:31 +0100 <merijn> __monty__: His point was, rather than revising package 1.0.0 with a new upper bound on dependency foo, you can release version 1.0.0.1 with the new "foo" upperbound
2021-02-14 14:15:35 +0100 <__monty__> No, that's an example of a usability issue I see with "Just use versions instead of revisions."
2021-02-14 14:15:51 +0100 <dcoutts> maerwald: the thing I'd like to do in the long term is unify the idea of the hackage revisions and the stackage snapshots into a single package sets idea, an allow anyone to publish them on hackage, and to select them (or combinations of them) in project files.
2021-02-14 14:16:18 +0100 <maerwald> dcoutts: What do you think about this: a metadata update is carried out the same way as now by hackage trustees... but instead of creating a revision update, it will 1) create a new release with micro version bumped, 2) send an email to a dedicated ML + the maintaner and 3) mark this version in hackage in some way, indicating that it's a metadata update only release
2021-02-14 14:16:24 +0100 <merijn> __monty__: If another package uses ^>=1.0.0 it still works, because 1.0.0 wasn't broken, it just had a restricted build plan and 1.0.0.1 is the same code with a relaxed buildplan
2021-02-14 14:16:54 +0100 <dcoutts> maerwald: I don't see how that's any better (and it's worse in several ways).
2021-02-14 14:17:03 +0100 <__monty__> merijn: Yeah, that's the problem, that leaves 1.0.0 potentially broken because somewhere in your build plan something constrains the package to not allow 1.0.0.1 or to require a version of foo past that upper bound, which rules out 1.0.0.1.
2021-02-14 14:17:07 +0100 <merijn> dcoutts: That was maerwald's suggested issue on cabal github, but that'd harm the critical path for plan.json, though
2021-02-14 14:17:19 +0100 <merijn> __monty__: Why does it leave 1.0.0 broken?
2021-02-14 14:17:43 +0100 <merijn> __monty__: The assumption is that you released 1.0.0 with accurate (i.e. conservative) upperbounds
2021-02-14 14:17:50 +0100 <merijn> If you didn't, then yeah, you're fucked
2021-02-14 14:18:31 +0100 <merijn> maerwald: The main reason revisions are necessary over microbumps is the insistence of a certain subsection of Hackage to on principle just refuse to add upperbounds to their releases
2021-02-14 14:18:47 +0100 <merijn> maerwald: Your approach *only* works if people upload package with proper upperbounds
2021-02-14 14:19:00 +0100 <__monty__> merijn: That sounds like an "It works if you do it right," argument. Which applies equally to revisions.
2021-02-14 14:19:18 +0100 <merijn> __monty__: Revisions work if you don't do it right either, which is why we have them
2021-02-14 14:19:32 +0100 <merijn> because a vocal minority of the community refuses to do it right :p
2021-02-14 14:19:35 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se) (Ping timeout: 272 seconds)
2021-02-14 14:19:40 +0100 <__monty__> No, the "you" here is the person authoring the revision.
2021-02-14 14:19:48 +0100 <merijn> __monty__: That's irrelevant
2021-02-14 14:19:50 +0100heatsink(~heatsink@2600:1700:bef1:5e10:f066:c875:bf57:1bea) (Ping timeout: 264 seconds)
2021-02-14 14:20:02 +0100 <merijn> __monty__: Because if you fuck it up by accident, you can revise your revision :p
2021-02-14 14:20:06 +0100 <maerwald> merijn: given the ^>= syntax (although I think cabal has no switch to ignore those upper bounds yet), I think it's less controversial
2021-02-14 14:20:13 +0100 <merijn> maerwald: It does
2021-02-14 14:20:17 +0100 <maerwald> which one is it
2021-02-14 14:20:29 +0100 <__monty__> No it's not. I'm not talking about package uploaders doing it right. I'm talking about the hackage trustee(?) doing it right. They're only human they can accidentally push a bad revision.
2021-02-14 14:20:39 +0100 <merijn> --allow-newer has a ^ syntax that lets you select it, but documentation is...lacking :)
2021-02-14 14:20:51 +0100deja(~deja@213162080090.public.t-mobile.at)
2021-02-14 14:20:56 +0100 <merijn> __monty__: Which can be fixed with a new one
2021-02-14 14:21:10 +0100 <maerwald> well, I want a switch saying "ignore all upper bounds, except those that are in place due to *known* build failures"
2021-02-14 14:21:16 +0100star_cloud(~star_clou@ec2-34-220-44-120.us-west-2.compute.amazonaws.com) (Ping timeout: 240 seconds)
2021-02-14 14:21:34 +0100 <__monty__> merijn: The revise a revision part is exactly why constraints on revisions is sensible. You can simply specify "revision 3 is broken, never use it, even if it's the most recent revision you have access to because of index-state."
2021-02-14 14:21:39 +0100 <merijn> maerwald: So, kinda the inverted selection of what's possible now
2021-02-14 14:21:49 +0100deja(~deja@213162080090.public.t-mobile.at) (Client Quit)
2021-02-14 14:22:19 +0100 <maerwald> dcoutts: what we may really want is the stable/unstable separation like in Gentoo ;)
2021-02-14 14:22:40 +0100 <merijn> maerwald: https://cabal.readthedocs.io/en/latest/cabal-project.html?highlight=allow-newer#cfg-field-allow-ne…
2021-02-14 14:23:08 +0100 <merijn> maerwald: Note the description of ^ to relax only ^>= bounds and in certain scopes
2021-02-14 14:23:43 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se)
2021-02-14 14:24:43 +0100 <merijn> maerwald: I think a negation operator for allow-newer so that "~foo" would allow newer for everything *except* "foo" would be a good idea. I think you can already get those semantics right now, by enumerating all the non-foo ones, but having an explicit operator to act as "inversion" makes sense
2021-02-14 14:24:48 +0100 <nshepperd> it was a revelation when i discovered that you can do per-dependency allow-newer in cabal.project
2021-02-14 14:25:01 +0100Rudd0(~Rudd0@185.189.115.103) (Ping timeout: 265 seconds)
2021-02-14 14:25:06 +0100 <nshepperd> no more forking things locally just to bump bounds
2021-02-14 14:25:07 +0100 <merijn> nshepperd: That works on the commandline too :p
2021-02-14 14:25:13 +0100 <merijn> But, yeah
2021-02-14 14:26:33 +0100 <nshepperd> it would be good if you could do "allow-newer: package:dep < x.y.z" or something too
2021-02-14 14:26:51 +0100 <merijn> maerwald: If you care enough to implement it, I would merge an inversion operator for allow-newer. You'd have to consult the specs to find if ~ or ! is disallowed in package names (and thus safe to use)
2021-02-14 14:27:02 +0100 <merijn> nshepperd: You can add custom constraints to the build plan
2021-02-14 14:27:28 +0100hseg(~gesh@IGLD-84-228-239-97.inter.net.il)
2021-02-14 14:27:28 +0100 <merijn> nshepperd: So you can just use --constraint (or 'constraint:' in cabal.project) to give an arbitrary constraint like that
2021-02-14 14:27:30 +0100 <maerwald> dcoutts: so there could be three levels: 1. testing (this is the only layer package authors have direct upload access to), 2. unstable (only boot/core are guaranteed to build, upper bounds are loose), 3. a large subset of hackage is guaranteed to work with tight upper bounds
2021-02-14 14:27:32 +0100 <nshepperd> i suppose so
2021-02-14 14:27:51 +0100kenran(~kenran@i59F67B96.versanet.de) (Quit: leaving)
2021-02-14 14:27:58 +0100 <nshepperd> yeah i guess the intersection of allow-newer and a separate constraint is enough
2021-02-14 14:28:19 +0100 <maerwald> dcoutts: and all layers could still be rolling
2021-02-14 14:29:03 +0100deja(~deja@213162080090.public.t-mobile.at)
2021-02-14 14:29:55 +0100 <Franciman> <merijn> People who complain about "revisions breaking things" seem to be blindly assuming "it compiled in the past, therefore it worked" <- gotcha merijn
2021-02-14 14:29:56 +0100 <Franciman> thanks
2021-02-14 14:30:16 +0100dhil(~dhil@80.208.56.181) (Ping timeout: 240 seconds)
2021-02-14 14:30:22 +0100 <maerwald> I don't think I have to argue why rolling is generally superior... freeze files, LTS, nix are all nice, but are really less interesting if there is hight build success chance in your rolling stable branch
2021-02-14 14:30:26 +0100them_(~them_@217.146.82.202) (Remote host closed the connection)
2021-02-14 14:32:05 +0100son0p(~son0p@181.58.39.182) (Quit: Lost terminal)
2021-02-14 14:32:07 +0100Wuzzy(~Wuzzy@p57a2e574.dip0.t-ipconnect.de)
2021-02-14 14:33:06 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 14:33:09 +0100 <maerwald> Franciman: tighter upper bounds are sometimes introduces due to build failures in *specific* architectures... but we lack a way to express different build plans for different arches
2021-02-14 14:33:25 +0100 <maerwald> so revisions sometimes break valid build plans due to that
2021-02-14 14:33:59 +0100frozenErebus(~frozenEre@94.128.81.133)
2021-02-14 14:34:23 +0100 <merijn> maerwald: That could be addressed by an arch() flag in cabal (Don't we have one already) and making the restriction architecture specific
2021-02-14 14:34:46 +0100 <merijn> Although I think revisions currently don't allow you to introduce if/else constructs in a revision
2021-02-14 14:34:46 +0100 <__monty__> Metadata on constraints does sound reasonable to me. "This bound is because PVP, this bound is because it's broken on ARM, this bound is because of a bug..."
2021-02-14 14:35:15 +0100 <merijn> __monty__: PVP vs bug is the intended difference between ^>= and <
2021-02-14 14:35:33 +0100 <merijn> ^>= singals "PVP bound" and < signals hard bound
2021-02-14 14:36:06 +0100rdivyanshu(uid322626@gateway/web/irccloud.com/x-pkahdvkefnsdjqce)
2021-02-14 14:37:08 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se) (Ping timeout: 256 seconds)
2021-02-14 14:37:27 +0100 <maerwald> merijn: not arches, old GHCs... my mistake
2021-02-14 14:37:38 +0100 <__monty__> I guess that's true. Limited and new enough that some people don't use for "compatibility" reasons though : /
2021-02-14 14:37:43 +0100 <maerwald> merijn: https://github.com/ekmett/contravariant/issues/61#issuecomment-498606805
2021-02-14 14:37:46 +0100 <Franciman> wait, we also have constraints on ghc versions
2021-02-14 14:37:48 +0100 <Franciman> ah no!
2021-02-14 14:37:51 +0100 <Franciman> it's compiler version
2021-02-14 14:37:55 +0100 <Franciman> err
2021-02-14 14:37:59 +0100 <Franciman> I mean compiler flavour
2021-02-14 14:38:05 +0100 <Franciman> GHC , JHC and others
2021-02-14 14:39:22 +0100Marissa(Marissa@33.anserq.com) (Quit: Marissa)
2021-02-14 14:39:43 +0100 <__monty__> The indirect constraint on GHC version through base is kind of opaque, yeah.
2021-02-14 14:39:48 +0100 <merijn> __monty__: It's slowly becoming old enough to start making head way
2021-02-14 14:39:53 +0100ambiso9(~ambiso@209.182.239.205)
2021-02-14 14:40:07 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 14:40:25 +0100raehik1(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds)
2021-02-14 14:40:29 +0100 <__monty__> merijn: In a couple years I'll claim I pioneered it by using it extensively in my unreleased projects ; )
2021-02-14 14:40:33 +0100 <Franciman> I don't know if this was already said, but I really hope the haskell foundation regularizes cabal development a bit
2021-02-14 14:41:08 +0100 <maerwald> I think it *does* make sense to reduce valid build plans sometimes, as long as there's still a valid build plan
2021-02-14 14:41:09 +0100 <merijn> __monty__: ^>= syntax requires cabal-version 2.0 which is approaching 4 years old
2021-02-14 14:41:20 +0100 <Franciman> that was a cool hat trick
2021-02-14 14:41:28 +0100 <Franciman> it scammed really hard with the stack fellas
2021-02-14 14:41:37 +0100 <Franciman> I really hope the two tools join forces in a constructive way
2021-02-14 14:41:43 +0100 <maerwald> Franciman: no
2021-02-14 14:41:47 +0100 <merijn> Franciman: Unlikely
2021-02-14 14:41:58 +0100 <maerwald> different philosophies are better off separate
2021-02-14 14:41:59 +0100 <Franciman> that's what I wanted to do with vabal, but I failed :P
2021-02-14 14:42:05 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 14:42:06 +0100 <Franciman> I like the idea of stackage
2021-02-14 14:42:18 +0100 <Franciman> I strongly dislike forking the community creating two different tools with different user interfaces
2021-02-14 14:42:21 +0100 <maerwald> yes, stackage as a concept is possible in cabal
2021-02-14 14:42:22 +0100 <merijn> __monty__: I mean, there's not much reason to support old cabal versions
2021-02-14 14:42:24 +0100 <__monty__> Stackage is great but you don't need stack for that?
2021-02-14 14:42:34 +0100raehik1(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-02-14 14:42:54 +0100 <merijn> __monty__: cabal 3.4 is backwards compatible with all cabal files/versions and supports every GHC since 7.0
2021-02-14 14:42:59 +0100 <__monty__> merijn: I agree. I only support current and up whenever I start something.
2021-02-14 14:43:24 +0100 <maerwald> I don't believe in the concept of stackage, as I believe in rolling, but it's perfectly possible and doesn't conflict with cabal philosophy either imo
2021-02-14 14:43:25 +0100 <merijn> __monty__: Well, it can make sense to support a slightly lower cabal-version for slow moving distros
2021-02-14 14:43:46 +0100 <merijn> __monty__: But 2.0 is 4 years old, that's more than enough for distro to move to a cabal version that's at least 2.0
2021-02-14 14:44:09 +0100 <merijn> __monty__: Personally I default to 2.0/2.2 unless I specifically need some newer feature
2021-02-14 14:44:18 +0100 <maerwald> Franciman: what conflicts with cabal philosophy is mainly the cli interface and non-separation of concerns of stack
2021-02-14 14:44:24 +0100 <__monty__> I'm also on the flip side of that coin though. I'm still using a 32 bit machine and the "Nobody needs stuff *this* old, right?" reasoning is really inconvenient.
2021-02-14 14:44:42 +0100hololeap(~hololeap@unaffiliated/hololeap) (Ping timeout: 246 seconds)
2021-02-14 14:44:45 +0100 <Franciman> maerwald, FREAKING +1
2021-02-14 14:44:50 +0100 <Franciman> in fact I vehemently hate stack
2021-02-14 14:44:56 +0100 <Franciman> it hurts my health, so I stop
2021-02-14 14:45:12 +0100 <maerwald> I like stack for its file format
2021-02-14 14:45:23 +0100 <merijn> __monty__: It's not "nobody needs this" it's "why should the community bend over backwards to support niche usecases"
2021-02-14 14:45:32 +0100 <Franciman> maerwald, you mean hpack's file format?
2021-02-14 14:45:39 +0100 <maerwald> Franciman: no, I hate hpack :p
2021-02-14 14:45:40 +0100 <merijn> __monty__: Like, no offense, but it's 2021, why do you even *have* a 32 bit machine? :p
2021-02-14 14:45:46 +0100 <maerwald> Franciman: I mean stack.yaml etc
2021-02-14 14:45:46 +0100 <Franciman> lol
2021-02-14 14:45:49 +0100 <Franciman> ah ok
2021-02-14 14:45:56 +0100 <merijn> Franciman: both hpack and stack use yaml and both are terrible
2021-02-14 14:46:00 +0100 <maerwald> although pantry made it worse
2021-02-14 14:46:11 +0100 <merijn> Like, I'm willing to "live and let live" when it comes to stack
2021-02-14 14:46:11 +0100 <__monty__> merijn: Because I can't stand consumerism. I know this is self-inflicted suffering.
2021-02-14 14:46:13 +0100 <maerwald> It's a feature creep and most ppl don't even know how deep it goes
2021-02-14 14:46:15 +0100 <merijn> But hpack should go away
2021-02-14 14:46:32 +0100 <maerwald> there's a bazillion ways to write your stack.yaml
2021-02-14 14:46:36 +0100 <merijn> __monty__: I mean, is it really consumerism? I think my first 64bit machine was in, like, 2006?
2021-02-14 14:46:41 +0100Sheilong(uid293653@gateway/web/irccloud.com/x-ltinxgozprmzwqca)
2021-02-14 14:47:09 +0100 <Franciman> maerwald, honestly I think part of the issue with stack is how cabal is complicated
2021-02-14 14:47:09 +0100 <maerwald> but it's yaml and you don't need to rely on esoteric package-specific parsers
2021-02-14 14:47:14 +0100 <Franciman> I'm not saying that it could be simpler
2021-02-14 14:47:21 +0100 <merijn> __monty__: If you machine is less than a decade old it should be 64 bit, and if it's more than a decade old then I don't think it's consumerism to say "we don't support something that old"
2021-02-14 14:47:25 +0100 <Franciman> but it is complicated
2021-02-14 14:47:27 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 14:47:30 +0100 <Franciman> so ppl try their way
2021-02-14 14:47:42 +0100 <maerwald> Franciman: cabals cli interface is quite messy
2021-02-14 14:47:46 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 14:47:53 +0100 <Franciman> but I dislike that a private company pursues its agenda at the level of splitting the community and starting flames
2021-02-14 14:48:08 +0100 <Franciman> because they invest in stack, and then they don't want to lose their investment
2021-02-14 14:48:35 +0100 <maerwald> Franciman: I think it's a fair game, though. Because stack *does* provide an alternative philosophy
2021-02-14 14:48:42 +0100 <maerwald> it's more than just a cabal fork
2021-02-14 14:48:43 +0100 <Franciman> this is true
2021-02-14 14:48:57 +0100 <Franciman> but why not try to mix with cabal? instead of fighting and flaming ?
2021-02-14 14:49:06 +0100 <Franciman> it could have been done in a different way
2021-02-14 14:49:10 +0100 <__monty__> merijn: Maybe this is better suited to offtopic? Anything that still works fine and is dropped because it's "too old" is consumerism to me. Note that me not throwing it out is because of consumerism, a community deciding to stop building 32 bit binaries is totally reasonable, maybe even better for resource consumption. I only said it was *inconvenient*.
2021-02-14 14:49:15 +0100 <maerwald> Franciman: arguing about philosophy is what caused the flame war I believe
2021-02-14 14:49:20 +0100 <Franciman> oh I see
2021-02-14 14:49:33 +0100 <Franciman> well java has like 2000 build systems
2021-02-14 14:49:42 +0100 <Franciman> we should learn from java then :)
2021-02-14 14:49:46 +0100 <maerwald> like, Poettering doesn't believe in unix and the "everything is a file" principle
2021-02-14 14:49:52 +0100 <maerwald> have fun convincing him
2021-02-14 14:50:07 +0100 <Franciman> probably we had a small community and creating a fork would like splitting anything in half
2021-02-14 14:50:10 +0100 <maerwald> or you just don't and ignore him
2021-02-14 14:50:31 +0100 <Franciman> that is what philip glass says about serialist american composers
2021-02-14 14:50:42 +0100 <Franciman> you don't argue with them, you just outlive them
2021-02-14 14:50:43 +0100 <Franciman> :)
2021-02-14 14:50:58 +0100_noblegas(uid91066@gateway/web/irccloud.com/x-twmjqwcrorjsfymz) (Quit: Connection closed for inactivity)
2021-02-14 14:51:04 +0100 <__monty__> Franciman: FPComplete's reasoning was they moved too fast for Cabal maintainers to keep up so they just did their own thing.
2021-02-14 14:51:05 +0100 <maerwald> no no... you support them
2021-02-14 14:51:35 +0100 <Franciman> __monty__, I still do not understand the super different UX
2021-02-14 14:51:40 +0100 <maerwald> that's why I strive (for my projects), to support whatever tool ppl want... stack, cabal, nix (if someone writes a patch)
2021-02-14 14:51:41 +0100 <Franciman> they thought they created something more polished?
2021-02-14 14:51:44 +0100 <Franciman> spolier they did not
2021-02-14 14:51:47 +0100 <Franciman> it sucks equally
2021-02-14 14:51:52 +0100 <Franciman> plus it is different
2021-02-14 14:52:16 +0100 <ij> everything is a file is nice, if the files lived in a vfs (but what do I know)
2021-02-14 14:52:33 +0100 <Franciman> lately I have been blasted by snoyman saying that github was better because it was an UX everybody knows
2021-02-14 14:52:36 +0100 <Franciman> so it is better than gitlab
2021-02-14 14:52:43 +0100 <Franciman> and then I have to cringe any time I have to use stack
2021-02-14 14:52:48 +0100 <Franciman> because I am too used to cabal?
2021-02-14 14:53:27 +0100 <maerwald> I think tools are an emotional thing for developers too
2021-02-14 14:53:42 +0100 <maerwald> only half of the dicussions are really about tech issues :p
2021-02-14 14:53:46 +0100 <__monty__> Yeah, UX is too subjective.
2021-02-14 14:53:48 +0100hseg(~gesh@IGLD-84-228-239-97.inter.net.il) (Ping timeout: 246 seconds)
2021-02-14 14:53:50 +0100 <Franciman> but really
2021-02-14 14:53:54 +0100 <Franciman> it is a double standard at play here
2021-02-14 14:53:59 +0100 <Franciman> but it is personal ok
2021-02-14 14:54:00 +0100 <Franciman> yes
2021-02-14 14:54:02 +0100 <Franciman> subjective
2021-02-14 14:54:24 +0100 <__monty__> They probably started out thinking "Now *this* is simple/intuitive UX." Then they bolted things on and now we're here.
2021-02-14 14:54:30 +0100 <maerwald> and I'm not trying to say emotional is non-sense... no, it's pretty important for productivity too
2021-02-14 14:54:45 +0100deja(~deja@213162080090.public.t-mobile.at) (Quit: requested)
2021-02-14 14:55:04 +0100sz0(uid110435@gateway/web/irccloud.com/x-jawittjnojcejvfc)
2021-02-14 14:55:11 +0100 <Franciman> I also got to say that I am not a serious programmer, and I have difficulties understanding production problems
2021-02-14 14:55:20 +0100 <Franciman> and in fact I prefer pipes over conduit
2021-02-14 14:55:26 +0100 <Franciman> i think conduit is awful
2021-02-14 14:55:31 +0100 <__monty__> Btw, Franciman, your nick is too similar to frangipane, please tone down being delicious.
2021-02-14 14:55:32 +0100 <Franciman> pipes instead is pretty nice
2021-02-14 14:55:42 +0100deja(~deja@213162080090.public.t-mobile.at)
2021-02-14 14:55:52 +0100 <Franciman> __monty__, what? Llol
2021-02-14 14:55:53 +0100 <maerwald> I'll refrain from conduit bashing today
2021-02-14 14:55:57 +0100maerwaldsmirks at merijn
2021-02-14 14:56:21 +0100hololeap(~hololeap@unaffiliated/hololeap)
2021-02-14 14:59:02 +0100 <maerwald> Franciman: production problems are about how to not fail while your system has to swallow more crap input. Avoiding failure is an interesting approach that works pretty well for very successful companies, despit having absolute crap software
2021-02-14 15:00:08 +0100knupfer(~Thunderbi@mue-88-130-61-128.dsl.tropolys.de)
2021-02-14 15:00:34 +0100chris8142(~chris8142@srvnet-01-071.ikbnet.co.at)
2021-02-14 15:00:45 +0100 <maerwald> I guess haskellers roam in the subset of the industry, where either the founders are visionaries or the company just has insane funding, so that they can hire actual engineers
2021-02-14 15:01:24 +0100 <Franciman> true, maerwald
2021-02-14 15:04:27 +0100tlyu(~tlyu@195.140.213.38)
2021-02-14 15:05:20 +0100coot(~coot@37.30.55.141.nat.umts.dynamic.t-mobile.pl) (Quit: coot)
2021-02-14 15:08:38 +0100dhil(~dhil@80.208.56.181)
2021-02-14 15:10:48 +0100deja(~deja@213162080090.public.t-mobile.at) (Quit: requested)
2021-02-14 15:11:51 +0100deja(~deja@213162080090.public.t-mobile.at)
2021-02-14 15:13:28 +0100theDon(~td@94.134.91.232) (Quit: waking up from the american dream ...)
2021-02-14 15:14:34 +0100 <hc_> interesting hypothesis
2021-02-14 15:15:47 +0100heatsink(~heatsink@2600:1700:bef1:5e10:b101:b0cf:b14d:ce6b)
2021-02-14 15:18:11 +0100alx741(~alx741@186.178.108.225) (Quit: alx741)
2021-02-14 15:19:06 +0100 <[exa]> (invalid though)
2021-02-14 15:19:12 +0100bnbgg_(uid454564@gateway/web/irccloud.com/x-dlouokgmjjwefkhf) (Quit: Connection closed for inactivity)
2021-02-14 15:19:22 +0100 <merijn> Not that invalid, I think
2021-02-14 15:20:26 +0100heatsink(~heatsink@2600:1700:bef1:5e10:b101:b0cf:b14d:ce6b) (Ping timeout: 264 seconds)
2021-02-14 15:20:54 +0100 <[exa]> not sure if "hired for a research job" counts as industry but we did that a few times
2021-02-14 15:21:11 +0100 <[exa]> hiring a haskeller saves a lot of time and money on both sides
2021-02-14 15:22:21 +0100 <merijn> [exa]: Is your company representative of most companies which employ haskell programmers to write Haskell, though?
2021-02-14 15:22:52 +0100 <merijn> Most of them seem to be big multinationals with big budgets. Target, Facebook, several banks...
2021-02-14 15:23:21 +0100 <pineapples[m]> Facebook hires Haskell programmers?
2021-02-14 15:23:34 +0100 <__monty__> pineapples[m]: For their spam stuff Sigma or something?
2021-02-14 15:23:52 +0100jamm__(~jamm@unaffiliated/jamm) (Remote host closed the connection)
2021-02-14 15:24:07 +0100 <Franciman> I think Simon Marlowe still works there?
2021-02-14 15:24:09 +0100 <Franciman> Marlow*
2021-02-14 15:24:36 +0100jamm_(~jamm@unaffiliated/jamm)
2021-02-14 15:24:47 +0100 <pineapples[m]> Wow, I didn't know this, thanks!
2021-02-14 15:26:25 +0100 <[exa]> merijn: well no, but I guess similar institutions make a lot of demand for the programmers
2021-02-14 15:26:43 +0100 <[exa]> -> #offtopic
2021-02-14 15:26:50 +0100pavonia(~user@unaffiliated/siracusa)
2021-02-14 15:27:07 +0100new_haskeller(ae72a197@cpe00fc8d386d93-cm00fc8d386d90.cpe.net.cable.rogers.com)
2021-02-14 15:27:24 +0100 <merijn> pineapples[m]: There's a number of prominent Haskellers working their and part of their anti-spam infra is written in/uses Haskell
2021-02-14 15:29:22 +0100jamm_(~jamm@unaffiliated/jamm) (Ping timeout: 260 seconds)
2021-02-14 15:30:20 +0100jamm_(~jamm@unaffiliated/jamm)
2021-02-14 15:30:48 +0100 <new_haskeller> I am curious why the following are not equivalentPrelude> [ x * 3 | x <- [1..100], x<10]
2021-02-14 15:30:48 +0100 <new_haskeller> [3,6,9,12,15,18,21,24,27]
2021-02-14 15:30:49 +0100 <new_haskeller> Prelude> [ x * 3 | x <- [1..], x<10]
2021-02-14 15:30:49 +0100 <new_haskeller> [3,6,9,12,15,18,21,24,27
2021-02-14 15:31:29 +0100 <Franciman> new_haskeller, because haskell tries to go trhough the whole list
2021-02-14 15:31:35 +0100 <Franciman> it does not have any idea that after 10
2021-02-14 15:31:36 +0100 <xerox_> the second one is still checking the various x > 10, forever
2021-02-14 15:31:40 +0100 <Franciman> the other numbers will fail
2021-02-14 15:31:46 +0100 <ski> > filter (< 10) [1 ... 100]
2021-02-14 15:31:47 +0100 <lambdabot> error:
2021-02-14 15:31:48 +0100 <lambdabot> • Could not deduce (Plated c0)
2021-02-14 15:31:48 +0100 <lambdabot> from the context: (Ord (Over p f s t a b), Applicative f, Plated c,
2021-02-14 15:31:52 +0100 <ski> > filter (< 10) [1 .. 100]
2021-02-14 15:31:54 +0100 <ski> > filter (< 10) [1 ..]
2021-02-14 15:31:54 +0100 <lambdabot> [1,2,3,4,5,6,7,8,9]
2021-02-14 15:32:00 +0100 <lambdabot> mueval-core: Time limit exceeded
2021-02-14 15:32:17 +0100 <pineapples[m]> takeWhile might be better in this use case than filter
2021-02-14 15:32:22 +0100 <pineapples[m]> If you want to use infinite lists
2021-02-14 15:32:26 +0100 <ski> (`filter p xs' does the same as `[x | x <- xs,p x]')
2021-02-14 15:33:07 +0100Marissa(Marissa@33.anserq.com)
2021-02-14 15:33:15 +0100 <ski> it can't know that there won't be any element less than ten, later. if you want to take advantage of the list being sorted, use `takeWhile'
2021-02-14 15:33:25 +0100 <ski> > takeWhile (< 10) [1 .. 100]
2021-02-14 15:33:27 +0100 <lambdabot> [1,2,3,4,5,6,7,8,9]
2021-02-14 15:33:28 +0100 <ski> > takeWhile (< 10) [1 ..]
2021-02-14 15:33:29 +0100 <lambdabot> [1,2,3,4,5,6,7,8,9]
2021-02-14 15:33:35 +0100 <new_haskeller> makes sense now. Thanks!
2021-02-14 15:33:49 +0100 <ski> > [x * 3 | x <- takeWhile (< 10) [1 ..]]
2021-02-14 15:33:51 +0100 <lambdabot> [3,6,9,12,15,18,21,24,27]
2021-02-14 15:34:25 +0100 <new_haskeller> I thought Haskell would terminate when x >10
2021-02-14 15:34:54 +0100 <Franciman> new_haskeller, the problem is that haskell does not know anything about the predicate
2021-02-14 15:34:55 +0100 <pineapples[m]> It does terminate
2021-02-14 15:35:02 +0100 <Franciman> for haskell it is a generic predicate
2021-02-14 15:35:07 +0100 <Franciman> so it must test it all the time
2021-02-14 15:35:10 +0100 <new_haskeller> I get it.
2021-02-14 15:35:12 +0100 <pineapples[m]> All x are in the range [1..9]
2021-02-14 15:35:17 +0100 <int-e> 10 < 10 is already false
2021-02-14 15:35:18 +0100 <pineapples[m]> But the output function multiplies that by 3
2021-02-14 15:35:29 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 15:35:30 +0100Marissa(Marissa@33.anserq.com) (Client Quit)
2021-02-14 15:35:41 +0100Marissa(Marissa@33.anserq.com)
2021-02-14 15:39:10 +0100 <ski> % :set -XTransformListComp
2021-02-14 15:39:10 +0100 <yahb> ski:
2021-02-14 15:39:13 +0100 <ski> % [x | x <- [0 ..],then takeWhile by x < 10]
2021-02-14 15:39:13 +0100 <yahb> ski: [0,1,2,3,4,5,6,7,8,9]
2021-02-14 15:39:38 +0100 <ski> % [x * 3 | x <- [0 ..],then takeWhile by x < 10]
2021-02-14 15:39:38 +0100 <yahb> ski: [0,3,6,9,12,15,18,21,24,27]
2021-02-14 15:40:02 +0100frozenErebus(~frozenEre@94.128.81.133) (Ping timeout: 256 seconds)
2021-02-14 15:40:45 +0100acarrico(~acarrico@dhcp-68-142-39-249.greenmountainaccess.net) (Ping timeout: 240 seconds)
2021-02-14 15:41:17 +0100drozdziak1(~drozdziak@vps-520f86fd.vps.ovh.net) (Quit: ZNC 1.8.1 - https://znc.in)
2021-02-14 15:41:59 +0100bnbgg_(uid454564@gateway/web/irccloud.com/x-rbckpsfnteepsstm)
2021-02-14 15:44:26 +0100frozenErebus(~frozenEre@94.128.81.133)
2021-02-14 15:44:46 +0100son0p(~son0p@181.136.122.143)
2021-02-14 15:47:12 +0100viluon(uid453725@gateway/web/irccloud.com/x-phgigjwjsbgranpk)
2021-02-14 15:47:27 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 15:47:46 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 15:47:56 +0100ep1ctetus(~epictetus@ip72-194-215-136.sb.sd.cox.net)
2021-02-14 15:49:31 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 15:50:34 +0100stef204(~stef204@unaffiliated/stef-204/x-384198)
2021-02-14 15:55:47 +0100chris8142(~chris8142@srvnet-01-071.ikbnet.co.at) (Quit: WeeChat 3.0.1)
2021-02-14 15:59:14 +0100neiluj(~jco@91-167-203-101.subs.proxad.net)
2021-02-14 15:59:23 +0100a-tsioh[m](a-tsiohmat@gateway/shell/matrix.org/x-lhnuiggshvkhptok)
2021-02-14 16:02:02 +0100frozenErebusAlan_Turing
2021-02-14 16:07:15 +0100idhugo_(~idhugo@80-62-117-97-mobile.dk.customer.tdc.net) (Ping timeout: 272 seconds)
2021-02-14 16:07:27 +0100hexo(~hexo@gateway/tor-sasl/hexo) (Ping timeout: 268 seconds)
2021-02-14 16:07:27 +0100xelxebar(~xelxebar@gateway/tor-sasl/xelxebar) (Ping timeout: 268 seconds)
2021-02-14 16:08:33 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 16:08:41 +0100srk(~sorki@gateway/tor-sasl/sorki) (Ping timeout: 268 seconds)
2021-02-14 16:08:48 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 16:08:51 +0100Tario(~Tario@201.192.165.173)
2021-02-14 16:09:02 +0100xelxebar(~xelxebar@gateway/tor-sasl/xelxebar)
2021-02-14 16:09:32 +0100srk(~sorki@gateway/tor-sasl/sorki)
2021-02-14 16:09:37 +0100hexo(~hexo@gateway/tor-sasl/hexo)
2021-02-14 16:12:17 +0100geekosaur(ae68c070@cpe-174-104-192-112.neo.res.rr.com)
2021-02-14 16:15:17 +0100Franciman(~francesco@host-82-49-79-189.retail.telecomitalia.it) (Quit: Leaving)
2021-02-14 16:15:42 +0100hololeap(~hololeap@unaffiliated/hololeap) (Ping timeout: 246 seconds)
2021-02-14 16:16:30 +0100heatsink(~heatsink@2600:1700:bef1:5e10:b101:b0cf:b14d:ce6b)
2021-02-14 16:16:41 +0100 <xsperry> then takes a function that takes a predicate, and a predicate?
2021-02-14 16:16:43 +0100hololeap(~hololeap@unaffiliated/hololeap)
2021-02-14 16:17:48 +0100jonathanx(~jonathan@h-176-109.A357.priv.bahnhof.se) (Remote host closed the connection)
2021-02-14 16:21:36 +0100ClaudiusMaximus(~claude@191.123.199.146.dyn.plus.net)
2021-02-14 16:21:36 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se)
2021-02-14 16:21:36 +0100ClaudiusMaximus(~claude@191.123.199.146.dyn.plus.net) (Changing host)
2021-02-14 16:21:36 +0100ClaudiusMaximus(~claude@unaffiliated/claudiusmaximus)
2021-02-14 16:21:38 +0100heatsink(~heatsink@2600:1700:bef1:5e10:b101:b0cf:b14d:ce6b) (Ping timeout: 264 seconds)
2021-02-14 16:21:56 +0100urodna(~urodna@unaffiliated/urodna)
2021-02-14 16:22:46 +0100catalin(~catalin@82.77.237.51)
2021-02-14 16:23:13 +0100catalin(~catalin@82.77.237.51) (Client Quit)
2021-02-14 16:23:19 +0100jmsx(~jordan@li1158-85.members.linode.com) (Quit: bye o/)
2021-02-14 16:28:31 +0100 <edwardk> what version of ghc did explicit bidirectional pattern synonyms become usable with the current signature format, again?
2021-02-14 16:28:54 +0100 <edwardk> basically trying to figure out how recently i'd have to cut off to adopt them
2021-02-14 16:29:36 +0100RusAlex(~Chel@unaffiliated/rusalex) (Quit: WeeChat 2.7.1)
2021-02-14 16:30:36 +0100 <merijn> edwardk: GHC user guide claims pattern synonyms are in since 7.8, but I think bidirectionaly patterns weren't completely working until 8.0?
2021-02-14 16:31:20 +0100 <edwardk> that sounds about right, given we're moving into 9 i'm thinking about doing a mass drop of things below 8 across my whole ecosystem and seeing what cleanups i could get
2021-02-14 16:31:22 +0100 <geekosaur> my track record with these kind of questions is poor but I want to say there were lingering issues until 8.2
2021-02-14 16:31:50 +0100 <geekosaur> but that may have been interactions with checking exhaustiveness
2021-02-14 16:33:10 +0100 <edwardk> i remember the type signature flipping around
2021-02-14 16:33:18 +0100 <edwardk> not sure what version that was in
2021-02-14 16:34:45 +0100ephemera_(~E@122.34.1.187) (Ping timeout: 264 seconds)
2021-02-14 16:35:26 +0100 <edwardk> 8 seems to be where signatures came along in modern style, and allowed bundling synonyms
2021-02-14 16:37:39 +0100star_cloud(~star_clou@ec2-34-220-44-120.us-west-2.compute.amazonaws.com)
2021-02-14 16:38:37 +0100rdivyanshu(uid322626@gateway/web/irccloud.com/x-pkahdvkefnsdjqce) (Quit: Connection closed for inactivity)
2021-02-14 16:40:39 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 16:40:54 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed)
2021-02-14 16:41:15 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 16:41:44 +0100ephemera_(~E@122.34.1.187)
2021-02-14 16:41:59 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 16:42:15 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 16:44:44 +0100kenran(~kenran@i59F67B96.versanet.de)
2021-02-14 16:44:50 +0100sagax(~sagax_nb@213.138.71.146)
2021-02-14 16:45:53 +0100cole-h(~cole-h@c-73-48-197-220.hsd1.ca.comcast.net)
2021-02-14 16:46:09 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Ping timeout: 264 seconds)
2021-02-14 16:47:25 +0100Alan_Turing(~frozenEre@94.128.81.133) (Ping timeout: 256 seconds)
2021-02-14 16:47:27 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 16:47:35 +0100 <pineapples[m]> When did the typeclass `Num` stop having `class (Eq a) => Num a` as a class constraint? Going through LYAH right now, but it seems that Eq must have been a constraint on Num when the book was written
2021-02-14 16:47:46 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 16:48:59 +0100 <dolio> A long time ago.
2021-02-14 16:49:25 +0100 <geekosaur> sometime early in the ghc8 series
2021-02-14 16:49:46 +0100 <geekosaur> I think the standard still specifies Num and Show constraints
2021-02-14 16:50:34 +0100karasu1[m](karasu1mat@gateway/shell/matrix.org/x-dxpaeclqknizkxjp)
2021-02-14 16:50:36 +0100 <edwardk> pineapples[m]: it was back in the 7.4 era i think when igloo started breaking compatibility with haskell 98
2021-02-14 16:50:46 +0100 <edwardk> geekosaur: its way older than that
2021-02-14 16:50:54 +0100 <merijn> geekosaur: Naah, way older
2021-02-14 16:51:01 +0100 <merijn> geekosaur: Like, early 7.x
2021-02-14 16:51:03 +0100 <edwardk> its literally the first breaking change to the standard we consciously made
2021-02-14 16:51:21 +0100 <edwardk> and only one to the Prelude for a looong time
2021-02-14 16:51:38 +0100 <dolio> Yeah, it's already gone in 7.4.
2021-02-14 16:51:39 +0100 <merijn> pineapples[m]: The Haskell Report requires Show and Eq as superclass of Num, but it's a documented deviation in GHC
2021-02-14 16:51:45 +0100 <merijn> Actually
2021-02-14 16:51:52 +0100 <merijn> Possibly in 6.x already
2021-02-14 16:52:10 +0100 <merijn> It was already gone when I started learning Haskell and that'd be late 6.x, early 7.x
2021-02-14 16:52:39 +0100 <dolio> No, edwardk actually nailed it somehow.
2021-02-14 16:52:52 +0100 <dolio> 7.2.1 still has Eq and Show.
2021-02-14 16:52:53 +0100 <merijn> pineapples[m]: See also: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/bugs.html
2021-02-14 16:52:55 +0100 <edwardk> 7.4 was peak igloo
2021-02-14 16:53:03 +0100 <edwardk> thats how i remembered =)
2021-02-14 16:53:20 +0100caef^(caef@ip98-184-89-2.mc.at.cox.net) ()
2021-02-14 16:53:21 +0100ph88(~ph88@2a02:8109:9e00:7e5c:a5e6:eed6:171f:46a3)
2021-02-14 16:54:32 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 16:56:49 +0100RusAlex(~Chel@unaffiliated/rusalex)
2021-02-14 16:57:00 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 16:58:09 +0100jamm_(~jamm@unaffiliated/jamm) (Remote host closed the connection)
2021-02-14 16:58:24 +0100elfets(~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de)
2021-02-14 16:58:45 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 17:00:03 +0100fendor_fendor
2021-02-14 17:00:05 +0100Hatsue[m](berbermanm@gateway/shell/matrix.org/x-ofhjghikpvbiahie) (Quit: Idle for 30+ days)
2021-02-14 17:05:33 +0100new_haskeller(ae72a197@cpe00fc8d386d93-cm00fc8d386d90.cpe.net.cable.rogers.com) (Quit: Ping timeout (120 seconds))
2021-02-14 17:06:15 +0100theDon(~td@94.134.91.34)
2021-02-14 17:08:15 +0100Tario(~Tario@201.192.165.173) (Read error: Connection reset by peer)
2021-02-14 17:09:15 +0100Tario(~Tario@201.192.165.173)
2021-02-14 17:09:39 +0100nrh^(nrh@ip98-184-89-2.mc.at.cox.net)
2021-02-14 17:11:38 +0100__minoru__shirae(~shiraeesh@109.166.57.144)
2021-02-14 17:11:44 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se) (Remote host closed the connection)
2021-02-14 17:11:58 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se)
2021-02-14 17:12:12 +0100Franciman(~francesco@host-82-49-79-189.retail.telecomitalia.it)
2021-02-14 17:14:01 +0100danvet(~Daniel@2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa)
2021-02-14 17:15:31 +0100kroww(~kroww@196.240.57.156)
2021-02-14 17:16:36 +0100jamm_(~jamm@unaffiliated/jamm)
2021-02-14 17:16:40 +0100MidAutumnHotaru(~MidAutumn@unaffiliated/midautumnhotaru) (Quit: Quit 啾)
2021-02-14 17:16:58 +0100MidAutumnHotaru(~MidAutumn@unaffiliated/midautumnhotaru)
2021-02-14 17:20:00 +0100Rudd0(~Rudd0@185.189.115.108)
2021-02-14 17:20:51 +0100MidAutumnHotaru(~MidAutumn@unaffiliated/midautumnhotaru) (Client Quit)
2021-02-14 17:21:31 +0100MidAutumnHotaru(~MidAutumn@unaffiliated/midautumnhotaru)
2021-02-14 17:22:56 +0100greymalkin(~greymalki@199.180.249.79) (Ping timeout: 240 seconds)
2021-02-14 17:23:35 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 17:25:46 +0100kroww(~kroww@196.240.57.156) (Quit: Leaving)
2021-02-14 17:25:51 +0100_ashbreeze_(~mark@64.85.214.234.reverse.socket.net) (Remote host closed the connection)
2021-02-14 17:26:31 +0100 <karasu1[m]> What is the difference between `fromInteger` and `fromIntegral`, and when would you use one or the other? It seems that in the class declaration of Num, only `fromInteger` is defined, but `fromIntegral` is one of the "Numeric Functions" in Prelude (I am new to Haskell so I don't know what the "Numeric Functions" are supposed to mean, but that's what Hoogle is saying). Is this oddity for historical reasons?
2021-02-14 17:26:56 +0100 <merijn> :t fromIntegral
2021-02-14 17:26:57 +0100 <lambdabot> (Integral a, Num b) => a -> b
2021-02-14 17:27:00 +0100 <merijn> :t fromInteger
2021-02-14 17:27:01 +0100 <lambdabot> Num a => Integer -> a
2021-02-14 17:27:12 +0100son0p(~son0p@181.136.122.143) (Quit: Lost terminal)
2021-02-14 17:27:18 +0100_ashbreeze_(~mark@64.85.214.234.reverse.socket.net)
2021-02-14 17:27:39 +0100 <merijn> karasu1[m]: fromInteger is part of the Num class and specifies how (integer) literals in the source are converted into a specific value
2021-02-14 17:27:49 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 17:27:50 +0100toorevitimirp(~tooreviti@117.182.183.159)
2021-02-14 17:27:56 +0100 <merijn> karasu1[m]: fromIntegral allows you to convert any type that is Integral to another numeric type
2021-02-14 17:28:07 +0100 <karasu1[m]> Hmm, I'm not sure I totally understand the difference. So `Integral` is an algebraic data type with a type constraint `a`, but Integer is a concrete type I guess?
2021-02-14 17:28:17 +0100 <merijn> karasu1[m]: No
2021-02-14 17:28:34 +0100 <merijn> karasu1[m]: Integral is a typeclass (specifically for stuff that behaves lik an integer)
2021-02-14 17:29:35 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 272 seconds)
2021-02-14 17:29:42 +0100 <merijn> "Integral a => a -> ..." says that the function works for any type that is an instance of the Integral typeclass.
2021-02-14 17:30:43 +0100 <merijn> karasu1[m]: I'm not sure the term "type constraint" makes a lot of sense. The stuff in front of => in a type signature is a constraint (which you can think of as something like a compile time precondition)
2021-02-14 17:30:51 +0100machinedgod(~machinedg@135-23-192-217.cpe.pppoe.ca)
2021-02-14 17:32:52 +0100 <karasu1[m]> I was thinking that both `fromIntegral` and `fromInteger` would convert Integrals (in the case of `fromIntegral`) and Integers (in the case of `fromInteger`) to the generic `Num` type.... Is this the wrong way of looking at it then? Num, Integral, and Integer are all typeclasses right?
2021-02-14 17:33:22 +0100Alan_Turing(~frozenEre@94.128.81.133)
2021-02-14 17:33:49 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 17:33:52 +0100 <xsperry> Integer is a type
2021-02-14 17:34:04 +0100 <merijn> karasu1[m]: No
2021-02-14 17:34:13 +0100 <merijn> karasu1[m]: Num and Integral are type classes
2021-02-14 17:34:20 +0100 <merijn> Integer is not
2021-02-14 17:34:26 +0100 <merijn> > 500 :: Integer
2021-02-14 17:34:27 +0100 <lambdabot> 500
2021-02-14 17:34:33 +0100 <merijn> :t 500
2021-02-14 17:34:34 +0100 <lambdabot> Num p => p
2021-02-14 17:34:50 +0100 <xsperry> Integer is a type with Integral instance
2021-02-14 17:35:12 +0100 <merijn> Literals are polymorphic, so that is saying that the literal has type "Num p => p" i.e. this can be any type if (and only if) that type is also an instance of Num
2021-02-14 17:35:21 +0100 <merijn> :t (500 :: Integer)
2021-02-14 17:35:22 +0100 <lambdabot> Integer
2021-02-14 17:35:38 +0100machinedgod(~machinedg@135-23-192-217.cpe.pppoe.ca) (Client Quit)
2021-02-14 17:36:00 +0100machinedgod(~machinedg@135-23-192-217.cpe.pppoe.ca)
2021-02-14 17:36:19 +0100machinedgod(~machinedg@135-23-192-217.cpe.pppoe.ca) (Client Quit)
2021-02-14 17:37:31 +0100jamm_(~jamm@unaffiliated/jamm) (Remote host closed the connection)
2021-02-14 17:37:45 +0100machinedgod(~machinedg@135-23-192-217.cpe.pppoe.ca)
2021-02-14 17:38:59 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 17:38:59 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se) (Ping timeout: 256 seconds)
2021-02-14 17:39:02 +0100Noldorin(~noldorin@unaffiliated/noldorin)
2021-02-14 17:39:05 +0100 <karasu1[m]> Do you have examples on when to use `fromIntegral` vs `fromInteger`? I'm still not sure I understand :(. `negate $ fromIntegral 1` and `negate $ fromInteger 1` seem to be doing exactly the same thing....
2021-02-14 17:40:19 +0100 <geekosaur> > fromInteger (length "abc")
2021-02-14 17:40:21 +0100 <lambdabot> error:
2021-02-14 17:40:21 +0100 <lambdabot> • Couldn't match expected type ‘Integer’ with actual type ‘Int’
2021-02-14 17:40:21 +0100 <lambdabot> • In the first argument of ‘fromInteger’, namely ‘(length "abc")’
2021-02-14 17:40:28 +0100 <geekosaur> > fromIntegral (length "abc")
2021-02-14 17:40:30 +0100 <lambdabot> 3
2021-02-14 17:40:42 +0100 <merijn> karasu1[m]: Integer is an instance of Integral, so you can use fromIntegral for everything
2021-02-14 17:40:54 +0100 <merijn> karasu1[m]: The reason fromInteger exists is far more specific
2021-02-14 17:40:55 +0100conal(~conal@64.71.133.70)
2021-02-14 17:41:20 +0100 <merijn> karasu1[m]: Literals are polymorphic, so how can the compiler turn an arbitrary literal into a value of a specific type?
2021-02-14 17:41:25 +0100 <geekosaur> it'll look like it's unnecessary a lot of the time because of defaulting which means if you don't use something that specifies otherwise, it'll default to Integer
2021-02-14 17:41:41 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se)
2021-02-14 17:41:50 +0100 <merijn> Integer is an unbounded integer type, so we can convert any integer literal into an Integer safely
2021-02-14 17:42:04 +0100 <merijn> karasu1[m]: then use fromInteger to produce the actual type we want
2021-02-14 17:42:16 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 17:42:35 +0100 <merijn> karasu1[m]: writing "500" in your code is, effectively, like writing "fromInteger 500". That's why fromInteger exists.
2021-02-14 17:42:36 +0100 <geekosaur> and one specific reason for fromInteger is that a numeric literal is compiled as an Integer and fromInteger applied to it to get (Num a => a), since the compiler has to pick some type for literals in order to compile them
2021-02-14 17:42:46 +0100 <merijn> geekosaur: hah, too slow :p
2021-02-14 17:42:58 +0100 <geekosaur> yeh, me and my verbose mouth :)
2021-02-14 17:44:11 +0100 <maerwald> merijn: considering literals... haskell is dynamically typed :p
2021-02-14 17:45:11 +0100raym(~ray@45.64.220.98) (Quit: leaving)
2021-02-14 17:46:05 +0100cole-h(~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 17:46:17 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed)
2021-02-14 17:46:25 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se) (Ping timeout: 240 seconds)
2021-02-14 17:46:39 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 17:46:58 +0100hseg(~gesh@IGLD-84-228-239-97.inter.net.il)
2021-02-14 17:47:14 +0100 <Igloo> edwardk: I always wondered how history would remember me. Now I know: The guy who broke compatibility with H98 :-)
2021-02-14 17:47:22 +0100 <edwardk> yup
2021-02-14 17:47:27 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 17:47:43 +0100 <edwardk> you cracked open the dam and made room for me
2021-02-14 17:47:46 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 17:48:34 +0100 <karasu1[m]> <geekosaur "and one specific reason for from"> Wait.... but why would the compiler want to do that? `fromInteger` converts things to a generic `Num a` type right? Wouldn't it be be better to keep it as an `Integer` or `Int` type rather than converting it to `Num a`?
2021-02-14 17:48:55 +0100 <merijn> karasu1[m]: There is no "generic" num type
2021-02-14 17:49:10 +0100 <merijn> karasu1[m]: It converts to a *specific* type that happens to be an instance of the Num class
2021-02-14 17:49:37 +0100 <merijn> karasu1[m]: Well, what if you want:
2021-02-14 17:49:41 +0100 <merijn> > 500 :: Double
2021-02-14 17:49:43 +0100 <lambdabot> 500.0
2021-02-14 17:50:11 +0100 <merijn> karasu1[m]: The reason you can use 500 as a Double is that Double is an instance of Num and literals are converted to *any* instance of Num you want
2021-02-14 17:50:32 +0100boxscape(4ff0baf3@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.243)
2021-02-14 17:50:43 +0100 <karasu1[m]> Ah, so Integral and Num are completely unrelated typeclasses? I thought there might have been constraints and things going on such that `Integral` is constrained to be a `Num`, but the only constraints seem to be `Real` and `Enum`
2021-02-14 17:51:06 +0100 <boxscape> cursed unicode https://i.imgur.com/hepukXI.png
2021-02-14 17:51:28 +0100 <merijn> karasu1[m]: Yes
2021-02-14 17:51:28 +0100 <geekosaur> Real has the constraint Num
2021-02-14 17:51:39 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 17:51:45 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Ping timeout: 272 seconds)
2021-02-14 17:52:03 +0100 <merijn> karasu1[m]: All Integral instances *must* be Num instances, but no all Num instance are Integral instance (like Double)
2021-02-14 17:52:38 +0100 <tomsmeding> boxscape: what obscure symbol is that "3"
2021-02-14 17:52:49 +0100 <boxscape> tomsmeding erm let me check
2021-02-14 17:53:06 +0100 <tomsmeding> because it's not a 3 :p
2021-02-14 17:53:13 +0100 <boxscape> tomsmeding YI RADICAL VEP ꒱
2021-02-14 17:53:35 +0100tomsmeding's font doesn't have that
2021-02-14 17:53:42 +0100 <boxscape> :(
2021-02-14 17:53:58 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se)
2021-02-14 17:54:46 +0100 <geekosaur> I'm reminded of that hack with the not-a-semicolon
2021-02-14 17:54:53 +0100 <geekosaur> (someone's question mark iirc)
2021-02-14 17:55:07 +0100 <pera> Does anyone knows the minimum memory requirements to compile Pandoc nowadays? 8GB of RAM is not enough for GHC anymore unfortunately... I was wondering if 16GB could do it, otherwise I will need to buy a new laptop :/
2021-02-14 17:55:13 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-02-14 17:56:26 +0100 <koz_> pera: 16 should be enough.
2021-02-14 17:56:30 +0100knupfer(~Thunderbi@mue-88-130-61-128.dsl.tropolys.de) (Ping timeout: 246 seconds)
2021-02-14 17:57:13 +0100xsperry(~as@unaffiliated/xsperry) ()
2021-02-14 17:57:16 +0100 <pera> cool, gonna buy a new module then :)
2021-02-14 17:58:38 +0100 <tomsmeding> geekosaur: the Greek question mark, indeed, or this fabulous one https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/
2021-02-14 17:58:52 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 18:00:09 +0100bnbgg_(uid454564@gateway/web/irccloud.com/x-rbckpsfnteepsstm) (Quit: Connection closed for inactivity)
2021-02-14 18:00:35 +0100rajivr(uid269651@gateway/web/irccloud.com/x-pdqpqnvxjwncrovd) (Quit: Connection closed for inactivity)
2021-02-14 18:01:52 +0100 <karasu1[m]> <geekosaur "and one specific reason for from"> When the typer (the thing that gives literals types, don't know the formal name for this), looks at numeric literal, it says: this seems like an `Integer`, but we should convert it to a `Num`. But to me that makes no sense, since as I realized, `Integer` already is an instance of `Num`.....
2021-02-14 18:02:22 +0100 <geekosaur> there is no "conversion" going on at that point
2021-02-14 18:02:33 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 18:02:41 +0100 <geekosaur> Num is not a thing you convert to, it is a constraint
2021-02-14 18:02:55 +0100 <karasu1[m]> But didn't you say `fromInteger` is applied to convert it to a `Num`, or am I misunderstanding still?
2021-02-14 18:03:13 +0100 <geekosaur> :t fromInteger
2021-02-14 18:03:14 +0100 <lambdabot> Num a => Integer -> a
2021-02-14 18:03:20 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se) (Remote host closed the connection)
2021-02-14 18:03:38 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se)
2021-02-14 18:03:59 +0100 <geekosaur> in practice, fromInteger takes two parameters: an Integer, and a record of functions specifying the Num "interface" for some type
2021-02-14 18:04:16 +0100 <geekosaur> sorry, not specifying but implemnting
2021-02-14 18:05:12 +0100 <geekosaur> fromInteger then invokes the appropriate interface function to produce a value of that type from the Integer
2021-02-14 18:05:13 +0100 <karasu1[m]> What would happen if `fromInteger` was not applied though? `Integer` already is an instance of `Num` so I don't see why we need to convert it back.... :(
2021-02-14 18:05:29 +0100 <geekosaur> Num is not a type, there are no values of "type" Num
2021-02-14 18:05:33 +0100 <maerwald> pera: 32gb work well
2021-02-14 18:06:34 +0100 <pera> maerwald: my thinkpad can't go that high though :p
2021-02-14 18:06:46 +0100 <maerwald> yeah, I had to buy thinkpad X1 extreme
2021-02-14 18:07:13 +0100 <maerwald> and then linux support is still awful... but the alternative is mac with soldered non-upgradable ram
2021-02-14 18:07:17 +0100 <geekosaur> a constraint like Num means the function must be given proof that some type obeys the constraint. with GHC specifically, this proof is an implementation
2021-02-14 18:07:37 +0100 <MarcelineVQ> I'd try closing my browser and building with -j1 before buying a new pc
2021-02-14 18:07:48 +0100 <karasu1[m]> <geekosaur "Num is not a type, there are no "> Right. Is this a better question: Why do we need to convert numeric literals to some type `a`, where `a` is an instance of the `Num` typeclass, when the compiler has already interpreted `a` as `Integer` (but `Integer` already has an instance of the `Num` typeclass)
2021-02-14 18:08:22 +0100boxscape(4ff0baf3@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.243) (Quit: Connection closed)
2021-02-14 18:08:33 +0100 <geekosaur> because you don't want to have to jump through extra hoops to use a bare `500` as, say, a Double instead of an Integer
2021-02-14 18:08:52 +0100hexo(~hexo@gateway/tor-sasl/hexo) (Remote host closed the connection)
2021-02-14 18:08:52 +0100srk(~sorki@gateway/tor-sasl/sorki) (Remote host closed the connection)
2021-02-14 18:09:10 +0100srk(~sorki@gateway/tor-sasl/sorki)
2021-02-14 18:09:10 +0100hexo(~hexo@gateway/tor-sasl/hexo)
2021-02-14 18:09:17 +0100 <pera> MarcelineVQ: yeah I'm using -j1 now, and my system is under 2gb without ghc
2021-02-14 18:09:31 +0100berberman_(~berberman@unaffiliated/berberman)
2021-02-14 18:09:56 +0100 <tromp> is there a Haskell library offering Int256 or Word256 ?
2021-02-14 18:10:22 +0100berberman(~berberman@unaffiliated/berberman) (Ping timeout: 260 seconds)
2021-02-14 18:10:28 +0100 <geekosaur> the whole point of the numeric typeclass hierarchy is to try to make numbers behave somewhat like they do with C's auto-promotion, instead of having to always be explicit about all your numeric types
2021-02-14 18:10:43 +0100 <tromp> oh, there is https://hackage.haskell.org/package/basement-0.0.11/docs/Basement-Types-Word256.html
2021-02-14 18:10:45 +0100 <Franciman> https://hackage.haskell.org/package/accelerate-bignum-0.2.0.0/docs/Data-Array-Accelerate-Data-BigI…
2021-02-14 18:10:45 +0100Alan_Turing(~frozenEre@94.128.81.133) (Ping timeout: 240 seconds)
2021-02-14 18:10:46 +0100 <Franciman> like thiz?
2021-02-14 18:10:54 +0100 <geekosaur> in particular:
2021-02-14 18:10:58 +0100 <geekosaur> :t (^)
2021-02-14 18:10:59 +0100 <lambdabot> (Integral b, Num a) => a -> b -> a
2021-02-14 18:11:09 +0100 <karasu1[m]> geekosaur: You said that `Num` is not a type, but a typeclass, which makes sense. But when I do `:t 500`, I see `500 :: Num p => p`. So, it seems the GHCi has typed the numeric literal 500 as the "type" `Num p => p`. So is it then fine to say that `Num p => p` is a type (although `Num` is not)?
2021-02-14 18:11:17 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se) (Ping timeout: 256 seconds)
2021-02-14 18:11:32 +0100 <geekosaur> there is no way to infer a type for b, so we have defaulting and typeclass relationships to make things Just Work most of the time
2021-02-14 18:11:39 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 18:12:30 +0100 <geekosaur> yes. it says "given proof that some type p has a Num instance, this value can have the type p"
2021-02-14 18:13:14 +0100 <geekosaur> the proof is usually inferred, but sometimes has to be manually specified by providing an explicit type
2021-02-14 18:13:59 +0100 <Uniaika> Is there anyone here who has been roaming the Haskell wiki for quite some time now?
2021-02-14 18:14:15 +0100 <Uniaika> I need someone experienced with it to review a list of changes to pages of the wiki
2021-02-14 18:14:49 +0100 <geekosaur> when nothing else works, it'll try defaulting, which is a possibly empty list of types to attempt if everything else fails; the first that allows an expression to typecheck will be used. the defalt list is Integer and Double in that order
2021-02-14 18:14:57 +0100mnrmnaugh(~mnrmnaugh@unaffiliated/mnrmnaugh) (Ping timeout: 264 seconds)
2021-02-14 18:15:41 +0100 <geekosaur> all of this so numbers aren't an explicitly typed pain in the *ss to use
2021-02-14 18:16:37 +0100heatsink(~heatsink@2600:1700:bef1:5e10:b101:b0cf:b14d:ce6b)
2021-02-14 18:17:56 +0100 <karasu1[m]> How does GHCi generate the list of types for defaulting?
2021-02-14 18:18:47 +0100 <karasu1[m]> I think I get most of this stuff now though, so thanks a lot lol
2021-02-14 18:18:58 +0100 <geekosaur> the language specification says the "default default" is (Integer, Double)
2021-02-14 18:19:44 +0100 <karasu1[m]> OK! thanks!
2021-02-14 18:19:49 +0100 <geekosaur> with ExtendedDefaultRules a few more are added, so that lists behave sensibly in the face of the Foldable typeclass which has similar issues
2021-02-14 18:19:54 +0100 <geekosaur> :t length
2021-02-14 18:19:55 +0100 <lambdabot> Foldable t => t a -> Int
2021-02-14 18:20:30 +0100jonathanx(~jonathan@h-176-109.A357.priv.bahnhof.se)
2021-02-14 18:20:39 +0100 <geekosaur> so with ExtendedDefaultRules if length can't figure out what instance to use, it'll use the Foldable instance for lists which is usually what you want
2021-02-14 18:21:56 +0100 <geekosaur> and there's a similar extension which extends defaulting and type inference to strings since there are two string-like types and some quasi-string-like types
2021-02-14 18:23:53 +0100nullniverse(~null@unaffiliated/nullniverse)
2021-02-14 18:23:57 +0100xff0x(~xff0x@2001:1a81:52f8:8e00:3f0c:a02c:d901:27bc) (Ping timeout: 272 seconds)
2021-02-14 18:24:26 +0100xff0x(xff0x@gateway/vpn/mullvad/xff0x)
2021-02-14 18:26:01 +0100mnrmnaugh(~mnrmnaugh@unaffiliated/mnrmnaugh)
2021-02-14 18:28:20 +0100gioyik(~gioyik@gateway/tor-sasl/gioyik)
2021-02-14 18:28:54 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 256 seconds)
2021-02-14 18:30:33 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 18:31:41 +0100tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net)
2021-02-14 18:32:00 +0100xff0x(xff0x@gateway/vpn/mullvad/xff0x) (Ping timeout: 265 seconds)
2021-02-14 18:32:52 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds)
2021-02-14 18:32:56 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se)
2021-02-14 18:33:38 +0100xff0x(~xff0x@2001:1a81:52f8:8e00:23fc:8648:28c:c2cd)
2021-02-14 18:33:45 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 18:33:46 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 18:35:40 +0100alx741(~alx741@186.178.108.225)
2021-02-14 18:36:03 +0100vicfred(~vicfred@unaffiliated/vicfred)
2021-02-14 18:36:33 +0100neiluj(~jco@91-167-203-101.subs.proxad.net) (Remote host closed the connection)
2021-02-14 18:36:57 +0100ep1ctetus(~epictetus@ip72-194-215-136.sb.sd.cox.net) (Read error: Connection reset by peer)
2021-02-14 18:37:16 +0100toorevitimirp(~tooreviti@117.182.183.159) (Remote host closed the connection)
2021-02-14 18:38:56 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2021-02-14 18:39:34 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 18:40:36 +0100stef204(~stef204@unaffiliated/stef-204/x-384198) (Ping timeout: 240 seconds)
2021-02-14 18:42:16 +0100ep1ctetus(~epictetus@ip72-194-215-136.sb.sd.cox.net)
2021-02-14 18:42:58 +0100ep1ctetus(~epictetus@ip72-194-215-136.sb.sd.cox.net) (Read error: Connection reset by peer)
2021-02-14 18:43:01 +0100ClaudiusMaximus(~claude@unaffiliated/claudiusmaximus) (Quit: ->)
2021-02-14 18:43:03 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 18:43:44 +0100nullniv38(~null@unaffiliated/nullniverse)
2021-02-14 18:44:44 +0100 <Squarism> Im curious if its possible to rewrite these 2 functions to use the same case expression ? https://wtools.io/paste-code/b3AT
2021-02-14 18:44:57 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 272 seconds)
2021-02-14 18:45:23 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 18:45:55 +0100 <Squarism> Or would it require the proxy type be exactly the same as the value type ( the variants of "Form_X" )
2021-02-14 18:46:24 +0100stef204(~stef204@unaffiliated/stef-204/x-384198)
2021-02-14 18:46:52 +0100 <geekosaur> at a guess, it's possible but would be a huge mistake
2021-02-14 18:47:10 +0100 <Squarism> oh ok?
2021-02-14 18:47:16 +0100 <Squarism> Why?
2021-02-14 18:47:21 +0100nullniverse(~null@unaffiliated/nullniverse) (Ping timeout: 264 seconds)
2021-02-14 18:47:27 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 18:47:36 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 18:47:46 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 18:48:40 +0100 <geekosaur> I'd expect it to be possible with lots of complicated type machinery that would be a massive pain to understand much less maintain
2021-02-14 18:49:21 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr)
2021-02-14 18:49:53 +0100 <geekosaur> starting with a type family to paper over the difference between the proxy and value types
2021-02-14 18:50:25 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2021-02-14 18:51:28 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 18:52:18 +0100kenran(~kenran@i59F67B96.versanet.de) (Quit: leaving)
2021-02-14 18:54:05 +0100 <Squarism> geekosaur, the number of versions will increase so I thought it would be nice to limit the number of place needed changing when adding versions.
2021-02-14 18:54:27 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se) (Ping timeout: 272 seconds)
2021-02-14 18:55:17 +0100jmsx(~jordan@li1158-85.members.linode.com)
2021-02-14 18:55:25 +0100 <geekosaur> best I can think of is to drop the default clause and use the pattern exhaustiveness checker to highlight such spots
2021-02-14 18:56:18 +0100 <geekosaur> the other alternative is a record of variants, but that'll be a pain too (but at least colllects them all into one place)
2021-02-14 18:56:36 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2021-02-14 18:56:58 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 18:57:31 +0100ph88(~ph88@2a02:8109:9e00:7e5c:a5e6:eed6:171f:46a3) (Ping timeout: 272 seconds)
2021-02-14 18:58:48 +0100Alan_Turing(~frozenEre@94.128.81.133)
2021-02-14 18:58:56 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 18:59:05 +0100hnOsmium0001(uid453710@gateway/web/irccloud.com/x-kpbpuzyuhnpbsdju)
2021-02-14 18:59:07 +0100Jd007(~Jd007@162.156.11.151)
2021-02-14 18:59:19 +0100 <Squarism> You mean record of variants in signatures. like VersionDispatch { call :: .., proxyCall :: ... } ? Yeah, maybe ill just leave it for now,
2021-02-14 18:59:42 +0100nullniv38(~null@unaffiliated/nullniverse) (Read error: No route to host)
2021-02-14 18:59:54 +0100 <geekosaur> yes
2021-02-14 19:00:32 +0100 <geekosaur> there are no good answers to this kind of problem, only different tradeoffs
2021-02-14 19:02:02 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection)
2021-02-14 19:02:18 +0100Alan_Turing(~frozenEre@94.128.81.133) (Client Quit)
2021-02-14 19:02:20 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds)
2021-02-14 19:02:36 +0100frozenErebus(~frozenEre@94.128.81.133)
2021-02-14 19:02:37 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-02-14 19:03:05 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 19:04:45 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 246 seconds)
2021-02-14 19:05:09 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 19:05:39 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 19:05:48 +0100_ashbreeze_(~mark@64.85.214.234.reverse.socket.net) (Remote host closed the connection)
2021-02-14 19:06:28 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se)
2021-02-14 19:07:33 +0100dyeplexer(~lol@unaffiliated/terpin) (Ping timeout: 246 seconds)
2021-02-14 19:08:15 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection)
2021-02-14 19:08:30 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-02-14 19:08:44 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds)
2021-02-14 19:08:52 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 19:09:02 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed)
2021-02-14 19:09:23 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 19:09:35 +0100coot(~coot@37.30.54.17.nat.umts.dynamic.t-mobile.pl)
2021-02-14 19:10:13 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 256 seconds)
2021-02-14 19:13:10 +0100ptrcmd(~ptrcmd@unaffiliated/petercommand) (Quit: Lost terminal)
2021-02-14 19:13:51 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds)
2021-02-14 19:14:41 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 19:14:45 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 19:14:52 +0100jmo`(~user@h-162-127.A785.priv.bahnhof.se) (Remote host closed the connection)
2021-02-14 19:16:09 +0100ptrcmd(~ptrcmd@unaffiliated/petercommand)
2021-02-14 19:17:25 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 19:20:06 +0100idhugo_(~idhugo@80-62-117-97-mobile.dk.customer.tdc.net)
2021-02-14 19:20:10 +0100boxscape(4ff0baf3@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.243)
2021-02-14 19:20:13 +0100bnbgg_(uid454564@gateway/web/irccloud.com/x-kgcnnasbwqjrcwxm)
2021-02-14 19:22:05 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 19:22:28 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 19:27:01 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed)
2021-02-14 19:27:16 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 19:27:22 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 19:33:56 +0100Sgeo(~Sgeo@ool-18b98aa4.dyn.optonline.net)
2021-02-14 19:34:31 +0100bitmagie(~Thunderbi@200116b80679950091d656c272596245.dip.versatel-1u1.de)
2021-02-14 19:35:10 +0100Jd007(~Jd007@162.156.11.151) (Quit: Jd007)
2021-02-14 19:35:14 +0100coot(~coot@37.30.54.17.nat.umts.dynamic.t-mobile.pl) (Quit: coot)
2021-02-14 19:38:06 +0100jamm_(~jamm@unaffiliated/jamm)
2021-02-14 19:39:33 +0100frozenErebus(~frozenEre@94.128.81.133) (Ping timeout: 264 seconds)
2021-02-14 19:40:25 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 19:42:38 +0100jamm_(~jamm@unaffiliated/jamm) (Ping timeout: 264 seconds)
2021-02-14 19:43:08 +0100Noldorin(~noldorin@unaffiliated/noldorin) (Ping timeout: 268 seconds)
2021-02-14 19:43:45 +0100frozenErebus(~frozenEre@94.128.81.133)
2021-02-14 19:44:54 +0100bitmagie(~Thunderbi@200116b80679950091d656c272596245.dip.versatel-1u1.de) (Quit: bitmagie)
2021-02-14 19:45:06 +0100average(uid473595@gateway/web/irccloud.com/x-lumfcglyvjlqciwx) (Quit: Connection closed for inactivity)
2021-02-14 19:45:21 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 19:47:27 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 19:47:46 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 19:48:51 +0100Noldorin(~noldorin@unaffiliated/noldorin)
2021-02-14 19:55:09 +0100leah2(~leah@vuxu.org) (Ping timeout: 272 seconds)
2021-02-14 19:55:55 +0100mizu_no_oto(~textual@cpe-66-66-222-11.rochester.res.rr.com)
2021-02-14 19:56:11 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 19:56:40 +0100ransom(~c4264035@8.48.134.52)
2021-02-14 19:57:06 +0100ransom(~c4264035@8.48.134.52) (Client Quit)
2021-02-14 19:58:42 +0100_ashbreeze_(~mark@64.85.214.234.reverse.socket.net)
2021-02-14 19:59:51 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 20:01:16 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 20:03:26 +0100berberman_(~berberman@unaffiliated/berberman) (Ping timeout: 240 seconds)
2021-02-14 20:03:31 +0100berberman(~berberman@unaffiliated/berberman)
2021-02-14 20:04:45 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 272 seconds)
2021-02-14 20:06:58 +0100mizu_no_oto(~textual@cpe-66-66-222-11.rochester.res.rr.com) (Quit: Computer has gone to sleep.)
2021-02-14 20:08:08 +0100mizu_no_oto(~textual@cpe-66-66-222-11.rochester.res.rr.com)
2021-02-14 20:08:08 +0100ptrcmd(~ptrcmd@unaffiliated/petercommand) (Quit: leaving)
2021-02-14 20:08:59 +0100aldessa(~hugh@cpc158605-hari23-2-0-cust303.20-2.cable.virginm.net)
2021-02-14 20:09:19 +0100Dufaer(4d38337f@77-56-51-127.dclient.hispeed.ch)
2021-02-14 20:09:24 +0100 <Dufaer> Hi!
2021-02-14 20:09:24 +0100 <Dufaer> The documentation page
2021-02-14 20:09:25 +0100 <Dufaer> https://hackage.haskell.org/package/base-4.14.1.0/docs/GHC-TypeNats.html
2021-02-14 20:09:25 +0100 <Dufaer> states:
2021-02-14 20:09:26 +0100 <Dufaer> "The programmer interface for working with type-level naturals should be defined in a separate library."
2021-02-14 20:09:26 +0100 <Dufaer> Does this "separate library" exist?
2021-02-14 20:09:39 +0100ptrcmd(~ptrcmd@unaffiliated/petercommand)
2021-02-14 20:10:45 +0100raehik1(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 264 seconds)
2021-02-14 20:10:49 +0100 <merijn> singletons, if anything
2021-02-14 20:10:57 +0100 <merijn> @hackage singletons
2021-02-14 20:10:58 +0100 <lambdabot> https://hackage.haskell.org/package/singletons
2021-02-14 20:11:16 +0100 <Dufaer> Thanks!
2021-02-14 20:11:31 +0100 <merijn> Dufaer: But maybe others exist, I'm also vaguely aware of the existence of several GHC plugins for working with type level nats
2021-02-14 20:12:15 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 20:12:18 +0100 <merijn> Dufaer: Basically, that's just a disclaimer of "this is just the raw GHC internals, with no attempt at convenience and the lack of usability is not a bug in this module" ;)
2021-02-14 20:12:25 +0100mizu_no_oto(~textual@cpe-66-66-222-11.rochester.res.rr.com) (Ping timeout: 240 seconds)
2021-02-14 20:13:14 +0100 <geekosaur> that, basically. the ghc plugins and some ad hoc stuff are otherwise all I'm aware of in terms of usability
2021-02-14 20:13:24 +0100 <geekosaur> and it doesn't add up to much yet
2021-02-14 20:13:29 +0100alx741(~alx741@186.178.108.225) (Quit: alx741)
2021-02-14 20:13:40 +0100 <geekosaur> hm, I may have phrased that badly :)
2021-02-14 20:13:45 +0100frozenErebus(~frozenEre@94.128.81.133) (Ping timeout: 240 seconds)
2021-02-14 20:14:49 +0100boxscape(4ff0baf3@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.243) (Quit: Connection closed)
2021-02-14 20:14:52 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 20:15:08 +0100boxscape(4ff0baf3@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.243)
2021-02-14 20:15:44 +0100 <aldessa> hi, with reflex-dom is it possible to use any package on Hackage? I'm looking at Reflex Platform but it says it is a curated set of packages.
2021-02-14 20:16:22 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection)
2021-02-14 20:16:28 +0100 <geekosaur> not "any" package; I'd expect problems with any package that uses the FFI, if nothing else
2021-02-14 20:16:38 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-02-14 20:16:45 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 20:17:09 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection)
2021-02-14 20:17:26 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-02-14 20:17:28 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 20:17:57 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection)
2021-02-14 20:18:14 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-02-14 20:18:44 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection)
2021-02-14 20:19:00 +0100 <aldessa> i'm a bit confused, how do i use reflex without reflex-platform? it looks like GHCJS support for stack has gone
2021-02-14 20:19:01 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-02-14 20:19:08 +0100 <aldessa> reflex-dom*
2021-02-14 20:19:31 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection)
2021-02-14 20:20:26 +0100thongpv87(~thongpv87@103.6.151.121)
2021-02-14 20:20:32 +0100sm(~user@li229-222.members.linode.com) (Ping timeout: 246 seconds)
2021-02-14 20:22:16 +0100conal(~conal@64.71.133.70) (Read error: Connection reset by peer)
2021-02-14 20:22:41 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 265 seconds)
2021-02-14 20:23:55 +0100conal(~conal@64.71.133.70)
2021-02-14 20:31:22 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed)
2021-02-14 20:31:41 +0100leah2(~leah@vuxu.org)
2021-02-14 20:31:42 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 20:32:05 +0100bitmagie(~Thunderbi@200116b806799500c47356767c14074b.dip.versatel-1u1.de)
2021-02-14 20:32:18 +0100kmein(~weechat@static.173.83.99.88.clients.your-server.de) (Quit: ciao kakao)
2021-02-14 20:32:36 +0100kmein(~weechat@static.173.83.99.88.clients.your-server.de)
2021-02-14 20:33:15 +0100Jd007(~Jd007@162.156.11.151)
2021-02-14 20:33:46 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 20:34:16 +0100bitmagie(~Thunderbi@200116b806799500c47356767c14074b.dip.versatel-1u1.de) (Client Quit)
2021-02-14 20:35:57 +0100frozenErebus(~frozenEre@94.128.81.133)
2021-02-14 20:36:42 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Ping timeout: 265 seconds)
2021-02-14 20:38:40 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 20:40:05 +0100ixaxaar(~ixaxaar@49.207.197.94) (Ping timeout: 240 seconds)
2021-02-14 20:40:26 +0100dale(dale@unaffiliated/dale) (Remote host closed the connection)
2021-02-14 20:40:39 +0100dale(dale@unaffiliated/dale)
2021-02-14 20:41:05 +0100dale(dale@unaffiliated/dale) (Remote host closed the connection)
2021-02-14 20:41:34 +0100dale(dale@unaffiliated/dale)
2021-02-14 20:43:45 +0100mizu_no_oto(~textual@cpe-66-66-222-11.rochester.res.rr.com)
2021-02-14 20:44:02 +0100 <tromp> my program imports Basement.Types.Word256(Word256), but yields an error " • No instance for (Integral Word256) arising from a use of ‘div’" when dividing two Word256s
2021-02-14 20:44:34 +0100 <tromp> yet https://hackage.haskell.org/package/basement-0.0.11/docs/Basement-Types-Word256.html shows an instance Integral Word256
2021-02-14 20:45:01 +0100 <tromp> do i need a different import for that
2021-02-14 20:45:16 +0100 <geekosaur> make sure you have the matching version installed?
2021-02-14 20:45:24 +0100sm(~user@li229-222.members.linode.com)
2021-02-14 20:45:29 +0100 <tromp> i do
2021-02-14 20:45:48 +0100dale(dale@unaffiliated/dale) (Remote host closed the connection)
2021-02-14 20:45:49 +0100 <tromp> basement-0.0.11 is installed
2021-02-14 20:45:54 +0100 <swarmcollective> Remove the "(Word256)" so it will allow all imports from Basement.Types.Word256 ?
2021-02-14 20:46:12 +0100 <geekosaur> instances should always be imported
2021-02-14 20:46:21 +0100 <swarmcollective> Oh, good to know.
2021-02-14 20:46:24 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 20:46:28 +0100 <geekosaur> type system soundness depends on it
2021-02-14 20:46:35 +0100dale(dale@unaffiliated/dale)
2021-02-14 20:46:52 +0100 <tromp> that gave a ton of errors every time i use + (asking whether I mean Prelude.+ or Basement one, evven if I add two Ints)
2021-02-14 20:47:26 +0100aldessa(~hugh@cpc158605-hari23-2-0-cust303.20-2.cable.virginm.net) (Quit: Leaving)
2021-02-14 20:47:26 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 20:47:46 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 20:48:58 +0100 <tromp> can i let the + be inferred from arguments?
2021-02-14 20:49:13 +0100 <merijn> tromp: eh, Basement is intended to be a replacement for Prelude
2021-02-14 20:49:22 +0100 <merijn> if you use it you should be getting rid of Prelude
2021-02-14 20:49:23 +0100 <geekosaur> type directed name resolution is not a thing, no
2021-02-14 20:49:35 +0100 <merijn> (via -XNoImplicitPrelude or whatever the flag is)
2021-02-14 20:49:40 +0100 <tromp> merijn: ah that explains
2021-02-14 20:49:52 +0100 <geekosaur> and merijn is probably right, it's trying to find an instance for the wrong Integralk
2021-02-14 20:49:55 +0100 <davean> But wouldn't types not be enough? Does basement's + not also add Ints?
2021-02-14 20:50:00 +0100raehik1(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-02-14 20:50:24 +0100 <geekosaur> true that
2021-02-14 20:50:46 +0100 <davean> Theres nothing here to say which is the correct oneto my knowlege
2021-02-14 20:51:33 +0100pera(~pera@unaffiliated/pera) (Ping timeout: 264 seconds)
2021-02-14 20:51:51 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 20:52:31 +0100 <tromp> ok, with that language extension, I now get error: Not in scope: type constructor or class ‘Int’
2021-02-14 20:52:53 +0100 <tromp> for instance on my function sig: armies :: Int -> Int -> [(Int, Int, Int, Word256)]
2021-02-14 20:53:13 +0100 <geekosaur> you need more than just that module if you're using it as your Prelude. probably: import Basement
2021-02-14 20:53:47 +0100 <geekosaur> you don't get to pick and choose types from it, in short; you need the whole package as a group
2021-02-14 20:54:13 +0100 <merijn> Or maybe read the README which discusses how to use it with and without Prelude :p
2021-02-14 20:54:38 +0100 <geekosaur> reading documentation. imagine that :)
2021-02-14 20:54:47 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 272 seconds)
2021-02-14 20:55:39 +0100 <Squarism> if you have 2 types that are sets of constraints. Can you combine then into one type?
2021-02-14 20:55:58 +0100 <davean> geekosaur: No, I won't
2021-02-14 20:56:00 +0100 <Squarism> ...by reusing the other two
2021-02-14 20:56:09 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 20:57:19 +0100mizu_no_oto(~textual@cpe-66-66-222-11.rochester.res.rr.com) (Ping timeout: 256 seconds)
2021-02-14 20:57:34 +0100 <geekosaur> "types"? afaik you can only do that with type synonyms
2021-02-14 20:57:49 +0100 <geekosaur> types hide too much
2021-02-14 20:58:30 +0100 <tromp> i think i need Foundation. will try using latter's README
2021-02-14 20:58:46 +0100 <monochrom> But since the syntax is "type XXX = ..." people think that XXX is a type.
2021-02-14 20:59:00 +0100 <monochrom> So much for meaningful reserved words.
2021-02-14 20:59:24 +0100 <merijn> monochrom: Well, it is :p
2021-02-14 20:59:59 +0100 <DigitalKiwi> i know of shelly HSH and turtle but are there any more i should look at? want to replace some shell scripts but i don't know which of these best fits the kind of scripts i write :(
2021-02-14 21:00:00 +0100 <Squarism> geekosaur, i guess i mean "type XYZ a b .. = "
2021-02-14 21:00:03 +0100 <geekosaur> if that's the case then you can just combine them, I think: type XAndY a = (X a, Y a) -- may require ConstraintKinds still?
2021-02-14 21:00:14 +0100 <davean> I mean perhaps he means sometihng like http://hackage.haskell.org/package/constraints-0.12/docs/Data-Constraint.html ?
2021-02-14 21:00:24 +0100 <merijn> monochrom: Arguably it's "a name for a type", then again "ReaderT Foo" is, arguably, also just a name for a type :p
2021-02-14 21:00:43 +0100minoru_shiraeesh(~shiraeesh@46.34.207.93)
2021-02-14 21:01:08 +0100__minoru__shirae(~shiraeesh@109.166.57.144) (Ping timeout: 272 seconds)
2021-02-14 21:01:20 +0100 <monochrom> More generally and meta-ly, so much for wording your question in your own wording without actual code or concrete example.
2021-02-14 21:01:45 +0100pfurla(~pfurla@ool-182ed2e2.dyn.optonline.net) (Ping timeout: 272 seconds)
2021-02-14 21:01:49 +0100 <monochrom> I want to tell you the story of 1048.
2021-02-14 21:02:07 +0100 <DigitalKiwi> https://mostlyabsurd.com/files/tito is one i want to do
2021-02-14 21:03:06 +0100 <monochrom> It was 10-15 years ago. My friend was an on-site tech support person, he went to a small office to upgrade software. The small office people asked him "will this work for 1048?"
2021-02-14 21:03:28 +0100 <monochrom> Their homebrew terminology "1048" means "1024x768 monitors"
2021-02-14 21:03:33 +0100Tops2(~Tobias@dyndsl-095-033-023-209.ewe-ip-backbone.de)
2021-02-14 21:03:37 +0100 <dmj`> DigitalKiwi: just writing bash, and then using ShellCheck is nice too
2021-02-14 21:03:48 +0100 <DigitalKiwi> dmj`: yeah that's what i do now lol
2021-02-14 21:04:17 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 272 seconds)
2021-02-14 21:04:40 +0100 <DigitalKiwi> some of these are starting to get more advanced than i know how to do in bash :(
2021-02-14 21:04:56 +0100pfurla(~pfurla@219.15.195.173.client.static.strong-in52.as13926.net)
2021-02-14 21:04:57 +0100conal(~conal@64.71.133.70) (Quit: Computer has gone to sleep.)
2021-02-14 21:05:05 +0100petersen(~petersen@redhat/juhp) (Ping timeout: 240 seconds)
2021-02-14 21:05:11 +0100 <dmj`> lots of haskell shell libs are stringly-typed anyways
2021-02-14 21:05:15 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 21:05:18 +0100frozenErebus(~frozenEre@94.128.81.133) (Ping timeout: 256 seconds)
2021-02-14 21:05:38 +0100 <geekosaur> lots of shell scripts are stringly typed anyways :)
2021-02-14 21:05:59 +0100 <monochrom> lots of Turing machines, too.
2021-02-14 21:07:11 +0100petersen(~petersen@redhat/juhp)
2021-02-14 21:07:31 +0100Tops22(~Tobias@dyndsl-095-033-023-209.ewe-ip-backbone.de) (Ping timeout: 256 seconds)
2021-02-14 21:08:04 +0100irc_user(uid423822@gateway/web/irccloud.com/x-ywgoyvpgklsytbwc)
2021-02-14 21:09:45 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 21:11:33 +0100kam1(~kam1@5.125.120.35)
2021-02-14 21:12:04 +0100kam1(~kam1@5.125.120.35) (Read error: Connection reset by peer)
2021-02-14 21:13:04 +0100 <DigitalKiwi> yeah lots of String -> [String] -> [String] in HSH at least
2021-02-14 21:13:47 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 21:18:19 +0100 <dmj`> System.Process is very stringy
2021-02-14 21:18:58 +0100ADG1089__(~aditya@223.235.76.112)
2021-02-14 21:20:02 +0100 <geekosaur> POSIX is very stringy
2021-02-14 21:20:11 +0100tlyu(~tlyu@195.140.213.38) (Remote host closed the connection)
2021-02-14 21:20:16 +0100 <geekosaur> for ByteString values of "stringy"
2021-02-14 21:20:26 +0100conal(~conal@64.71.133.70)
2021-02-14 21:20:45 +0100ADG1089__(~aditya@223.235.76.112) (Read error: Connection reset by peer)
2021-02-14 21:22:28 +0100boxscape(4ff0baf3@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.243) (Quit: Connection closed)
2021-02-14 21:22:39 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 246 seconds)
2021-02-14 21:25:25 +0100stef204(~stef204@unaffiliated/stef-204/x-384198) (Quit: WeeChat 3.0)
2021-02-14 21:25:55 +0100boxscape(4ff0baf3@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.243)
2021-02-14 21:27:08 +0100thongpv87(~thongpv87@103.6.151.121) (Remote host closed the connection)
2021-02-14 21:27:27 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) (Ping timeout: 265 seconds)
2021-02-14 21:28:44 +0100mizu_no_oto(~textual@cpe-66-66-222-11.rochester.res.rr.com)
2021-02-14 21:29:36 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 21:30:15 +0100ezrakilty(~ezrakilty@75-172-120-208.tukw.qwest.net) (Remote host closed the connection)
2021-02-14 21:30:46 +0100gioyik_(~gioyik@gateway/tor-sasl/gioyik)
2021-02-14 21:31:17 +0100 <DigitalKiwi> as it turns out i manipulate a lot of strings in my bash scripts ;P
2021-02-14 21:31:54 +0100heatsink(~heatsink@2600:1700:bef1:5e10:b101:b0cf:b14d:ce6b) (Remote host closed the connection)
2021-02-14 21:32:07 +0100 <pjb> DigitalKiwi: that sounds dire. bash is not very efficient at processing strings…
2021-02-14 21:32:38 +0100 <geekosaur> which is funny because processing strings is most of what shells do
2021-02-14 21:32:56 +0100mizu_no_oto(~textual@cpe-66-66-222-11.rochester.res.rr.com) (Ping timeout: 240 seconds)
2021-02-14 21:34:17 +0100gioyik(~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 268 seconds)
2021-02-14 21:35:13 +0100 <DigitalKiwi> git show -U25 --word-diff=plain --color=auto --word-diff-regex='\w+.\w+' | grep -E 'assets:cc|Net' | sed 's:\$ ::'|sed -E 's:(\[-|\{\+)::g'| sed -E 's:(\+\})::g'|sed -E 's:(\-\]):",":g'|sed 's:",": ":g'|sed 's:"::g'|awk '{ if ($3) {v=$3-$2; if(v>0) { print $1 "\t" "\033[1;31m" $2 "\033[0m" "\t" "\033[1;35m" $3 "\033[0m" "\t" "\033[0;32m(v: +" v ")\033[0m" } else print $1 "\t" "\033[1;31m" $2 "\33[0m" "\t" "\033[1;35m" $3 "\033[0m" "\t" "\033[0
2021-02-14 21:35:13 +0100 <DigitalKiwi> ;31m(v: " v ")\033[0m" } else print $1 "\t" "\033[0;36m" $2 "\033[0m" "\t" "\033[0;36m" $2 "\033[0m" }'|sed 's:\t:,:g' | column -N "coin,prev,current,delta" --table --output-separator " " --separator ","
2021-02-14 21:35:16 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 21:36:58 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed)
2021-02-14 21:37:00 +0100zepheiryan(~zepheirya@178.239.168.171)
2021-02-14 21:37:19 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 21:37:35 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 21:38:31 +0100hexfive(~hexfive@50.35.83.177)
2021-02-14 21:38:56 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 21:39:28 +0100bnbgg_(uid454564@gateway/web/irccloud.com/x-kgcnnasbwqjrcwxm) (Quit: Connection closed for inactivity)
2021-02-14 21:39:37 +0100 <DigitalKiwi> https://dpaste.com/4DWY2S7JE#wrap
2021-02-14 21:41:43 +0100 <DigitalKiwi> https://dpaste.com/G4TJE79QZ#wrap
2021-02-14 21:41:54 +0100 <DigitalKiwi> it's messy and wrong ;_;
2021-02-14 21:41:56 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Ping timeout: 240 seconds)
2021-02-14 21:42:28 +0100 <DigitalKiwi> but it's pretty
2021-02-14 21:42:41 +0100 <monochrom> haha
2021-02-14 21:42:55 +0100 <DigitalKiwi> https://mostlyabsurd.com/files/2021-02-14-110551_2880x1800_scrot.png
2021-02-14 21:43:00 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-02-14 21:43:28 +0100 <merijn> DigitalKiwi: You seem to have misspelled "terrifying"
2021-02-14 21:43:54 +0100 <DigitalKiwi> 03:39 DigitalKiwi: i have something amazingly horrific but so pretty
2021-02-14 21:44:24 +0100 <geekosaur> looks like something I would write >.>
2021-02-14 21:44:55 +0100 <DigitalKiwi> don't trust anyone who says they wouldn't
2021-02-14 21:44:55 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 21:45:01 +0100knupfer(~Thunderbi@200116b8246bfb009dcc87cb843657f3.dip.versatel-1u1.de)
2021-02-14 21:45:03 +0100sh9(~sh9@softbank060116136158.bbtec.net) (Ping timeout: 246 seconds)
2021-02-14 21:47:02 +0100 <DigitalKiwi> i use jq in a few others a lot...
2021-02-14 21:47:26 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 21:47:46 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 21:47:48 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 21:48:02 +0100leah2(~leah@vuxu.org) (Ping timeout: 264 seconds)
2021-02-14 21:48:08 +0100 <monochrom> https://www.youtube.com/watch?v=O4SXqAnKWwE "ASCII Haskell raytracer"
2021-02-14 21:49:09 +0100zar(~zar@fw1.ciirc.cvut.cz) (Ping timeout: 264 seconds)
2021-02-14 21:49:39 +0100sh9(~sh9@softbank060116136158.bbtec.net)
2021-02-14 21:50:10 +0100fissureman(~quassel@c-73-163-84-25.hsd1.dc.comcast.net) (Ping timeout: 265 seconds)
2021-02-14 21:50:21 +0100fissureman(~quassel@c-73-163-84-25.hsd1.dc.comcast.net)
2021-02-14 21:51:10 +0100 <dmj`> jq is a classic
2021-02-14 21:51:23 +0100usr25(~J@68.red-83-46-58.dynamicip.rima-tde.net)
2021-02-14 21:51:35 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 21:51:51 +0100bnbgg_(uid454564@gateway/web/irccloud.com/x-jxwbvqetgazmpwcn)
2021-02-14 21:52:01 +0100 <maerwald> I write my backends with jq and bash
2021-02-14 21:54:10 +0100knupfer(~Thunderbi@200116b8246bfb009dcc87cb843657f3.dip.versatel-1u1.de) (Quit: knupfer)
2021-02-14 21:54:58 +0100 <DigitalKiwi> the problem isn't so much that bash isn't good at the things i've shown you so far it's that it's not good at the things i want to do :(
2021-02-14 21:56:05 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 21:57:11 +0100 <DigitalKiwi> hmm but maybe i can combine them
2021-02-14 21:58:53 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 21:59:10 +0100zar(~zar@fw1.ciirc.cvut.cz)
2021-02-14 21:59:46 +0100 <DigitalKiwi> btw what's a haskell lib to print color text like i did above heh
2021-02-14 22:01:02 +0100DigitalKiwisees ansi-terminal...ohhi ocharles
2021-02-14 22:02:53 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 22:05:21 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net) (Ping timeout: 264 seconds)
2021-02-14 22:05:42 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 246 seconds)
2021-02-14 22:05:43 +0100 <dmj`> maerwald: what about your front ends?
2021-02-14 22:06:14 +0100 <sm[m]> DigitalKiwi: maybe overkill but I like cmd that's built in to shake. Easy to use, and if your script happens to generate any artifacts, you have the full power of shake available
2021-02-14 22:06:46 +0100 <maerwald> dmj`: I write them all in miso
2021-02-14 22:07:52 +0100 <sm[m]> also: cool scripts, why would you rewrite them ?
2021-02-14 22:07:58 +0100_ht(~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection)
2021-02-14 22:08:38 +0100 <dmj`> maerwald: that's correct
2021-02-14 22:09:05 +0100Varis(~Tadas@unaffiliated/varis) (Remote host closed the connection)
2021-02-14 22:11:03 +0100heatsink_(~heatsink@2600:1700:bef1:5e10:b101:b0cf:b14d:ce6b)
2021-02-14 22:11:54 +0100ezrakilty(~ezrakilty@75-172-120-208.tukw.qwest.net)
2021-02-14 22:13:09 +0100xsperry(~as@unaffiliated/xsperry)
2021-02-14 22:13:45 +0100sMuNiX(~sMuNiX@lnsm2-montreal02-142-118-236-120.internet.virginmobile.ca) (Ping timeout: 246 seconds)
2021-02-14 22:15:36 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net)
2021-02-14 22:16:39 +0100ezrakilty(~ezrakilty@75-172-120-208.tukw.qwest.net) (Ping timeout: 256 seconds)
2021-02-14 22:17:45 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 22:18:19 +0100sMuNiX(~sMuNiX@lnsm2-montreal02-142-118-236-120.internet.virginmobile.ca)
2021-02-14 22:18:52 +0100mirrorbird(~psutcliff@2a00:801:44d:603d:d116:d5a1:4a2f:a08f)
2021-02-14 22:19:34 +0100coot(~coot@37.30.55.141.nat.umts.dynamic.t-mobile.pl)
2021-02-14 22:19:54 +0100coot(~coot@37.30.55.141.nat.umts.dynamic.t-mobile.pl) (Remote host closed the connection)
2021-02-14 22:19:55 +0100Sheilong(uid293653@gateway/web/irccloud.com/x-ltinxgozprmzwqca) ()
2021-02-14 22:20:28 +0100coot(~coot@37.30.55.141.nat.umts.dynamic.t-mobile.pl)
2021-02-14 22:21:21 +0100verement(~anonymous@cpe-76-167-229-223.san.res.rr.com) (Quit: verement)
2021-02-14 22:22:09 +0100elliott__(~elliott@pool-108-51-101-42.washdc.fios.verizon.net) (Ping timeout: 264 seconds)
2021-02-14 22:22:45 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2021-02-14 22:23:16 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 22:24:12 +0100 <__monty__> sm[m]: Oo, cool idea. How does shake help with coloring though?
2021-02-14 22:25:04 +0100 <sm[m]> I didn't mean it for that question :)
2021-02-14 22:25:45 +0100gioyik(~gioyik@gateway/tor-sasl/gioyik)
2021-02-14 22:27:19 +0100gioyik_(~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 268 seconds)
2021-02-14 22:27:56 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed)
2021-02-14 22:29:57 +0100slack1256(~slack1256@pc-198-213-46-190.cm.vtr.net)
2021-02-14 22:30:02 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 22:30:40 +0100son0p(~son0p@181.136.122.143)
2021-02-14 22:32:05 +0100pfurla(~pfurla@219.15.195.173.client.static.strong-in52.as13926.net) (Ping timeout: 240 seconds)
2021-02-14 22:33:27 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Client Quit)
2021-02-14 22:33:47 +0100 <sm[m]> but related to that: ansi-terminal is the package, indeed. Which brings the question, can I robustly add packages to my scripts ? The answer is yes, if you make it a cabal or (works slightly better) stack script.
2021-02-14 22:33:49 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 22:34:14 +0100pfurla(~pfurla@ool-182ed2e2.dyn.optonline.net)
2021-02-14 22:34:44 +0100 <sm[m]> these scripts are more verbose and much heavier for other people to install than shell scripts, but if you can get past that it sure is intoxicating knowing there's no ceiling on your script's power
2021-02-14 22:35:32 +0100verement(~anonymous@cpe-76-167-229-223.san.res.rr.com)
2021-02-14 22:36:45 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 22:38:16 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Ping timeout: 240 seconds)
2021-02-14 22:41:35 +0100heatsink_(~heatsink@2600:1700:bef1:5e10:b101:b0cf:b14d:ce6b) (Remote host closed the connection)
2021-02-14 22:41:38 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 22:47:25 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 22:47:45 +0100idhugo_(~idhugo@80-62-117-97-mobile.dk.customer.tdc.net) (Ping timeout: 240 seconds)
2021-02-14 22:47:46 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 22:48:19 +0100kmein(~weechat@static.173.83.99.88.clients.your-server.de) (Quit: ciao kakao)
2021-02-14 22:48:35 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 22:48:35 +0100kmein(~weechat@static.173.83.99.88.clients.your-server.de)
2021-02-14 22:49:27 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 22:51:12 +0100geekosaur(ae68c070@cpe-174-104-192-112.neo.res.rr.com) (Quit: Connection closed)
2021-02-14 22:51:20 +0100boxscape(4ff0baf3@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.243) (Quit: Connection closed)
2021-02-14 22:51:20 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 22:51:22 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 22:54:25 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 22:54:37 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds)
2021-02-14 22:56:47 +0100 <ij> alterF is for only for the new containers, which doesn't build :/
2021-02-14 22:56:47 +0100justanotheruser(~justanoth@unaffiliated/justanotheruser) (Ping timeout: 260 seconds)
2021-02-14 22:56:49 +0100Gurkenglas(~Gurkengla@dslb-092-075-179-204.092.075.pools.vodafone-ip.de) (Read error: Connection reset by peer)
2021-02-14 22:56:56 +0100 <ij> womp womp
2021-02-14 22:57:35 +0100 <ij> ah, but that must be the optimized version. lens likely has a working, slower one
2021-02-14 22:59:05 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 240 seconds)
2021-02-14 22:59:08 +0100 <ij> hm, no it compiled after all.. on the 10th rerun _after_ I stopped fiddling with NIX_PATH and override definitions
2021-02-14 22:59:58 +0100conal(~conal@64.71.133.70) (Quit: Computer has gone to sleep.)
2021-02-14 23:00:25 +0100conal(~conal@64.71.133.70)
2021-02-14 23:00:44 +0100fendor(~fendor@77.119.131.224.wireless.dyn.drei.com) (Remote host closed the connection)
2021-02-14 23:01:07 +0100fendor(~fendor@77.119.131.224.wireless.dyn.drei.com)
2021-02-14 23:02:10 +0100elliott__(~elliott@pool-108-51-101-42.washdc.fios.verizon.net)
2021-02-14 23:04:40 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-02-14 23:04:45 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed)
2021-02-14 23:05:09 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 23:05:15 +0100conal(~conal@64.71.133.70) (Ping timeout: 272 seconds)
2021-02-14 23:06:08 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection)
2021-02-14 23:07:51 +0100 <ij> @hoogle a -> Data.Set.Set a -> a
2021-02-14 23:07:52 +0100 <lambdabot> Data.Set lookupLT :: Ord a => a -> Set a -> Maybe a
2021-02-14 23:07:52 +0100 <lambdabot> Data.Set lookupGT :: Ord a => a -> Set a -> Maybe a
2021-02-14 23:07:52 +0100 <lambdabot> Data.Set lookupLE :: Ord a => a -> Set a -> Maybe a
2021-02-14 23:07:56 +0100hseg(~gesh@IGLD-84-228-239-97.inter.net.il) (Ping timeout: 240 seconds)
2021-02-14 23:08:35 +0100 <ij> there's no lookup that finds the exact one. there's delete, but it doesn't return it :/
2021-02-14 23:09:10 +0100 <ij> is it really not there or am I just not seeing it?
2021-02-14 23:10:55 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 23:11:06 +0100 <Rembane> ij: Why do you want to get it back? You already have it.
2021-02-14 23:11:32 +0100 <ij> I have the Eq/Ord value, but not the rest
2021-02-14 23:12:48 +0100 <ij> ah, it's DIY – lookupIndex + elemAt
2021-02-14 23:12:59 +0100bo_(~bo@178.150.122.153)
2021-02-14 23:13:16 +0100 <Rembane> Don't you already have the value you are doing a lookup on?
2021-02-14 23:13:33 +0100Franciman(~francesco@host-82-49-79-189.retail.telecomitalia.it) (Quit: Leaving)
2021-02-14 23:13:45 +0100 <MarcelineVQ> use member to test for Set membership
2021-02-14 23:13:56 +0100 <ij> I do, but it's not equal to the value with the same Ord order in the set
2021-02-14 23:15:16 +0100sMuNiX(~sMuNiX@lnsm2-montreal02-142-118-236-120.internet.virginmobile.ca) (Ping timeout: 240 seconds)
2021-02-14 23:15:16 +0100ski. o O ( some values are more equal than others )
2021-02-14 23:15:25 +0100minoru_shiraeesh(~shiraeesh@46.34.207.93) (Ping timeout: 240 seconds)
2021-02-14 23:15:26 +0100 <Rembane> That sounds like a potential footgun
2021-02-14 23:15:38 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2021-02-14 23:16:01 +0100_bo(~bo@178.150.122.153) (Ping timeout: 272 seconds)
2021-02-14 23:16:07 +0100 <ij> well, I don't know a better way to write it
2021-02-14 23:17:56 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 23:18:38 +0100 <c_wraith> ij: I think you want alterF
2021-02-14 23:19:10 +0100 <ephemient> alterF doesn't return the element itself either
2021-02-14 23:19:33 +0100 <c_wraith> sure it does
2021-02-14 23:19:38 +0100 <c_wraith> it does whatever f does
2021-02-14 23:19:43 +0100danvet(~Daniel@2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa) (Ping timeout: 272 seconds)
2021-02-14 23:19:56 +0100nhs(~nhs@c-24-20-87-79.hsd1.or.comcast.net)
2021-02-14 23:20:01 +0100 <c_wraith> oh, wait. It only gets a Bool? that's austere
2021-02-14 23:20:14 +0100 <ephemient> :t \a s -> case S.spanAntitone (< a) s of (l, S.minView -> Just (a', r)) -> Just (a', l <> r); _ -> Nothing
2021-02-14 23:20:16 +0100 <lambdabot> Ord a => a -> S.Set a -> Maybe (a, S.Set a)
2021-02-14 23:20:30 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2021-02-14 23:20:49 +0100 <ephemient> that being said, I think it's pretty unusual to have Eq/Ord on only part of a type
2021-02-14 23:21:29 +0100 <ephemient> wait, that doesn't check for a == a'
2021-02-14 23:21:39 +0100 <ephemient> anyway, you can bodge together something like that I guess
2021-02-14 23:21:45 +0100 <ij> :t fmap (flip Data.Set.findIndex Data.Set.empty) . Data.Set.lookupIndex
2021-02-14 23:21:47 +0100 <lambdabot> Ord a => a -> S.Set a -> Int
2021-02-14 23:21:58 +0100 <ij> sorry, wrong copypaste
2021-02-14 23:22:13 +0100greety(bab7262d@186.183.38.45)
2021-02-14 23:22:18 +0100 <ij> it's elemAt + lookupIndex
2021-02-14 23:22:23 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 256 seconds)
2021-02-14 23:23:01 +0100 <ij> is it that unusual? that's the whole reason it's by instances in the first place :) so you can swap it for something else
2021-02-14 23:23:07 +0100 <c_wraith> The whole api for set just isn't designed for Ord/Eq ignoring fields
2021-02-14 23:29:48 +0100 <ij> it would be really odd, if I was the only one donig that
2021-02-14 23:30:05 +0100clog(~nef@bespin.org) (Ping timeout: 240 seconds)
2021-02-14 23:30:22 +0100 <nshepperd> just use a Map?
2021-02-14 23:31:13 +0100boxscape(4ff0baf3@gateway/web/cgi-irc/kiwiirc.com/ip.79.240.186.243)
2021-02-14 23:31:48 +0100leah2(~leah@vuxu.org)
2021-02-14 23:32:40 +0100 <ij> that would work
2021-02-14 23:33:59 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-02-14 23:34:19 +0100 <ij> that does sound like the saner option
2021-02-14 23:35:13 +0100 <nshepperd> a Set containing items where Ord only handles part of the value is basically simulating a Map poorly
2021-02-14 23:35:34 +0100conal(~conal@64.71.133.70)
2021-02-14 23:36:03 +0100justanotheruser(~justanoth@unaffiliated/justanotheruser)
2021-02-14 23:37:46 +0100greety(bab7262d@186.183.38.45) ()
2021-02-14 23:37:47 +0100 <ij> it's funny to moe how totally unaware I was of that... it seemed like an ok idea
2021-02-14 23:37:56 +0100 <ij> moe ~> me
2021-02-14 23:38:50 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 272 seconds)
2021-02-14 23:41:39 +0100ezrakilty(~ezrakilty@75-172-120-208.tukw.qwest.net)
2021-02-14 23:41:59 +0100heatsink(~heatsink@2600:1700:bef1:5e10:b101:b0cf:b14d:ce6b)
2021-02-14 23:44:24 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-14 23:46:50 +0100heatsink(~heatsink@2600:1700:bef1:5e10:b101:b0cf:b14d:ce6b) (Ping timeout: 264 seconds)
2021-02-14 23:47:26 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-02-14 23:47:46 +0100zebrag(~inkbottle@aaubervilliers-654-1-112-148.w86-198.abo.wanadoo.fr)
2021-02-14 23:50:31 +0100conal(~conal@64.71.133.70) (Quit: Computer has gone to sleep.)
2021-02-14 23:53:48 +0100 <ephemient> Set a ≅ Map a (), Map a b ≅ Set (Arg a b)
2021-02-14 23:54:41 +0100 <ephemient> I wouldn't have been surprised if they used the same representation underneath, but apparently that's not what containers does
2021-02-14 23:55:44 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed)
2021-02-14 23:56:05 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9)
2021-02-14 23:57:49 +0100sMuNiX(~sMuNiX@lnsm2-montreal02-142-118-236-120.internet.virginmobile.ca)
2021-02-14 23:59:38 +0100jpds(~jpds@gateway/tor-sasl/jpds)
2021-02-14 23:59:42 +0100 <Axman6> the former is how Set in DAML is defined (for not anyway, I think there's work to make TextMap a specific type which is provided by whatever platform the contract code is run on)
2021-02-14 23:59:47 +0100 <Axman6> now*