| 2021-07-14 00:00:19 +0200 | <hseg> | for this to happen, we must have a ~ (α -> β), b ~ (φ α -> φ β) |
| 2021-07-14 00:00:31 +0200 | <hseg> | ( ~ is type equality) |
| 2021-07-14 00:01:20 +0200 | hgolden | (uid507415@id-507415.highgate.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-14 00:01:38 +0200 | <hseg> | I then make a couple of bookkeeping renamings, to avoid having α, β, φ in the resulting type |
| 2021-07-14 00:01:51 +0200 | <hseg> | (so read {} from left to right) |
| 2021-07-14 00:02:43 +0200 | <hseg> | the multiline {} decompose the desired equality more and more, producing assignments for some of the variables |
| 2021-07-14 00:05:14 +0200 | <mariohesles> | Say I want to implement a library for defining social relationships, so a function in this library might be something like getPaternalGrandfather :: Person -> Person; I want to have references to each `Person`s children and parents within a given value. What would be a "Haskell-y" way of doing this? I'm thinking of doing something like the following `data Person = P UID Name Sex Parents Children deriving (Eq, Show)`, where `type UID = |
| 2021-07-14 00:05:14 +0200 | <mariohesles> | Int`, `type Name = String`, `data Sex = Female | Male deriving (Eq, Show), `type Parents = [UID]` and `type Children = [UID]`, but it feels wrong. I would have to have a database of all Persons and would have to refer to this database to do anything interesting. Is this bad? |
| 2021-07-14 00:05:42 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:146a:5c4b:109:2ce4) |
| 2021-07-14 00:08:38 +0200 | <hololeap> | is what bad? having a database or needing it to do anything interesting? |
| 2021-07-14 00:08:51 +0200 | <hololeap> | those both sound like pretty reasonable things to me |
| 2021-07-14 00:09:11 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2021-07-14 00:09:45 +0200 | <hololeap> | it's a pretty simple schema that would fit well inside an SQL database, so it's not going to need the full expressiveness of haskell. there's nothing wrong with that. |
| 2021-07-14 00:09:59 +0200 | <hseg> | mariohesles: you mean you feel the encoding should be closer to the relationship graph? |
| 2021-07-14 00:10:30 +0200 | <hseg> | otoh, being closer to the graph is nicer conceptually, but as hololeap points out, it'll be harder to serialize |
| 2021-07-14 00:10:57 +0200 | <hseg> | and grippingly, it can potentially entail retaining huge objects in memory |
| 2021-07-14 00:12:47 +0200 | <FixedPointDude> | yeah the graphiest thing that jumps out to me is: an Ancestry is a tree of Person, and every Person contains an Ancestry |
| 2021-07-14 00:13:03 +0200 | <FixedPointDude> | data Person = Person Ancestry |
| 2021-07-14 00:13:04 +0200 | <FixedPointDude> | data Ancestry = Empty | Tree [Person] |
| 2021-07-14 00:13:35 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:146a:5c4b:109:2ce4) (Quit: Leaving) |
| 2021-07-14 00:13:47 +0200 | <FixedPointDude> | well the Empty is redundant |
| 2021-07-14 00:15:57 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 245 seconds) |
| 2021-07-14 00:16:05 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Remote host closed the connection) |
| 2021-07-14 00:16:38 +0200 | Guest6135 | (~Guest61@2001:ac8:27:20::a01e) (Quit: Client closed) |
| 2021-07-14 00:16:58 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-14 00:19:47 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-14 00:21:48 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2021-07-14 00:23:22 +0200 | vk3wtf | (~doc@124.168.198.139) |
| 2021-07-14 00:23:45 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) |
| 2021-07-14 00:31:18 +0200 | Guest6176 | (~Guest61@2001:ac8:27:20::a01e) |
| 2021-07-14 00:31:29 +0200 | Lycurgus | (~juan@cpe-45-46-140-49.buffalo.res.rr.com) (Quit: Exeunt) |
| 2021-07-14 00:34:10 +0200 | neceve | (~quassel@2a02:c7f:607e:d600:f762:20dd:304e:4b1f) (Ping timeout: 246 seconds) |
| 2021-07-14 00:35:12 +0200 | <dsal> | mariohesles: modeling this is going to be ridiculously hard. Are you sure every person is only either Male or Female and only has one paternal grandfather? |
| 2021-07-14 00:36:33 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-07-14 00:39:24 +0200 | gentauro | (~gentauro@user/gentauro) (Ping timeout: 272 seconds) |
| 2021-07-14 00:39:24 +0200 | sm2n | (~sm2n@user/sm2n) (Ping timeout: 272 seconds) |
| 2021-07-14 00:39:38 +0200 | Gurkenglas | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) (Read error: Connection reset by peer) |
| 2021-07-14 00:39:45 +0200 | rostero | (uid236576@id-236576.tooting.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-14 00:40:01 +0200 | Gurkenglas | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) |
| 2021-07-14 00:43:12 +0200 | dextaa | (~DV@aftr-37-201-214-197.unity-media.net) (Ping timeout: 255 seconds) |
| 2021-07-14 00:43:16 +0200 | machinedgod | (~machinedg@24.105.81.50) (Ping timeout: 246 seconds) |
| 2021-07-14 00:44:11 +0200 | Gurkenglas_ | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) |
| 2021-07-14 00:45:10 +0200 | warnz | (~warnz@2600:1700:77c0:5610:9856:f279:a598:9845) |
| 2021-07-14 00:45:19 +0200 | dextaa | (~DV@37.201.214.197) |
| 2021-07-14 00:46:34 +0200 | Gurkenglas | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) (Ping timeout: 252 seconds) |
| 2021-07-14 00:46:53 +0200 | pavonia_ | (~user@user/siracusa) |
| 2021-07-14 00:48:16 +0200 | pavonia | (~user@user/siracusa) (Ping timeout: 272 seconds) |
| 2021-07-14 00:48:19 +0200 | pavonia_ | pavonia |
| 2021-07-14 00:50:07 +0200 | shapr | (~user@pool-108-28-144-11.washdc.fios.verizon.net) (Ping timeout: 245 seconds) |
| 2021-07-14 00:50:24 +0200 | Gurkenglas_ | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) (Ping timeout: 255 seconds) |
| 2021-07-14 00:50:25 +0200 | <mariohesles> | dsal for the purpose of the library, yes, assume that there are only two sexes and everyone has exactly two real parents |
| 2021-07-14 00:50:49 +0200 | <davean> | mariohesles: haha, I worked with genetics lab data, parents are complicated. |
| 2021-07-14 00:51:18 +0200 | <mariohesles> | hseg yes I do feel the encoding could be closer to the graph itself |
| 2021-07-14 00:52:20 +0200 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) |
| 2021-07-14 00:52:36 +0200 | <dsal> | A person may have multiple arbitrary relationships with multiple people. It's going to be easiest to just do a plain graph and perhaps have common named edges, but there are people for whom their father and grandfather are the same person, or have multiple fathers to traverse for grandparents. |
| 2021-07-14 00:52:47 +0200 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) |
| 2021-07-14 00:57:45 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-14 00:58:35 +0200 | fryguybob | (~fryguybob@cpe-74-65-31-113.rochester.res.rr.com) (Ping timeout: 252 seconds) |
| 2021-07-14 00:59:18 +0200 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) |
| 2021-07-14 01:03:08 +0200 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-14 01:03:41 +0200 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) |
| 2021-07-14 01:04:16 +0200 | acidjnk | (~acidjnk@p200300d0c72b9557fc98475d99842c11.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2021-07-14 01:04:28 +0200 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 2021-07-14 01:05:20 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:b510:a429:9a65:bf36) |
| 2021-07-14 01:07:20 +0200 | derelict | (~derelict@user/derelict) |
| 2021-07-14 01:07:25 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:b510:a429:9a65:bf36) (Client Quit) |
| 2021-07-14 01:13:22 +0200 | juhp | (~juhp@128.106.188.66) (Quit: juhp) |
| 2021-07-14 01:13:35 +0200 | juhp | (~juhp@128.106.188.66) |
| 2021-07-14 01:20:09 +0200 | warnz | (~warnz@2600:1700:77c0:5610:9856:f279:a598:9845) (Remote host closed the connection) |
| 2021-07-14 01:22:56 +0200 | o1lo01ol_ | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) (Remote host closed the connection) |
| 2021-07-14 01:28:51 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) (ERC (IRC client for Emacs 28.0.50)) |
| 2021-07-14 01:31:37 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2021-07-14 01:32:23 +0200 | warnz | (~warnz@2600:1700:77c0:5610:9856:f279:a598:9845) |
| 2021-07-14 01:32:29 +0200 | warnz | (~warnz@2600:1700:77c0:5610:9856:f279:a598:9845) (Remote host closed the connection) |
| 2021-07-14 01:34:34 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2021-07-14 01:34:40 +0200 | warnz | (~warnz@2600:1700:77c0:5610:9856:f279:a598:9845) |
| 2021-07-14 01:35:09 +0200 | machinedgod | (~machinedg@24.105.81.50) |
| 2021-07-14 01:39:25 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-07-14 01:40:17 +0200 | warnz | (~warnz@2600:1700:77c0:5610:9856:f279:a598:9845) (Remote host closed the connection) |
| 2021-07-14 01:41:24 +0200 | zebrag | (~chris@user/zebrag) (Ping timeout: 256 seconds) |
| 2021-07-14 01:42:20 +0200 | zebrag | (~chris@user/zebrag) |
| 2021-07-14 01:44:35 +0200 | jess | (~jess@libera/staff/jess) () |
| 2021-07-14 01:46:01 +0200 | smtnet3 | (~asdfasdfa@202.36.244.25) (Quit: Leaving) |
| 2021-07-14 01:46:38 +0200 | dajoer | (~david@user/gvx) |
| 2021-07-14 01:47:58 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-14 01:51:41 +0200 | dre | (~dre@2001:8003:c932:c301:b299:b352:c4c4:74a1) (Quit: Leaving) |
| 2021-07-14 01:52:03 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 01:52:59 +0200 | cjb | (~cjb@user/cjb) |
| 2021-07-14 01:55:45 +0200 | Atum__ | (IRC@user/atum/x-2392232) (Quit: Atum__) |
| 2021-07-14 02:00:42 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 272 seconds) |
| 2021-07-14 02:03:43 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 244 seconds) |
| 2021-07-14 02:04:27 +0200 | gentauro | (~gentauro@user/gentauro) |
| 2021-07-14 02:04:40 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2021-07-14 02:05:15 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-07-14 02:08:03 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Quit: Lost terminal) |
| 2021-07-14 02:08:13 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) |
| 2021-07-14 02:09:47 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-14 02:12:45 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) (Ping timeout: 255 seconds) |
| 2021-07-14 02:13:04 +0200 | hseg | (~gesh@185.120.126.10) (Quit: WeeChat 3.2) |
| 2021-07-14 02:13:48 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 02:14:19 +0200 | silverwhitefish | (~hidden@47.202.102.10) (Quit: One for all, all for One (2 Corinthians 5)) |
| 2021-07-14 02:16:18 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) (Ping timeout: 272 seconds) |
| 2021-07-14 02:16:48 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) (Ping timeout: 268 seconds) |
| 2021-07-14 02:26:26 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 272 seconds) |
| 2021-07-14 02:27:25 +0200 | fryguybob | (~fryguybob@cpe-74-65-31-113.rochester.res.rr.com) |
| 2021-07-14 02:27:58 +0200 | silverwhitefish | (~hidden@47.202.102.10) |
| 2021-07-14 02:31:04 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-14 02:31:42 +0200 | Guest3034 | (~mike@user/feetwind) (Quit: WeeChat 3.1) |
| 2021-07-14 02:31:54 +0200 | feetwind | (~mike@user/feetwind) |
| 2021-07-14 02:33:16 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 02:38:47 +0200 | <hololeap> | every person has exactly two biological parents... is that a reasonable enough assumption? |
| 2021-07-14 02:39:11 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) |
| 2021-07-14 02:40:46 +0200 | <geekosaur> | for genetics yes, for other aspects no |
| 2021-07-14 02:41:11 +0200 | <geekosaur> | and the biological parents may be unrelated to the familial parents |
| 2021-07-14 02:41:46 +0200 | <hololeap> | That's why I specified _biological_ parents |
| 2021-07-14 02:42:09 +0200 | <hololeap> | I'd be interested in hearing of a case where someone didn't have exactly two biological parents |
| 2021-07-14 02:42:15 +0200 | <hololeap> | cloning? |
| 2021-07-14 02:42:43 +0200 | <hololeap> | someone = an individual of the homo-sapeins species |
| 2021-07-14 02:43:32 +0200 | <geekosaur> | actually davean's earlier comment implied unexpected complexity |
| 2021-07-14 02:44:35 +0200 | <hololeap> | I understand that it wouldn't necessarily make a nice binary tree all the way up, but I'm wondering if we can at least hold it as axiomatic that each individual has exactly two biological parents |
| 2021-07-14 02:45:37 +0200 | <davean> | geekosaur: well, consider if you had an egg donated, but used the birthing mother's nucleus with some male's sperm. We're up to 3 now. And that differs mitocondrially |
| 2021-07-14 02:45:44 +0200 | <davean> | geekosaur: Thats a simple case |
| 2021-07-14 02:45:55 +0200 | <geekosaur> | was considering raising that case |
| 2021-07-14 02:46:03 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 255 seconds) |
| 2021-07-14 02:46:06 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) |
| 2021-07-14 02:46:16 +0200 | <hololeap> | I would think the egg and sperm donors would be the two in that case |
| 2021-07-14 02:46:42 +0200 | <davean> | hololeap: nope, the nucleous provide's materal DNS also |
| 2021-07-14 02:46:57 +0200 | <davean> | You've got 3 clear DNA sources |
| 2021-07-14 02:47:05 +0200 | <davean> | all providing seperate DNA |
| 2021-07-14 02:47:19 +0200 | <hololeap> | I guess you could argue that the blood from the surrugate mother would be in the fetus as well |
| 2021-07-14 02:47:31 +0200 | <davean> | No, no, I'm talking clearer than that here |
| 2021-07-14 02:47:48 +0200 | <davean> | I wasn't even talking about a surrugate - though that can matter also of course |
| 2021-07-14 02:47:53 +0200 | <davean> | also, can I remind you of chimeras? |
| 2021-07-14 02:48:01 +0200 | <hololeap> | lol |
| 2021-07-14 02:48:26 +0200 | <davean> | They happen |
| 2021-07-14 02:48:43 +0200 | <davean> | ANYWAY, parents are complicated |
| 2021-07-14 02:49:05 +0200 | <hololeap> | I'm definitely not trying to mock... but what do you mean by chimeras? |
| 2021-07-14 02:49:22 +0200 | <davean> | hololeap: chimeras are where multiple zygotes merge and form one individual |
| 2021-07-14 02:49:42 +0200 | <hololeap> | oh... ok. I thought you meant like a human-animal hybrid |
| 2021-07-14 02:49:50 +0200 | <davean> | No, its a human-human hybrid |
| 2021-07-14 02:49:56 +0200 | <davean> | So maybe you're you, but your liver is your unborn sister. |
| 2021-07-14 02:49:57 +0200 | MQ-17J | (~MQ-17J@8.21.10.15) |
| 2021-07-14 02:50:15 +0200 | <davean> | Or maybe your unborn half brother |
| 2021-07-14 02:50:16 +0200 | <hololeap> | No, I've never heard of that and that's really interesting |
| 2021-07-14 02:50:46 +0200 | <davean> | Look, this is REALLY complicated. And some politicans got together and decided what data would go on the forms |
| 2021-07-14 02:50:59 +0200 | <davean> | :) |
| 2021-07-14 02:51:03 +0200 | <davean> | The best way to make a standard |
| 2021-07-14 02:51:16 +0200 | <hololeap> | fair enough. I just wanted to find a model that would make sense, but it sounds like it can get really bizarre |
| 2021-07-14 02:51:27 +0200 | <davean> | REALLY bizar |
| 2021-07-14 02:51:52 +0200 | <davean> | You could have mitocondria from one person, male and female donated from 2 others, and be a chimera |
| 2021-07-14 02:51:54 +0200 | <davean> | Who the fuck knows |
| 2021-07-14 02:52:09 +0200 | <hololeap> | where can I read more about this? |
| 2021-07-14 02:52:26 +0200 | <davean> | Uh, no idea |
| 2021-07-14 02:52:35 +0200 | <davean> | https://en.wikipedia.org/wiki/Chimera_(genetics) has a section on human chimeras |
| 2021-07-14 02:52:43 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-14 02:52:47 +0200 | <davean> | the first example has shown up in IVF |
| 2021-07-14 02:53:13 +0200 | <davean> | uh, I only know about this because I had to descamble genetics databases for a genetics lab information management tool back in the day |
| 2021-07-14 02:53:35 +0200 | <hololeap> | that's cool. you have first-hand evidence |
| 2021-07-14 02:54:20 +0200 | <davean> | oh huh, wikipedia says, after I got out of this, there DID become human-animal chimeras |
| 2021-07-14 02:54:23 +0200 | <davean> | well thats a thing |
| 2021-07-14 02:54:38 +0200 | <davean> | So yah, your parents might even be different species I guess |
| 2021-07-14 02:54:44 +0200 | <davean> | Thats even more complicated than I knew of! |
| 2021-07-14 02:55:19 +0200 | <davean> | hololeap: oh this actually suggests a REALLY simple case I didn't even think of! Organ donation |
| 2021-07-14 02:55:30 +0200 | <davean> | I mean not what people generally mean here, but in a medical sense it matters |
| 2021-07-14 02:58:23 +0200 | <davean> | hololeap: https://www.statnews.com/2019/01/24/first-trial-of-three-person-ivf-for-infertility/ here is the origional case I listed, or a way it happens |
| 2021-07-14 02:58:35 +0200 | lbseale | (~lbseale@user/ep1ctetus) (Read error: Connection reset by peer) |
| 2021-07-14 02:58:49 +0200 | <davean> | I don't know how much you know about biology, I was guessing not much sine the initial example seemed to miss, but that could be how I said it |
| 2021-07-14 02:59:07 +0200 | <davean> | basicly mitochondria are seperate "sub cells" with their own genetics |
| 2021-07-14 02:59:28 +0200 | <davean> | seperate from what you generally think of as "your DNA" from your basic bio classes in HS |
| 2021-07-14 02:59:57 +0200 | <davean> | and its purely matrolineal (under normal circumstances! One COULD swap them out from the father of course if done on purpose!) |
| 2021-07-14 03:04:12 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 03:04:18 +0200 | Guest6176 | (~Guest61@2001:ac8:27:20::a01e) (Quit: Client closed) |
| 2021-07-14 03:05:18 +0200 | bitmapper | (uid464869@id-464869.tooting.irccloud.com) |
| 2021-07-14 03:13:37 +0200 | nate1 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 03:15:11 +0200 | zeenk | (~zeenk@2a02:2f04:a106:9600:82fb:aed9:ca9:38d3) (Quit: Konversation terminated!) |
| 2021-07-14 03:15:15 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-14 03:16:05 +0200 | notzmv | (~zmv@user/notzmv) |
| 2021-07-14 03:18:11 +0200 | <hololeap> | I'm not that familiar with that level of human biology, mostly just the basic stuff that you mentioned from HS. I know a bit more about botany and I know that can get really bizarre as well |
| 2021-07-14 03:18:34 +0200 | <yin[m]> | this is hilariously creepy https://www.youtube.com/watch?v=Kw0AEtrr7E0 |
| 2021-07-14 03:19:05 +0200 | smichel17 | (~smichel17@2601:193:8300:4b9::600) (Quit: smichel17) |
| 2021-07-14 03:23:27 +0200 | machinedgod | (~machinedg@24.105.81.50) (Ping timeout: 265 seconds) |
| 2021-07-14 03:23:46 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) |
| 2021-07-14 03:25:10 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 03:27:25 +0200 | <hololeap> | davean: I thought of organ donation after you mentioned the possibility of my liver being from a different zygote, and it ties into that whole philosophical dilemma of when a person stops being human after N bionic body replacements |
| 2021-07-14 03:27:25 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 244 seconds) |
| 2021-07-14 03:28:04 +0200 | <davean> | stops being human? I'd think the question would be when they stop being the same human |
| 2021-07-14 03:28:28 +0200 | <geekosaur> | "bionic" |
| 2021-07-14 03:29:10 +0200 | xff0x | (~xff0x@2001:1a81:5314:1800:204a:df94:d24b:de67) (Ping timeout: 246 seconds) |
| 2021-07-14 03:29:32 +0200 | <hololeap> | there's a futurama episode that goes into this :) |
| 2021-07-14 03:29:34 +0200 | <geekosaur> | kinda odd to consider a human in the context of the ship of Theseus |
| 2021-07-14 03:30:07 +0200 | <davean> | geekosaur: I don't find it odd at all - or I find it odd to consider a person is the same person over any period of time thats non-negligable |
| 2021-07-14 03:30:28 +0200 | <davean> | if someone doesn't change, they're not really worth considering much of a person, are they? |
| 2021-07-14 03:30:53 +0200 | <davean> | if they don't act, or think like they did, how would you determin they're the same? |
| 2021-07-14 03:31:02 +0200 | xff0x | (~xff0x@2001:1a81:5355:ca00:f556:f8e3:c42f:ffef) |
| 2021-07-14 03:31:08 +0200 | <geekosaur> | I'm actually on your side of that argument, but their body parts have continuity even though they have changed |
| 2021-07-14 03:31:19 +0200 | <geekosaur> | (cells already do the ship of theseus thing) |
| 2021-07-14 03:31:32 +0200 | <nshepperd> | a human is the squishy thing in the skull. the rest is just scaffolding |
| 2021-07-14 03:32:46 +0200 | <hololeap> | I read about cases of people taking on their donors memories after getting an organ transplant... not sure if it's true or not, but interesting to consider nonetheless |
| 2021-07-14 03:33:34 +0200 | nate1 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 272 seconds) |
| 2021-07-14 03:34:50 +0200 | bontaq | (~user@ool-18e47f8d.dyn.optonline.net) (Ping timeout: 272 seconds) |
| 2021-07-14 03:35:10 +0200 | shriekingnoise | (~shrieking@186.137.144.80) (ERC (IRC client for Emacs 28.0.50)) |
| 2021-07-14 03:36:29 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) |
| 2021-07-14 03:37:23 +0200 | son0p | (~ff@181.136.122.143) (Remote host closed the connection) |
| 2021-07-14 03:37:38 +0200 | <hololeap> | geekosaur: I'm reading about the ship of Thesus, and it seems like the quintessential thought experiment in regards to what I mentioned about bionic body replacement |
| 2021-07-14 03:38:06 +0200 | <geekosaur> | probably what the futurama ep was riffing on |
| 2021-07-14 03:38:29 +0200 | <hololeap> | yeah probably |
| 2021-07-14 03:38:58 +0200 | nate1 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 03:39:44 +0200 | <dexterfoo> | is attoparsec still a good choice (efficient) if i don't need any backtracking? |
| 2021-07-14 03:40:38 +0200 | <hololeap> | dexterfoo: I think so, but megaparsec is supposed to have similar efficiency... someone else can probably go into more detail on this |
| 2021-07-14 03:42:25 +0200 | <davean> | dexterfoo: attoparsec forces copying in its buffer |
| 2021-07-14 03:42:45 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) (Ping timeout: 255 seconds) |
| 2021-07-14 03:43:42 +0200 | <davean> | For many cases you can get faster elsewhere. I've had to add functions to attoparsec to keep acceptable performance vs. other things, but I haven't done side-by-side benchmarks with other standard offerings lately. I'd suspect attoparsec losses though - it certainly loses in many cases against naive implimentations. |
| 2021-07-14 03:44:01 +0200 | <davean> | I'm moving everything off attoparsec slowly |
| 2021-07-14 03:45:01 +0200 | renzhi | (~xp@2607:fa49:655f:a700::8b9f) |
| 2021-07-14 03:45:30 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2021-07-14 03:45:43 +0200 | stevenxl | (~stevenlei@66.63.167.105) |
| 2021-07-14 03:46:18 +0200 | stevenxl | (~stevenlei@66.63.167.105) (Client Quit) |
| 2021-07-14 03:49:03 +0200 | <dexterfoo> | davean: to which library? |
| 2021-07-14 03:50:05 +0200 | stevenxl | (uid133530@id-133530.highgate.irccloud.com) |
| 2021-07-14 03:50:15 +0200 | <davean> | I didn't imply to a specific library. I just ran the parse combinators against a 'machines' stream and removed the duplication of having a parser library for most of the stuff I was doing, because my core inefficiency was due to poor buffer management in attoparsec, but "more appropriate things" I have no reason to move to one specific thing to solve all my problems. |
| 2021-07-14 03:51:00 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) |
| 2021-07-14 03:51:57 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 276 seconds) |
| 2021-07-14 03:55:16 +0200 | <hololeap> | dexterfoo: I think it would be a good idea to compare it to megaparsec at the very least. also check out megaparsec's github page because there are some benchmark results on there |
| 2021-07-14 03:56:31 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) |
| 2021-07-14 03:57:06 +0200 | <dexterfoo> | ok, but i am parsing streaming data with conduit, which has a Data.Conduit.Attoparsec module, but there is no megaparsec integration |
| 2021-07-14 03:57:09 +0200 | nate1 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 255 seconds) |
| 2021-07-14 03:59:41 +0200 | <davean> | A) ok, great B) why would you need to to make that explicitely? C) if you just want it to be easy, use what you have at hand? |
| 2021-07-14 04:01:26 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) (Ping timeout: 272 seconds) |
| 2021-07-14 04:02:02 +0200 | nate1 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 04:02:04 +0200 | <dexterfoo> | i am using attoparsec and it works and is easy, but i am wondering if there is a faster way |
| 2021-07-14 04:03:37 +0200 | <stevenxl> | Hey folks. I have a newtype wrapper around a list of Ints, and I'd like a property test that if the list contains the number 1 in it, I get back the result `One`. |
| 2021-07-14 04:03:42 +0200 | <davean> | Oh theres a definately a faster way |
| 2021-07-14 04:03:49 +0200 | <stevenxl> | I wrote a quick script just to show what I mean: |
| 2021-07-14 04:03:58 +0200 | <davean> | attoparsec can't be anywhere NEAR the fastest - parse theory tells us that, its the wrong structure |
| 2021-07-14 04:04:01 +0200 | <stevenxl> | https://www.irccloud.com/pastebin/MPAt1waK/ |
| 2021-07-14 04:04:26 +0200 | <stevenxl> | Of course, the problem is that the instance of `Arbitrary` that I have created will always add one to the head of the list. |
| 2021-07-14 04:04:47 +0200 | <stevenxl> | I'd like to add it at the head, the tail, or somewhere in-between randomly. |
| 2021-07-14 04:05:02 +0200 | <davean> | stevenxl: filter? |
| 2021-07-14 04:05:19 +0200 | <stevenxl> | davean: Sorry. I'm not following you. |
| 2021-07-14 04:05:20 +0200 | <Axman6> | generate a random number between 0 and length list and insert it at that location |
| 2021-07-14 04:05:38 +0200 | <davean> | stevenxl: you can make sure 1 isn't in the list easily, you can also check if 1 is in the list easily, thus you can construct both cases |
| 2021-07-14 04:05:49 +0200 | <davean> | you can also randomly sort the list |
| 2021-07-14 04:05:59 +0200 | <stevenxl> | Axman6: Thanks. That's what I think I need! |
| 2021-07-14 04:06:24 +0200 | <Axman6> | do { list <- arbitrary; idx <- choose (0,length list); pure $ ContainsOne (insert idx 1 list) } -- you might need to write insert |
| 2021-07-14 04:06:45 +0200 | <stevenxl> | Axman6: perfect. |
| 2021-07-14 04:06:49 +0200 | <Axman6> | and you'll probably need to look up the correct name for choose |
| 2021-07-14 04:07:05 +0200 | <stevenxl> | Yup - I can look that up in the quickcheck docs / generator section. |
| 2021-07-14 04:09:17 +0200 | Guest43 | (~Guest43@187.83.249.216.dyn.smithville.net) |
| 2021-07-14 04:11:34 +0200 | thonkpod | (~thonkpod@user/thonkpod) (Ping timeout: 256 seconds) |
| 2021-07-14 04:17:24 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) (Ping timeout: 255 seconds) |
| 2021-07-14 04:17:46 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) |
| 2021-07-14 04:18:22 +0200 | td_ | (~td@94.134.91.7) (Ping timeout: 256 seconds) |
| 2021-07-14 04:19:08 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2021-07-14 04:19:08 +0200 | FinnElija | Guest2571 |
| 2021-07-14 04:19:08 +0200 | Guest2571 | (~finn_elij@user/finn-elija/x-0085643) (Killed (sodium.libera.chat (Nickname regained by services))) |
| 2021-07-14 04:19:08 +0200 | finn_elija | FinnElija |
| 2021-07-14 04:19:49 +0200 | td_ | (~td@muedsl-82-207-238-063.citykom.de) |
| 2021-07-14 04:22:42 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 04:26:14 +0200 | phma | (phma@2001:5b0:211f:8638:196:5581:d6d8:1f7e) (Remote host closed the connection) |
| 2021-07-14 04:26:43 +0200 | phma | (~phma@2001:5b0:211f:8638:196:5581:d6d8:1f7e) |
| 2021-07-14 04:34:03 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) (Ping timeout: 255 seconds) |
| 2021-07-14 04:36:40 +0200 | thonkpod | (~thonkpod@user/thonkpod) |
| 2021-07-14 04:38:56 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 258 seconds) |
| 2021-07-14 04:41:30 +0200 | shriekingnoise | (~shrieking@186.137.144.80) |
| 2021-07-14 04:44:37 +0200 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2021-07-14 04:53:24 +0200 | MQ-17J | (~MQ-17J@8.21.10.15) (Ping timeout: 255 seconds) |
| 2021-07-14 04:57:00 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 255 seconds) |
| 2021-07-14 04:57:29 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-14 05:01:37 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) |
| 2021-07-14 05:03:18 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-14 05:08:33 +0200 | FixedPointDude | (~FixedPoin@204.237.49.106) (Quit: Client closed) |
| 2021-07-14 05:09:57 +0200 | <dsal> | stevenxl: arbitrary = notOnes >>= \a -> notOnes >>= \b -> pure $ a <> [1] <> b |
| 2021-07-14 05:10:28 +0200 | <Axman6> | notOnes could just be arbitrary |
| 2021-07-14 05:10:42 +0200 | <Axman6> | all that's needed is that it contains a one, not that it contains only one one |
| 2021-07-14 05:10:55 +0200 | <dsal> | Where notOnes = arbitrary `suchThat` (notElem 1) |
| 2021-07-14 05:11:00 +0200 | <dsal> | Oh, then yeah |
| 2021-07-14 05:11:37 +0200 | <Axman6> | concat <$> sequence [arbitrary, pure [1], arbitrary] |
| 2021-07-14 05:12:03 +0200 | <dsal> | Yeah. That's a good one. |
| 2021-07-14 05:12:19 +0200 | <dsal> | I'm on a phone with part of my brain missing. :) |
| 2021-07-14 05:15:55 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) (Quit: WeeChat 2.8) |
| 2021-07-14 05:16:08 +0200 | <Axman6> | It was a good team effort |
| 2021-07-14 05:16:16 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-14 05:16:21 +0200 | nate1 | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 255 seconds) |
| 2021-07-14 05:17:54 +0200 | swistak | (~swistak@185.21.216.141) (Ping timeout: 252 seconds) |
| 2021-07-14 05:19:32 +0200 | <stevenxl> | Great team effort! |
| 2021-07-14 05:19:35 +0200 | <stevenxl> | lol. Thank you all. |
| 2021-07-14 05:21:55 +0200 | alx741 | (~alx741@186.178.109.32) (Quit: alx741) |
| 2021-07-14 05:21:56 +0200 | swistak | (~swistak@185.21.216.141) |
| 2021-07-14 05:24:49 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 05:25:22 +0200 | derelict | (~derelict@user/derelict) (Ping timeout: 246 seconds) |
| 2021-07-14 05:29:51 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 255 seconds) |
| 2021-07-14 05:30:24 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-14 05:30:34 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2021-07-14 05:33:40 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 05:34:31 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-07-14 05:34:55 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-07-14 05:35:15 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-14 05:37:57 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-14 05:40:16 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-07-14 05:40:45 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-07-14 05:41:03 +0200 | warnz | (~warnz@2600:1700:77c0:5610:9856:f279:a598:9845) |
| 2021-07-14 05:43:29 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 05:43:45 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 276 seconds) |
| 2021-07-14 05:43:51 +0200 | cheater1__ | cheater |
| 2021-07-14 05:45:36 +0200 | warnz | (~warnz@2600:1700:77c0:5610:9856:f279:a598:9845) (Ping timeout: 255 seconds) |
| 2021-07-14 05:47:30 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) |
| 2021-07-14 05:50:06 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) (Ping timeout: 255 seconds) |
| 2021-07-14 05:51:46 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) (Ping timeout: 258 seconds) |
| 2021-07-14 05:54:46 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-14 05:55:30 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-14 05:57:50 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-14 06:08:14 +0200 | wei2912 | (~wei2912@112.199.250.21) |
| 2021-07-14 06:09:11 +0200 | img | (~img@user/img) |
| 2021-07-14 06:19:04 +0200 | anandprabhu | (~anandprab@94.202.243.198) |
| 2021-07-14 06:21:47 +0200 | isekaijin | (~pyon@user/pyon) (Ping timeout: 255 seconds) |
| 2021-07-14 06:22:34 +0200 | <Guest43> | so I know GHC doesn't remember type information at runtime, does that mean it turns everything like identity :: [Wrap1 a] -> [Wrap2 a] into a noop? |
| 2021-07-14 06:24:05 +0200 | isekaijin | (~pyon@user/pyon) |
| 2021-07-14 06:24:29 +0200 | <Guest43> | specifically if a function performs no term-level operation, will GHC reliably recognize that? |
| 2021-07-14 06:25:45 +0200 | anandprabhu | (~anandprab@94.202.243.198) (Remote host closed the connection) |
| 2021-07-14 06:28:48 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-14 06:29:13 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-14 06:30:16 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Ping timeout: 272 seconds) |
| 2021-07-14 06:48:34 +0200 | <Axman6> | I don't think so |
| 2021-07-14 06:49:14 +0200 | <Axman6> | I know GHC has several RULES defined for removing id specifically if it's used somewhere where it would be a no-op (though these days coersions are probably where the preferred way to do that) |
| 2021-07-14 06:53:06 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-14 06:53:50 +0200 | <Guest43> | i see; so use id/coerce if I can, but no guarantees it won't traverse the list anyway at runtime? |
| 2021-07-14 06:55:21 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-14 06:55:48 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) (Ping timeout: 255 seconds) |
| 2021-07-14 06:57:26 +0200 | <Axman6> | yeah, that's basically exactly the usecase (and most used example) of why the safe coersions stuff exists. worth reading the paper, it's very approachable |
| 2021-07-14 06:58:13 +0200 | <Guest43> | cool thanks, and yeah i'll check it out |
| 2021-07-14 07:00:27 +0200 | peterhil | (~peterhil@dsl-hkibng32-54f849-252.dhcp.inet.fi) (Ping timeout: 276 seconds) |
| 2021-07-14 07:03:08 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 252 seconds) |
| 2021-07-14 07:04:01 +0200 | beka | (~beka@104-244-27-23.static.monkeybrains.net) |
| 2021-07-14 07:04:04 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 246 seconds) |
| 2021-07-14 07:04:33 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) |
| 2021-07-14 07:04:35 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-14 07:05:28 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:500a:f04e:5614:56a9) |
| 2021-07-14 07:06:04 +0200 | azeem | (~azeem@dynamic-adsl-84-220-226-129.clienti.tiscali.it) (Ping timeout: 252 seconds) |
| 2021-07-14 07:12:31 +0200 | smitop | (~smitop@user/smitop) (Ping timeout: 268 seconds) |
| 2021-07-14 07:12:54 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-14 07:15:19 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-14 07:18:57 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-14 07:23:29 +0200 | smitop | (~smitop@user/smitop) |
| 2021-07-14 07:23:46 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 258 seconds) |
| 2021-07-14 07:24:50 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-07-14 07:25:18 +0200 | slowButPresent | (~slowButPr@user/slowbutpresent) (Quit: leaving) |
| 2021-07-14 07:25:32 +0200 | chris-the-slurpa | (~chris@81.96.113.213) |
| 2021-07-14 07:25:43 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 07:30:00 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Ping timeout: 255 seconds) |
| 2021-07-14 07:33:22 +0200 | wallymathieu | (~wallymath@81-234-151-21-no94.tbcn.telia.com) |
| 2021-07-14 07:35:40 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) |
| 2021-07-14 07:35:52 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) |
| 2021-07-14 07:36:11 +0200 | sheepduck | (~sheepduck@user/sheepduck) |
| 2021-07-14 07:40:07 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) (Ping timeout: 246 seconds) |
| 2021-07-14 07:42:35 +0200 | Pickchea | (~private@user/pickchea) |
| 2021-07-14 07:44:19 +0200 | mikoto-chan | (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) |
| 2021-07-14 07:46:50 +0200 | azeem | (~azeem@dynamic-adsl-84-220-239-177.clienti.tiscali.it) |
| 2021-07-14 07:48:13 +0200 | xsperry | (~as@user/xsperry) () |
| 2021-07-14 07:48:41 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 258 seconds) |
| 2021-07-14 07:52:01 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-14 07:52:40 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) (Ping timeout: 265 seconds) |
| 2021-07-14 07:55:32 +0200 | mikoto-chan | (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) (Ping timeout: 245 seconds) |
| 2021-07-14 07:56:08 +0200 | xsperry | (~as@user/xsperry) |
| 2021-07-14 07:58:48 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-14 07:59:05 +0200 | Obo | (~roberto@70.pool90-171-81.dynamic.orange.es) |
| 2021-07-14 07:59:48 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 258 seconds) |
| 2021-07-14 08:00:36 +0200 | berberman | (~berberman@user/berberman) |
| 2021-07-14 08:00:58 +0200 | jneira | (~jneira@212.8.115.226) |
| 2021-07-14 08:01:03 +0200 | berberman_ | (~berberman@user/berberman) (Ping timeout: 255 seconds) |
| 2021-07-14 08:03:43 +0200 | EvanR | (~evan@mail.evanr.info) (Changing host) |
| 2021-07-14 08:03:43 +0200 | EvanR | (~evan@user/evanr) |
| 2021-07-14 08:06:10 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
| 2021-07-14 08:07:10 +0200 | paddymahoney | (~paddymaho@cpe9050ca207f83-cm9050ca207f80.cpe.net.cable.rogers.com) (Ping timeout: 265 seconds) |
| 2021-07-14 08:13:15 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 08:17:19 +0200 | azeem | (~azeem@dynamic-adsl-84-220-239-177.clienti.tiscali.it) (Ping timeout: 265 seconds) |
| 2021-07-14 08:19:06 +0200 | paddymahoney | (~paddymaho@cpe9050ca207f83-cm9050ca207f80.cpe.net.cable.rogers.com) |
| 2021-07-14 08:25:25 +0200 | azeem | (~azeem@dynamic-adsl-84-220-239-177.clienti.tiscali.it) |
| 2021-07-14 08:28:53 +0200 | chele | (~chele@user/chele) |
| 2021-07-14 08:33:27 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 245 seconds) |
| 2021-07-14 08:36:00 +0200 | mikoto-chan | (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) |
| 2021-07-14 08:47:35 +0200 | prite | (~pritam@user/pritambaral) |
| 2021-07-14 08:52:42 +0200 | anandprabhu | (~anandprab@94.202.243.198) |
| 2021-07-14 08:53:57 +0200 | fendor | (~fendor@77.119.210.250.wireless.dyn.drei.com) |
| 2021-07-14 08:54:19 +0200 | Guest2168 | (~Guest21@187.83.249.216.dyn.smithville.net) (Ping timeout: 246 seconds) |
| 2021-07-14 08:54:40 +0200 | Guest43 | (~Guest43@187.83.249.216.dyn.smithville.net) (Ping timeout: 246 seconds) |
| 2021-07-14 09:03:42 +0200 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) |
| 2021-07-14 09:04:44 +0200 | cjb | (~cjb@user/cjb) (Quit: rcirc on GNU Emacs 28.0.50) |
| 2021-07-14 09:07:16 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 258 seconds) |
| 2021-07-14 09:07:33 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-14 09:08:01 +0200 | pesada | (~agua@2804:18:4f:750a:1:0:192e:7017) |
| 2021-07-14 09:10:27 +0200 | agua | (~agua@2804:18:46:bafa:1:0:1551:7319) (Ping timeout: 276 seconds) |
| 2021-07-14 09:12:15 +0200 | eight | (~eight@user/eight) |
| 2021-07-14 09:15:43 +0200 | acidjnk | (~acidjnk@p200300d0c72b9557fc98475d99842c11.dip0.t-ipconnect.de) |
| 2021-07-14 09:16:15 +0200 | acidjnk_new | (~acidjnk@p200300d0c72b9557e15cb996b96a0953.dip0.t-ipconnect.de) |
| 2021-07-14 09:17:06 +0200 | Gurkenglas_ | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) |
| 2021-07-14 09:19:12 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2021-07-14 09:19:32 +0200 | beka | (~beka@104-244-27-23.static.monkeybrains.net) (Ping timeout: 252 seconds) |
| 2021-07-14 09:20:07 +0200 | acidjnk | (~acidjnk@p200300d0c72b9557fc98475d99842c11.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2021-07-14 09:20:10 +0200 | epolanski | (uid312403@id-312403.brockwell.irccloud.com) |
| 2021-07-14 09:20:30 +0200 | shriekingnoise | (~shrieking@186.137.144.80) (Quit: Quit) |
| 2021-07-14 09:24:12 +0200 | fef | (~thedawn@user/thedawn) |
| 2021-07-14 09:25:17 +0200 | prite | (~pritam@user/pritambaral) (Ping timeout: 258 seconds) |
| 2021-07-14 09:27:01 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) (Remote host closed the connection) |
| 2021-07-14 09:28:33 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2021-07-14 09:31:29 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2021-07-14 09:45:09 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 09:48:51 +0200 | prite | (~pritam@user/pritambaral) |
| 2021-07-14 09:52:14 +0200 | bens | (~bens@www.typius.com) (Ping timeout: 268 seconds) |
| 2021-07-14 09:52:27 +0200 | bens | (~bens@www.typius.com) |
| 2021-07-14 09:53:44 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-07-14 09:55:19 +0200 | smitop | (~smitop@user/smitop) (Ping timeout: 268 seconds) |
| 2021-07-14 09:55:30 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-14 09:58:00 +0200 | nattiestnate | (~nate@36.70.197.105) |
| 2021-07-14 10:06:15 +0200 | hendursa1 | (~weechat@user/hendursaga) |
| 2021-07-14 10:06:56 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection) |
| 2021-07-14 10:08:52 +0200 | hendursaga | (~weechat@user/hendursaga) (Ping timeout: 244 seconds) |
| 2021-07-14 10:09:10 +0200 | michalz | (~michalz@185.246.204.60) |
| 2021-07-14 10:10:12 +0200 | smitop | (~smitop@user/smitop) |
| 2021-07-14 10:10:12 +0200 | arahael1 | (~arahael@203-206-95-20.tpgi.com.au) |
| 2021-07-14 10:10:39 +0200 | TheRAt | (~TheRAt@user/therat) (Quit: :)) |
| 2021-07-14 10:10:47 +0200 | sheepduck | (~sheepduck@user/sheepduck) (Quit: Konversation terminated!) |
| 2021-07-14 10:11:21 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2021-07-14 10:12:21 +0200 | arahael | (~arahael@118.211.182.212) (Ping timeout: 265 seconds) |
| 2021-07-14 10:16:48 +0200 | hegstal | (~hegstal@2a02:c7f:7604:8a00:cd80:9697:e922:dc30) |
| 2021-07-14 10:17:30 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-07-14 10:17:55 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-07-14 10:18:23 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) |
| 2021-07-14 10:18:30 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) (Remote host closed the connection) |
| 2021-07-14 10:18:42 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) |
| 2021-07-14 10:19:15 +0200 | delYsid | (~user@zidpc777.tugraz.at) |
| 2021-07-14 10:21:57 +0200 | peterhil | (~peterhil@dsl-hkibng32-54f849-252.dhcp.inet.fi) |
| 2021-07-14 10:22:45 +0200 | arahael1 | arahael |
| 2021-07-14 10:23:27 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 245 seconds) |
| 2021-07-14 10:23:38 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-07-14 10:23:59 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-14 10:24:00 +0200 | phma | (~phma@2001:5b0:211f:8638:196:5581:d6d8:1f7e) (Read error: Connection reset by peer) |
| 2021-07-14 10:24:13 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-14 10:25:41 +0200 | smitop | (~smitop@user/smitop) (Ping timeout: 255 seconds) |
| 2021-07-14 10:25:58 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2021-07-14 10:25:59 +0200 | zeenk | (~zeenk@2a02:2f04:a106:9600:82fb:aed9:ca9:38d3) |
| 2021-07-14 10:26:44 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 272 seconds) |
| 2021-07-14 10:27:12 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2021-07-14 10:28:18 +0200 | prite | (~pritam@user/pritambaral) (Ping timeout: 265 seconds) |
| 2021-07-14 10:28:28 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-07-14 10:29:37 +0200 | prite | (~pritam@user/pritambaral) |
| 2021-07-14 10:30:48 +0200 | phma | (phma@2001:5b0:211b:8138:4237:c684:b0bd:87ec) |
| 2021-07-14 10:32:55 +0200 | ubert | (~Thunderbi@p2e5a50e5.dip0.t-ipconnect.de) |
| 2021-07-14 10:34:12 +0200 | martin02 | (silas@hund.fs.lmu.de) |
| 2021-07-14 10:35:03 +0200 | desophos | (~desophos@2601:249:1680:a570:489c:f364:abf0:5de7) (Quit: Leaving) |
| 2021-07-14 10:35:50 +0200 | _xor | (~xor@74.215.46.133) (Quit: brb) |
| 2021-07-14 10:37:12 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 255 seconds) |
| 2021-07-14 10:37:56 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-14 10:39:59 +0200 | smitop | (~smitop@user/smitop) |
| 2021-07-14 10:43:54 +0200 | nattiestnate | (~nate@36.70.197.105) (Quit: WeeChat 3.2) |
| 2021-07-14 10:44:49 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-07-14 10:45:18 +0200 | Patternmaster | (~georg@li1192-118.members.linode.com) (Remote host closed the connection) |
| 2021-07-14 10:48:02 +0200 | stevenxl | (uid133530@id-133530.highgate.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-14 10:49:05 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-07-14 10:51:10 +0200 | jippiedoe | (~david@2a02-a44c-e14e-1-1e76-24e-f48d-1c7a.fixed6.kpn.net) |
| 2021-07-14 10:51:18 +0200 | Patternmaster | (~georg@li1192-118.members.linode.com) |
| 2021-07-14 10:53:04 +0200 | zaquest | (~notzaques@5.128.210.178) (Remote host closed the connection) |
| 2021-07-14 10:54:11 +0200 | zaquest | (~notzaques@5.128.210.178) |
| 2021-07-14 10:54:41 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-14 10:56:00 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 10:58:37 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2021-07-14 10:59:26 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 272 seconds) |
| 2021-07-14 11:00:36 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 255 seconds) |
| 2021-07-14 11:01:47 +0200 | smitop | (~smitop@user/smitop) (Ping timeout: 245 seconds) |
| 2021-07-14 11:02:52 +0200 | smitop | (~smitop@user/smitop) |
| 2021-07-14 11:03:42 +0200 | juhp | (~juhp@128.106.188.66) (Quit: juhp) |
| 2021-07-14 11:03:56 +0200 | juhp | (~juhp@128.106.188.66) |
| 2021-07-14 11:05:54 +0200 | hgolden_ | (~hgolden2@cpe-172-114-84-61.socal.res.rr.com) (Ping timeout: 252 seconds) |
| 2021-07-14 11:07:54 +0200 | neceve | (~quassel@2a02:c7f:607e:d600:f762:20dd:304e:4b1f) |
| 2021-07-14 11:08:25 +0200 | delYsid | (~user@zidpc777.tugraz.at) (ERC (IRC client for Emacs 27.1.50)) |
| 2021-07-14 11:13:10 +0200 | juhp | (~juhp@128.106.188.66) (Quit: juhp) |
| 2021-07-14 11:14:15 +0200 | __monty__ | (~toonn@user/toonn) |
| 2021-07-14 11:14:16 +0200 | bitmapper | (uid464869@id-464869.tooting.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-14 11:15:13 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-07-14 11:17:43 +0200 | jumper149 | (~jumper149@80.240.31.34) |
| 2021-07-14 11:24:23 +0200 | elf_fortrez | (~elf_fortr@adsl-72-50-4-50.prtc.net) |
| 2021-07-14 11:25:20 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 244 seconds) |
| 2021-07-14 11:26:56 +0200 | ubert | (~Thunderbi@p2e5a50e5.dip0.t-ipconnect.de) (Quit: ubert) |
| 2021-07-14 11:27:40 +0200 | Pickchea | (~private@user/pickchea) |
| 2021-07-14 11:33:23 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-14 11:34:07 +0200 | fef | (~thedawn@user/thedawn) |
| 2021-07-14 11:37:19 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2021-07-14 11:37:37 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 245 seconds) |
| 2021-07-14 11:38:14 +0200 | mcglk | (~mcglk@131.191.49.120) (Read error: Connection reset by peer) |
| 2021-07-14 11:39:00 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) |
| 2021-07-14 11:39:16 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) (Remote host closed the connection) |
| 2021-07-14 11:40:27 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) |
| 2021-07-14 11:40:36 +0200 | koolazer | (~koo@user/koolazer) (Ping timeout: 272 seconds) |
| 2021-07-14 11:43:42 +0200 | koolazer | (~koo@user/koolazer) |
| 2021-07-14 11:43:42 +0200 | haykam1 | (~haykam@static.100.2.21.65.clients.your-server.de) (Remote host closed the connection) |
| 2021-07-14 11:43:55 +0200 | haykam1 | (~haykam@static.100.2.21.65.clients.your-server.de) |
| 2021-07-14 11:49:29 +0200 | ubert | (~Thunderbi@2a02:8109:9880:303c:ca5b:76ff:fe29:f233) |
| 2021-07-14 11:54:11 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2021-07-14 11:56:47 +0200 | wei2912 | (~wei2912@112.199.250.21) (Quit: Lost terminal) |
| 2021-07-14 12:05:52 +0200 | hnOsmium0001 | (uid453710@id-453710.stonehaven.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-14 12:10:42 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) (Remote host closed the connection) |
| 2021-07-14 12:11:25 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) |
| 2021-07-14 12:12:18 +0200 | fef | (~thedawn@user/thedawn) (Remote host closed the connection) |
| 2021-07-14 12:12:43 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) (Client Quit) |
| 2021-07-14 12:12:54 +0200 | fef | (~thedawn@user/thedawn) |
| 2021-07-14 12:13:07 +0200 | elf_fortrez | (~elf_fortr@adsl-72-50-4-50.prtc.net) (Ping timeout: 246 seconds) |
| 2021-07-14 12:15:36 +0200 | koolazer | (~koo@user/koolazer) (Ping timeout: 265 seconds) |
| 2021-07-14 12:15:46 +0200 | xsperry | (~as@user/xsperry) (Remote host closed the connection) |
| 2021-07-14 12:15:51 +0200 | wallymathieu | (~wallymath@81-234-151-21-no94.tbcn.telia.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-14 12:18:31 +0200 | neurocyte4042 | (~neurocyte@212.232.92.52) |
| 2021-07-14 12:18:32 +0200 | neurocyte4042 | (~neurocyte@212.232.92.52) (Changing host) |
| 2021-07-14 12:18:32 +0200 | neurocyte4042 | (~neurocyte@user/neurocyte) |
| 2021-07-14 12:20:33 +0200 | neurocyte4042 | neurocyte |
| 2021-07-14 12:23:37 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) |
| 2021-07-14 12:24:53 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) (Client Quit) |
| 2021-07-14 12:35:12 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) |
| 2021-07-14 12:35:18 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2021-07-14 12:43:52 +0200 | prite | (~pritam@user/pritambaral) (Ping timeout: 245 seconds) |
| 2021-07-14 12:45:14 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 12:46:22 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 245 seconds) |
| 2021-07-14 12:47:34 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2021-07-14 12:48:04 +0200 | prite | (~pritam@user/pritambaral) |
| 2021-07-14 12:48:57 +0200 | smichel17 | (~smichel17@c-73-68-217-18.hsd1.ma.comcast.net) |
| 2021-07-14 12:51:12 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2021-07-14 12:53:49 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 268 seconds) |
| 2021-07-14 12:57:27 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 13:02:02 +0200 | anandprabhu | (~anandprab@94.202.243.198) (Read error: Connection reset by peer) |
| 2021-07-14 13:03:01 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 258 seconds) |
| 2021-07-14 13:03:02 +0200 | oxide | (~lambda@user/oxide) (Ping timeout: 245 seconds) |
| 2021-07-14 13:05:00 +0200 | oxide | (~lambda@user/oxide) |
| 2021-07-14 13:07:31 +0200 | acidjnk_new3 | (~acidjnk@p200300d0c72b9516e15cb996b96a0953.dip0.t-ipconnect.de) |
| 2021-07-14 13:10:29 +0200 | Topsi | (~Tobias@dyndsl-095-033-020-123.ewe-ip-backbone.de) |
| 2021-07-14 13:10:31 +0200 | <yin[m]> | matrix down again. last message from 6h ago |
| 2021-07-14 13:10:32 +0200 | acidjnk_new | (~acidjnk@p200300d0c72b9557e15cb996b96a0953.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2021-07-14 13:16:43 +0200 | <tomsmeding> | yin[m]: on irc this was the last message https://ircbrowse.tomsmeding.com/browse/lchaskell?id=94477#trid94477 |
| 2021-07-14 13:16:48 +0200 | koolazer | (~koo@user/koolazer) |
| 2021-07-14 13:17:59 +0200 | silverwhitefish | (~hidden@47.202.102.10) (Quit: One for all, all for One (2 Corinthians 5)) |
| 2021-07-14 13:18:56 +0200 | <Topsi> | If I have the constraint (MyClass a, MyClass b, a ~ b), will this translate to 2 class-dictionaries passed at runtime or 1? Assuming both are used. |
| 2021-07-14 13:19:39 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 255 seconds) |
| 2021-07-14 13:19:43 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-07-14 13:22:33 +0200 | zdleaf | zinc |
| 2021-07-14 13:24:17 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-14 13:26:22 +0200 | Pickchea | (~private@user/pickchea) |
| 2021-07-14 13:33:53 +0200 | <tomsmeding> | Topsi: for a test with f :: (Show a, Show b, a ~ b) => a -> b -> String ; f x y = show x ++ show y, looking at the optimised Core only one dictionary is passed |
| 2021-07-14 13:34:27 +0200 | <tomsmeding> | if you want some guarantees, either look at the core yourself for the function you're interested in, or ask in #ghc :p |
| 2021-07-14 13:35:15 +0200 | <tomsmeding> | it does seem to take an additional actual argument for the equality constraint |
| 2021-07-14 13:37:12 +0200 | <tomsmeding> | ah it looks like that additional argument is a coercion, which I expect shouldn't have any runtime representation? But I don't know |
| 2021-07-14 13:38:22 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) |
| 2021-07-14 13:40:49 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-14 13:43:02 +0200 | eight | (~eight@user/eight) (Ping timeout: 245 seconds) |
| 2021-07-14 13:43:22 +0200 | eight | (~eight@user/eight) |
| 2021-07-14 13:45:18 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 255 seconds) |
| 2021-07-14 13:45:19 +0200 | azeem | (~azeem@dynamic-adsl-84-220-239-177.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2021-07-14 13:48:53 +0200 | koolazer | (~koo@user/koolazer) (Ping timeout: 265 seconds) |
| 2021-07-14 13:52:41 +0200 | azeem | (~azeem@dynamic-adsl-84-220-239-177.clienti.tiscali.it) |
| 2021-07-14 13:53:02 +0200 | Natch | (~natch@c-e070e255.014-297-73746f25.bbcust.telenor.se) (Remote host closed the connection) |
| 2021-07-14 13:57:24 +0200 | azeem | (~azeem@dynamic-adsl-84-220-239-177.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2021-07-14 13:57:53 +0200 | <yin[m]> | tomsmeding: my bad |
| 2021-07-14 13:58:25 +0200 | Natch | (~natch@c-e070e255.014-297-73746f25.bbcust.telenor.se) |
| 2021-07-14 14:00:44 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2021-07-14 14:01:08 +0200 | juhp | (~juhp@128.106.188.66) |
| 2021-07-14 14:04:54 +0200 | azeem | (~azeem@dynamic-adsl-84-220-239-177.clienti.tiscali.it) |
| 2021-07-14 14:07:34 +0200 | <maerwald> | https://hackage.haskell.org/package/rio-0.1.20.0/docs/RIO-Process.html am I missing something or does this look over-engineered? |
| 2021-07-14 14:11:07 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 265 seconds) |
| 2021-07-14 14:12:13 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Ping timeout: 244 seconds) |
| 2021-07-14 14:12:52 +0200 | <hpc> | yeah, i would rather use System.Process |
| 2021-07-14 14:13:13 +0200 | <Profpatsch> | looks that way |
| 2021-07-14 14:13:18 +0200 | <Profpatsch> | caching PATH is a bad idea |
| 2021-07-14 14:14:28 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-07-14 14:14:52 +0200 | <maerwald> | It took me 15 minutes just to figure out how to... well... spawn a process |
| 2021-07-14 14:15:43 +0200 | <maerwald> | and then you have to shove the env vars into the RIO env |
| 2021-07-14 14:15:49 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-14 14:20:47 +0200 | absence_ | absence |
| 2021-07-14 14:21:54 +0200 | <absence> | in ghc 9, template haskell was changed so liftTyped returns Quote m => Code m a instead of Q (TExp a). this breaks the code "either fail liftTyped something" because Code doesn't have a MonadFail instance. what's the recommended way to deal with this? manually wrap the result of fail in Code, i.e. "either (Code . fail) liftTyped something", or does that have other consequences? |
| 2021-07-14 14:24:35 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) |
| 2021-07-14 14:24:40 +0200 | stevenxl | (uid133530@id-133530.highgate.irccloud.com) |
| 2021-07-14 14:25:23 +0200 | Pickchea | (~private@user/pickchea) |
| 2021-07-14 14:26:53 +0200 | Guest12 | (~Guest12@static-72-73-22-17.clppva.fios.verizon.net) |
| 2021-07-14 14:27:46 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-14 14:28:06 +0200 | jespada | (~jespada@90.254.247.46) (Ping timeout: 256 seconds) |
| 2021-07-14 14:28:25 +0200 | Guest12 | (~Guest12@static-72-73-22-17.clppva.fios.verizon.net) (Client Quit) |
| 2021-07-14 14:29:36 +0200 | jespada | (~jespada@90.254.247.46) |
| 2021-07-14 14:32:23 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 265 seconds) |
| 2021-07-14 14:34:58 +0200 | fef | (~thedawn@user/thedawn) (Remote host closed the connection) |
| 2021-07-14 14:35:32 +0200 | fef | (~thedawn@user/thedawn) |
| 2021-07-14 14:36:12 +0200 | fef | (~thedawn@user/thedawn) (Remote host closed the connection) |
| 2021-07-14 14:36:49 +0200 | fef | (~thedawn@user/thedawn) |
| 2021-07-14 14:41:34 +0200 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-07-14 14:42:20 +0200 | jneira | (~jneira@212.8.115.226) (Quit: Client closed) |
| 2021-07-14 14:42:47 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:500a:f04e:5614:56a9) (Remote host closed the connection) |
| 2021-07-14 14:42:58 +0200 | jneira | (~jneira@212.8.115.226) |
| 2021-07-14 14:43:40 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:9925:18b1:79f7:f242) |
| 2021-07-14 14:47:31 +0200 | koolazer | (~koo@user/koolazer) |
| 2021-07-14 14:51:43 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-07-14 14:52:00 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-07-14 14:57:01 +0200 | jneira | (~jneira@212.8.115.226) (Quit: Client closed) |
| 2021-07-14 14:59:58 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 15:01:07 +0200 | alx741 | (~alx741@186.178.109.32) |
| 2021-07-14 15:01:29 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-14 15:04:12 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2021-07-14 15:12:01 +0200 | thyriaen | (~thyriaen@45.178.73.238) |
| 2021-07-14 15:12:57 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-14 15:14:05 +0200 | <thyriaen> | howdy, friends i do not understand why this gets pattern matched on the Leaf rule, when it is not: https://paste.tomsmeding.com/plDEEwT7 |
| 2021-07-14 15:15:18 +0200 | Gurkenglas_ | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) (Ping timeout: 272 seconds) |
| 2021-07-14 15:15:51 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 15:17:09 +0200 | <jippiedoe> | @thyriaen in `insert`, you only return the result of the recursive call (instead of wrapping it in the rest of the tree again) |
| 2021-07-14 15:17:09 +0200 | <lambdabot> | Unknown command, try @list |
| 2021-07-14 15:18:14 +0200 | <thyriaen> | jippiedoe, in the insert lm Leaf case ? |
| 2021-07-14 15:18:26 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2021-07-14 15:18:40 +0200 | <jippiedoe> | in the insert lm Node case! |
| 2021-07-14 15:19:06 +0200 | <thyriaen> | but i am inserting it again in that case |
| 2021-07-14 15:19:21 +0200 | prite | (~pritam@user/pritambaral) (Ping timeout: 268 seconds) |
| 2021-07-14 15:19:28 +0200 | <thyriaen> | ohhh |
| 2021-07-14 15:19:38 +0200 | <thyriaen> | im quite dumb i make the recursive call but dont put it in a tree |
| 2021-07-14 15:19:39 +0200 | <thyriaen> | xD |
| 2021-07-14 15:20:10 +0200 | prite | (~pritam@user/pritambaral) |
| 2021-07-14 15:20:15 +0200 | <thyriaen> | well now i know why the gardener left me |
| 2021-07-14 15:20:32 +0200 | koolazer | (~koo@user/koolazer) (Ping timeout: 245 seconds) |
| 2021-07-14 15:21:19 +0200 | <tomsmeding> | thyriaen: sometimes you need a pair of eyes that haven't been staring at the code yet to see what's going wrong :) |
| 2021-07-14 15:21:25 +0200 | <tomsmeding> | I can recommend rubber ducks |
| 2021-07-14 15:21:59 +0200 | <thyriaen> | :p |
| 2021-07-14 15:24:09 +0200 | hendursa1 | (~weechat@user/hendursaga) (Quit: hendursa1) |
| 2021-07-14 15:24:29 +0200 | hendursaga | (~weechat@user/hendursaga) |
| 2021-07-14 15:26:27 +0200 | hendursaga | (~weechat@user/hendursaga) (Client Quit) |
| 2021-07-14 15:26:52 +0200 | hendursaga | (~weechat@user/hendursaga) |
| 2021-07-14 15:27:17 +0200 | shriekingnoise | (~shrieking@186.137.144.80) |
| 2021-07-14 15:29:51 +0200 | thyriaen | (~thyriaen@45.178.73.238) (Quit: Leaving) |
| 2021-07-14 15:30:00 +0200 | silverwhitefish | (~hidden@47.202.102.10) |
| 2021-07-14 15:30:19 +0200 | chris_ | (~chris@81.96.113.213) |
| 2021-07-14 15:30:25 +0200 | haykam1 | (~haykam@static.100.2.21.65.clients.your-server.de) (Remote host closed the connection) |
| 2021-07-14 15:30:38 +0200 | haykam1 | (~haykam@static.100.2.21.65.clients.your-server.de) |
| 2021-07-14 15:34:29 +0200 | peterhil | (~peterhil@dsl-hkibng32-54f849-252.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-14 15:35:19 +0200 | peterhil | (~peterhil@dsl-hkibng32-54f849-252.dhcp.inet.fi) |
| 2021-07-14 15:36:00 +0200 | zgrep | (~zgrep@user/zgrep) (Quit: It's a quitter's world.) |
| 2021-07-14 15:37:32 +0200 | zgrep | (~zgrep@user/zgrep) |
| 2021-07-14 15:37:37 +0200 | acidjnk_new3 | (~acidjnk@p200300d0c72b9516e15cb996b96a0953.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2021-07-14 15:47:56 +0200 | madjestic | (~madjestic@88-159-247-120.fixed.kpn.net) |
| 2021-07-14 15:50:11 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-07-14 15:53:20 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 252 seconds) |
| 2021-07-14 15:55:07 +0200 | michalz | (~michalz@185.246.204.60) (Remote host closed the connection) |
| 2021-07-14 15:56:33 +0200 | Lycurgus | (~juan@cpe-45-46-140-49.buffalo.res.rr.com) |
| 2021-07-14 15:59:17 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Ping timeout: 245 seconds) |
| 2021-07-14 16:02:10 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2021-07-14 16:02:12 +0200 | allbery_b | (~geekosaur@xmonad/geekosaur) |
| 2021-07-14 16:03:46 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 246 seconds) |
| 2021-07-14 16:07:21 +0200 | allbery_b | geekosaur |
| 2021-07-14 16:12:34 +0200 | Topsi | (~Tobias@dyndsl-095-033-020-123.ewe-ip-backbone.de) (Quit: Leaving.) |
| 2021-07-14 16:14:43 +0200 | pharmaz0ne | (~pharmaz0n@92.40.194.74.threembb.co.uk) |
| 2021-07-14 16:15:02 +0200 | pharmaz0ne | (~pharmaz0n@92.40.194.74.threembb.co.uk) (Client Quit) |
| 2021-07-14 16:15:04 +0200 | biberu | (~biberu@user/biberu) (Read error: Connection reset by peer) |
| 2021-07-14 16:17:04 +0200 | pharmaz0ne | (~pharmaz0n@92.40.194.74.threembb.co.uk) |
| 2021-07-14 16:17:05 +0200 | Atum_ | (~IRC@user/atum/x-2392232) |
| 2021-07-14 16:17:08 +0200 | Atum_ | (~IRC@user/atum/x-2392232) (Client Quit) |
| 2021-07-14 16:17:18 +0200 | Pickchea | (~private@user/pickchea) |
| 2021-07-14 16:17:43 +0200 | Atum_ | (IRC@user/atum/x-2392232) |
| 2021-07-14 16:21:58 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-14 16:22:07 +0200 | biberu | (~biberu@user/biberu) |
| 2021-07-14 16:24:34 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2021-07-14 16:28:49 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2021-07-14 16:30:11 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 255 seconds) |
| 2021-07-14 16:39:06 +0200 | derelict | (~derelict@user/derelict) |
| 2021-07-14 16:39:19 +0200 | anandprabhu | (~anandprab@94.202.243.198) |
| 2021-07-14 16:41:17 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) |
| 2021-07-14 16:42:39 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 16:43:01 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-14 16:43:55 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) |
| 2021-07-14 16:46:30 +0200 | madjestic | (~madjestic@88-159-247-120.fixed.kpn.net) (Ping timeout: 258 seconds) |
| 2021-07-14 16:52:15 +0200 | HotblackDesiato | (~HotblackD@gateway/tor-sasl/hotblackdesiato) (Remote host closed the connection) |
| 2021-07-14 16:52:32 +0200 | HotblackDesiato | (~HotblackD@gateway/tor-sasl/hotblackdesiato) |
| 2021-07-14 16:56:15 +0200 | koolazer | (~koo@user/koolazer) |
| 2021-07-14 16:59:35 +0200 | azeem | (~azeem@dynamic-adsl-84-220-239-177.clienti.tiscali.it) (Ping timeout: 268 seconds) |
| 2021-07-14 17:01:23 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 17:02:07 +0200 | azeem | (~azeem@176.201.40.210) |
| 2021-07-14 17:03:48 +0200 | dajoer | (~david@user/gvx) (Quit: leaving) |
| 2021-07-14 17:04:01 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-07-14 17:04:37 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-14 17:05:32 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 245 seconds) |
| 2021-07-14 17:07:24 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-07-14 17:07:47 +0200 | azeem | (~azeem@176.201.40.210) (Read error: Connection reset by peer) |
| 2021-07-14 17:08:07 +0200 | azeem | (~azeem@dynamic-adsl-84-220-239-177.clienti.tiscali.it) |
| 2021-07-14 17:08:22 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 17:08:40 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 272 seconds) |
| 2021-07-14 17:08:45 +0200 | cheater1__ | cheater |
| 2021-07-14 17:13:04 +0200 | juhp | (~juhp@128.106.188.66) (Quit: juhp) |
| 2021-07-14 17:13:15 +0200 | juhp | (~juhp@128.106.188.66) |
| 2021-07-14 17:20:13 +0200 | chomwitt | (~Pitsikoko@2a02:587:dc04:e00:12c3:7bff:fe6d:d374) (Ping timeout: 268 seconds) |
| 2021-07-14 17:22:22 +0200 | Lycurgus | (~juan@cpe-45-46-140-49.buffalo.res.rr.com) (Quit: Exeunt) |
| 2021-07-14 17:26:34 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 17:29:06 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2021-07-14 17:31:33 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2021-07-14 17:32:03 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) |
| 2021-07-14 17:33:04 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-14 17:33:39 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 258 seconds) |
| 2021-07-14 17:34:14 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 244 seconds) |
| 2021-07-14 17:34:25 +0200 | koolazer | (~koo@user/koolazer) (Ping timeout: 258 seconds) |
| 2021-07-14 17:35:44 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-14 17:37:45 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 17:38:15 +0200 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-07-14 17:38:25 +0200 | <hololeap> | is caching PATH really that bad of an idea? it doesn't seem like something that would change very often |
| 2021-07-14 17:39:22 +0200 | Guest21 | (~Guest21@187.83.249.216.dyn.smithville.net) |
| 2021-07-14 17:39:27 +0200 | <Clint> | where? |
| 2021-07-14 17:39:45 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-07-14 17:40:02 +0200 | <hololeap> | https://hackage.haskell.org/package/rio-0.1.20.0/docs/RIO-Process.html |
| 2021-07-14 17:40:17 +0200 | <Rembane> | hololeap: Assume that someone will mess it up for you. |
| 2021-07-14 17:40:58 +0200 | <tomsmeding> | that's within one process, right? Normally environment variables don't change in one process unless you explicitly change it :) |
| 2021-07-14 17:41:01 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-14 17:41:29 +0200 | <tomsmeding> | though I guess that "cache PATH lookups" refers to caching the location of particular binary names in the file system as looked up in the PATH, which is a different story altogether |
| 2021-07-14 17:42:28 +0200 | hnOsmium0001 | (uid453710@id-453710.stonehaven.irccloud.com) |
| 2021-07-14 17:42:58 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-07-14 17:49:29 +0200 | lbseale | (~lbseale@user/ep1ctetus) (Read error: Connection reset by peer) |
| 2021-07-14 17:50:39 +0200 | <Profpatsch> | It introduces a caching layer, which is always a bad idea |
| 2021-07-14 17:50:58 +0200 | <Profpatsch> | They probably implement their own lookup logic |
| 2021-07-14 17:51:41 +0200 | <Profpatsch> | Granted, environment variables *probably* don’t change in most programs |
| 2021-07-14 17:53:23 +0200 | <Profpatsch> | but now you have to have a state that you need to carry around and a lot of logic around something |
| 2021-07-14 17:53:31 +0200 | slowButPresent | (~slowButPr@user/slowbutpresent) |
| 2021-07-14 17:55:19 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2021-07-14 17:55:44 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-07-14 17:57:29 +0200 | <[exa]> | hololeap: PATH lists in some certain environments (I'd even say nix) are pretty fat, if you save say 100 calls of stat(2) for one execve(2) it usually starts paying off |
| 2021-07-14 17:57:53 +0200 | qbt | (~edun@user/edun) (Quit: WeeChat 3.2) |
| 2021-07-14 17:58:09 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 17:58:44 +0200 | <[exa]> | Profpatsch: feel free remove your L1&L2 cache and reiterate on the caches as bad ideas |
| 2021-07-14 17:59:08 +0200 | <ephemient> | (ba)sh caches PATH lookups, but has a (re)hash command to manipulate it because it can be wrong |
| 2021-07-14 17:59:58 +0200 | Guest21 | (~Guest21@187.83.249.216.dyn.smithville.net) (Ping timeout: 246 seconds) |
| 2021-07-14 18:00:52 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-14 18:01:29 +0200 | mcglk | (~mcglk@131.191.49.120) |
| 2021-07-14 18:01:41 +0200 | <tomsmeding> | caching is sometimes good, sometimes _REALLY_ good, but certainly not always good |
| 2021-07-14 18:01:48 +0200 | <EvanR> | a caching layer is great when it's never wrong |
| 2021-07-14 18:02:18 +0200 | <tomsmeding> | and pays off in comparison to the required maintenance effort |
| 2021-07-14 18:02:39 +0200 | <tomsmeding> | it's an optimisation, and any optimisation is a tradeoff :) |
| 2021-07-14 18:03:06 +0200 | <EvanR> | L* cache, my maintenance effort is zero and it's never wrong xD |
| 2021-07-14 18:03:19 +0200 | <EvanR> | HTTP caching, maintenance effort high and is never right! |
| 2021-07-14 18:03:44 +0200 | alan41 | (~alan@83-245-249-101-nat-p.elisa-mobile.fi) |
| 2021-07-14 18:03:48 +0200 | <tomsmeding> | and yet, if you'd turn off http caching in your browser, many websites would get a lot slower |
| 2021-07-14 18:04:06 +0200 | <davean> | Uh, if your HTTP cache is wrong, the upstream site fucked up |
| 2021-07-14 18:04:08 +0200 | tomsmeding | doubts "never right" |
| 2021-07-14 18:04:18 +0200 | <tomsmeding> | davean: which happens |
| 2021-07-14 18:04:26 +0200 | <davean> | HTTP has a plenty expressive caching semantics |
| 2021-07-14 18:04:28 +0200 | <tomsmeding> | but not enough to warrant "never right" :) |
| 2021-07-14 18:04:34 +0200 | alan41 | (~alan@83-245-249-101-nat-p.elisa-mobile.fi) (Client Quit) |
| 2021-07-14 18:04:35 +0200 | xsperry | (~as@user/xsperry) |
| 2021-07-14 18:04:36 +0200 | <EvanR> | when it's your (my) upstream site, that explains it |
| 2021-07-14 18:05:07 +0200 | <EvanR> | anyway web tech gives caching a bad name |
| 2021-07-14 18:05:07 +0200 | pharmaz0ne | (~pharmaz0n@92.40.194.74.threembb.co.uk) (Read error: Connection reset by peer) |
| 2021-07-14 18:05:31 +0200 | <tomsmeding> | build tools also do, because of the rare instances when they're wrong |
| 2021-07-14 18:05:34 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 268 seconds) |
| 2021-07-14 18:06:41 +0200 | <EvanR> | I am still perplexed that caching schemes are allowed to be wrong |
| 2021-07-14 18:06:43 +0200 | <tomsmeding> | some regular in this channel (I forget who) has complained multiple times about weird behaviour because cabal thought some build product could be cached when it should've been recompiled |
| 2021-07-14 18:07:04 +0200 | <EvanR> | even if rarely, that would be unacceptable for the memory system's cache |
| 2021-07-14 18:07:09 +0200 | <tomsmeding> | EvanR: is there a caching scheme that is _intentionally_ allowed to be wrong? |
| 2021-07-14 18:07:26 +0200 | <tomsmeding> | oh right, bash |
| 2021-07-14 18:07:32 +0200 | jumper149 | (~jumper149@80.240.31.34) (Quit: WeeChat 3.1) |
| 2021-07-14 18:07:35 +0200 | <EvanR> | in the sense that the wrongness is observable |
| 2021-07-14 18:08:00 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 18:08:12 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 272 seconds) |
| 2021-07-14 18:08:12 +0200 | cheater1__ | cheater |
| 2021-07-14 18:08:14 +0200 | <EvanR> | whether because you went outside the bounds of unwritten rules of engagement, or just there are no rules here and everyone is doing whatever |
| 2021-07-14 18:09:10 +0200 | <davean> | You can only have a correct cache in regards to semantics |
| 2021-07-14 18:09:12 +0200 | <EvanR> | lets put it this way, if you hear someone complaining about their build systems cache being wrong, no one ever calls that a bug |
| 2021-07-14 18:09:25 +0200 | <EvanR> | it's a problem with the user |
| 2021-07-14 18:09:34 +0200 | <tomsmeding> | does no one? |
| 2021-07-14 18:09:37 +0200 | <EvanR> | i called that 'allowed to be wrong' |
| 2021-07-14 18:09:49 +0200 | <tomsmeding> | I have the exact opposite experience :p |
| 2021-07-14 18:09:50 +0200 | <davean> | Uh, no people always call that a bug |
| 2021-07-14 18:10:12 +0200 | <EvanR> | ok, the take away here is I have nothing whatsoever to add |
| 2021-07-14 18:10:25 +0200 | <EvanR> | just take the opposite of what i say, and we're good i guess |
| 2021-07-14 18:10:29 +0200 | <davean> | I guess |
| 2021-07-14 18:10:31 +0200 | <tomsmeding> | the _real_ take away is "software engineering is hard" :p |
| 2021-07-14 18:10:48 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 18:10:54 +0200 | pfurla | (~pfurla@216.131.82.58) |
| 2021-07-14 18:11:05 +0200 | <EvanR> | you see no difference whatsoever between the track record of memory system cache and other caching systems? xD |
| 2021-07-14 18:11:24 +0200 | <tomsmeding> | it's just that if there is a bug in the memory system cache, everything blows up |
| 2021-07-14 18:11:28 +0200 | <EvanR> | it seems like one is allowed to be wrong |
| 2021-07-14 18:11:29 +0200 | <davean> | The memory system cache is wrong sometimes. |
| 2021-07-14 18:11:43 +0200 | <tomsmeding> | that doesn't mean that a bug in cabal's caching scheme wouldn't be a bug |
| 2021-07-14 18:11:57 +0200 | <EvanR> | an actual bug, yeah |
| 2021-07-14 18:12:17 +0200 | <EvanR> | if you just don't know how to use cabal... |
| 2021-07-14 18:12:37 +0200 | <davean> | compilers (mostly) know how to use the memory cache |
| 2021-07-14 18:12:41 +0200 | abhixec | (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) |
| 2021-07-14 18:12:45 +0200 | <davean> | but this is actually a point of great debate |
| 2021-07-14 18:12:53 +0200 | <davean> | I'm surpised you're unfamiliar with it |
| 2021-07-14 18:13:03 +0200 | <davean> | memory ordering is a HUGE deal in compiler code generation |
| 2021-07-14 18:13:14 +0200 | ubert | (~Thunderbi@2a02:8109:9880:303c:ca5b:76ff:fe29:f233) (Remote host closed the connection) |
| 2021-07-14 18:13:19 +0200 | <EvanR> | I'm totally unfamiliar with that, in any detail |
| 2021-07-14 18:13:54 +0200 | pfurla_ | (~pfurla@ool-182ed2e2.dyn.optonline.net) (Ping timeout: 272 seconds) |
| 2021-07-14 18:14:43 +0200 | <EvanR> | so compilers don't treat the cache as a 'would be nice' bonus effect, but actively try to whisper it and get as much performance as possible? |
| 2021-07-14 18:15:12 +0200 | <EvanR> | that sounds like hell for cache designers |
| 2021-07-14 18:15:14 +0200 | elf_fortrez | (~elf_fortr@adsl-72-50-4-118.prtc.net) |
| 2021-07-14 18:15:38 +0200 | <davean> | Its not "would be nice" its a "can be incorrect under ..." |
| 2021-07-14 18:15:45 +0200 | <davean> | and then they also give it specific commands |
| 2021-07-14 18:15:50 +0200 | <davean> | evictions, prefetches ... |
| 2021-07-14 18:16:18 +0200 | <davean> | and compilers know the cache can get bad results and try to avoid it |
| 2021-07-14 18:16:26 +0200 | <davean> | you can write to a memory location, but read an old value for example |
| 2021-07-14 18:16:39 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) |
| 2021-07-14 18:16:51 +0200 | <EvanR> | really... I thought that was a serious security problem a while back and had to be fixed |
| 2021-07-14 18:17:07 +0200 | jneira[m] | (~jneira@214.red-176-83-92.dynamicip.rima-tde.net) |
| 2021-07-14 18:17:09 +0200 | <davean> | No, the security problem was making decisions based on memory *you weren't allowed to read* |
| 2021-07-14 18:17:13 +0200 | <davean> | which also interacted with the cache |
| 2021-07-14 18:17:16 +0200 | <davean> | but also with speculation |
| 2021-07-14 18:17:19 +0200 | <davean> | etc |
| 2021-07-14 18:17:38 +0200 | <EvanR> | oof |
| 2021-07-14 18:17:39 +0200 | <davean> | The concept of the cache giving wrong results generally falls under the term "memory ordering" |
| 2021-07-14 18:18:12 +0200 | <davean> | https://en.wikipedia.org/wiki/Memory_ordering |
| 2021-07-14 18:18:19 +0200 | <davean> | but also in multicore consistency, etc |
| 2021-07-14 18:18:31 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 268 seconds) |
| 2021-07-14 18:18:32 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 18:18:34 +0200 | cheater1__ | cheater |
| 2021-07-14 18:18:50 +0200 | <davean> | If you use the CPU cache correctly you get correct results - if you use HTTP caching correctly you get correct result |
| 2021-07-14 18:19:00 +0200 | <davean> | theres no mysteries here - other than what the x86 cache actually does! |
| 2021-07-14 18:19:05 +0200 | <davean> | Its a bit unknown on x86 |
| 2021-07-14 18:19:15 +0200 | <davean> | ARM for example actually has something of a specification |
| 2021-07-14 18:19:44 +0200 | <davean> | Mind you that wikipedia article focuses more on the instruction pipeline |
| 2021-07-14 18:20:13 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 244 seconds) |
| 2021-07-14 18:20:30 +0200 | <davean> | Both HTTP and the CPU cache directly tie back to https://en.wikipedia.org/wiki/Consistency_model |
| 2021-07-14 18:20:53 +0200 | <EvanR> | can we has a type system that guarantees correct use of cache |
| 2021-07-14 18:21:08 +0200 | <davean> | uh ... |
| 2021-07-14 18:21:16 +0200 | jippiedoe | (~david@2a02-a44c-e14e-1-1e76-24e-f48d-1c7a.fixed6.kpn.net) (Ping timeout: 268 seconds) |
| 2021-07-14 18:21:24 +0200 | <davean> | Not for x86 |
| 2021-07-14 18:21:35 +0200 | <davean> | because we don't know the semantics for x86 so we'd have nothing to type against |
| 2021-07-14 18:21:39 +0200 | <davean> | for ARM or something? |
| 2021-07-14 18:21:50 +0200 | anandprabhu | (~anandprab@94.202.243.198) (Quit: Leaving) |
| 2021-07-14 18:22:01 +0200 | <davean> | sure, but you'd not like the type system, because it would dictact what came before and after for variable distances. |
| 2021-07-14 18:22:19 +0200 | <davean> | Your types would be like some form of hoare triples I guess ... |
| 2021-07-14 18:22:31 +0200 | <EvanR> | cool |
| 2021-07-14 18:22:41 +0200 | <davean> | The compiler deals with this for you though |
| 2021-07-14 18:22:43 +0200 | <davean> | thats its job |
| 2021-07-14 18:22:47 +0200 | <Profpatsch> | [exa]: reductio ad absurdum |
| 2021-07-14 18:22:58 +0200 | <davean> | its job is to be a compitent CPU user, like yours is to be a compitent cabal user |
| 2021-07-14 18:23:02 +0200 | <EvanR> | it could maybe be a type system for use in a compiler |
| 2021-07-14 18:23:26 +0200 | <davean> | EvanR: I think this is a better place for something like a model checker |
| 2021-07-14 18:23:54 +0200 | <davean> | which, wait, is what we actually use currently |
| 2021-07-14 18:23:58 +0200 | <davean> | so I guess thats a boring statement |
| 2021-07-14 18:25:46 +0200 | <davean> | Well I'm kinda getting bored of giving a "how computers work - the basics" lecture, so I think I'll wander away |
| 2021-07-14 18:26:53 +0200 | <davean> | I will say though if you want to do any performance optimisation in your future, I'd spend a few hours reading about this stuff, it only takes a few hours |
| 2021-07-14 18:27:17 +0200 | <davean> | Computers are actually really simple |
| 2021-07-14 18:27:32 +0200 | <davean> | You could learn enough to build one in a day |
| 2021-07-14 18:27:58 +0200 | <hololeap> | what would be the recommended way to bind a python library to a haskell interface? |
| 2021-07-14 18:28:22 +0200 | <lechner> | Hi, is yesod still a suitable foundation for a website these days? Thanks! |
| 2021-07-14 18:28:30 +0200 | <EvanR> | all that aside, would be cool if websites showed the latest version, according to timestamps xD |
| 2021-07-14 18:28:51 +0200 | jneira[m] | (~jneira@214.red-176-83-92.dynamicip.rima-tde.net) (Remote host closed the connection) |
| 2021-07-14 18:29:11 +0200 | <EvanR> | sorry for boring! |
| 2021-07-14 18:29:24 +0200 | <davean> | EvanR: its cool, and they CAN |
| 2021-07-14 18:29:27 +0200 | <davean> | EvanR: if they don't, its by choice |
| 2021-07-14 18:29:42 +0200 | Brianmancer | (~Neuromanc@user/briandamag) (Ping timeout: 255 seconds) |
| 2021-07-14 18:30:30 +0200 | <davean> | (For a trivial version: You put an ETag on the root page, you stick your resource at hashs, and set the hashes to cache forever since they're content addressed) |
| 2021-07-14 18:31:11 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-07-14 18:32:28 +0200 | <davean> | EvanR: the HTTP cache semantics are layed out in the RFC, and seperate CDN style caches from user's browser caches, and CDNs can do semi-consistent invalidations |
| 2021-07-14 18:32:35 +0200 | <davean> | so this is ENTIRELY on the website in question |
| 2021-07-14 18:34:03 +0200 | <davean> | EvanR: I you ever run a website you care to actually get performant and correct, I'd be happy to talk about all the various options with you |
| 2021-07-14 18:34:15 +0200 | hexfive | (~eric@50.35.83.177) |
| 2021-07-14 18:34:34 +0200 | <davean> | I'll point out a site like reddit doesn't even SERVE fresh content. |
| 2021-07-14 18:34:39 +0200 | <davean> | never mind have the cache |
| 2021-07-14 18:34:42 +0200 | <davean> | its just too expensive |
| 2021-07-14 18:34:53 +0200 | <davean> | the content is updated by background tasks |
| 2021-07-14 18:35:02 +0200 | jneira[m] | (~jneira@214.red-176-83-92.dynamicip.rima-tde.net) |
| 2021-07-14 18:35:56 +0200 | <davean> | EvanR: Oh, you've probable seen the cleaner version of the above scheme - images like /.../img.jpg?12df22f2432fc22 |
| 2021-07-14 18:36:13 +0200 | <davean> | That last piece after the question mark is a cache buster, which has the hash of the content |
| 2021-07-14 18:36:38 +0200 | <davean> | so you force your way through the cache whenever the content updates, but keep the nice base names |
| 2021-07-14 18:36:41 +0200 | <EvanR> | the poor timestamps, so unappreciated xD |
| 2021-07-14 18:37:02 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-14 18:37:14 +0200 | <EvanR> | anyway! |
| 2021-07-14 18:41:24 +0200 | Atum_ | (IRC@user/atum/x-2392232) (Ping timeout: 255 seconds) |
| 2021-07-14 18:41:40 +0200 | Gurkenglas_ | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) |
| 2021-07-14 18:43:10 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-14 18:43:22 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 18:43:39 +0200 | derelict | (~derelict@user/derelict) (Ping timeout: 255 seconds) |
| 2021-07-14 18:43:40 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 272 seconds) |
| 2021-07-14 18:43:40 +0200 | Vajb | (~Vajb@2001:999:62:1d53:26b1:6c9b:c1ed:9c01) |
| 2021-07-14 18:43:40 +0200 | Vajb | (~Vajb@2001:999:62:1d53:26b1:6c9b:c1ed:9c01) (Read error: Connection reset by peer) |
| 2021-07-14 18:43:45 +0200 | cheater1__ | cheater |
| 2021-07-14 18:43:48 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-14 18:44:41 +0200 | jolly | (~jolly@208.180.97.158) (Quit: Connection closed) |
| 2021-07-14 18:44:42 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Ping timeout: 268 seconds) |
| 2021-07-14 18:45:00 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 255 seconds) |
| 2021-07-14 18:46:42 +0200 | s_ | (~s@50.34.81.185) (Quit: Leaving) |
| 2021-07-14 18:47:47 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 18:48:25 +0200 | qbt | (~edun@user/edun) (Quit: WeeChat 3.2) |
| 2021-07-14 18:48:51 +0200 | jneira[m] | (~jneira@214.red-176-83-92.dynamicip.rima-tde.net) (Remote host closed the connection) |
| 2021-07-14 18:49:44 +0200 | chele | (~chele@user/chele) (Read error: Connection reset by peer) |
| 2021-07-14 18:50:19 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 258 seconds) |
| 2021-07-14 18:52:21 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 18:53:52 +0200 | MQ-17J | (~MQ-17J@8.21.10.15) |
| 2021-07-14 18:53:56 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-07-14 18:58:06 +0200 | chomwitt | (~Pitsikoko@ppp-94-67-202-202.home.otenet.gr) |
| 2021-07-14 19:03:21 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-14 19:03:29 +0200 | arkanoid | (~arkanoid@2-238-151-49.ip244.fastwebnet.it) |
| 2021-07-14 19:03:35 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-14 19:03:44 +0200 | <arkanoid> | hello |
| 2021-07-14 19:03:49 +0200 | Vajb | (~Vajb@2001:999:62:1d53:26b1:6c9b:c1ed:9c01) |
| 2021-07-14 19:07:27 +0200 | <arkanoid> | I'm not an haskell programmer, just a newcomer to FP that's reading book about category theory for programmers. The book give a lot of examples and talks about haskell, but there's a phrase that just triggered my curiosity: it says that Haskell standard library comes with proofs of correctness. Is that true? |
| 2021-07-14 19:10:53 +0200 | Profpatsch | (~Profpatsc@static.88-198-193-255.clients.your-server.de) (WeeChat 3.1) |
| 2021-07-14 19:11:29 +0200 | <hololeap> | arkanoid: is it the Milewski one? |
| 2021-07-14 19:11:50 +0200 | <monochrom> | The answer is no. |
| 2021-07-14 19:12:03 +0200 | <davean> | Uh, theres a liquid haskell covered base I think? Maybe? |
| 2021-07-14 19:12:08 +0200 | <davean> | Certainly not the standard library! |
| 2021-07-14 19:12:27 +0200 | <davean> | https://hackage.haskell.org/package/liquid-base I think? |
| 2021-07-14 19:12:36 +0200 | <davean> | I've certainly never looked into it |
| 2021-07-14 19:14:19 +0200 | Atum_ | (IRC@user/atum/x-2392232) |
| 2021-07-14 19:15:05 +0200 | Pickchea | (~private@user/pickchea) |
| 2021-07-14 19:15:20 +0200 | <sm> | lechner: certainly |
| 2021-07-14 19:17:02 +0200 | <hololeap> | arkanoid: I think he means that the type system provides a proof of correctness, but the type system can't do _every_ kind of validation |
| 2021-07-14 19:17:20 +0200 | <hololeap> | for instance, reverse :: [a] -> [a] |
| 2021-07-14 19:17:42 +0200 | <hololeap> | the type system does nothing to prove that this function works the way it's intended to |
| 2021-07-14 19:17:51 +0200 | <davean> | Well you can never do every kinda of validation, correctness is with respect to a specification |
| 2021-07-14 19:19:07 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2021-07-14 19:19:11 +0200 | <davean> | arkanoid: do you have more around the quote? |
| 2021-07-14 19:19:39 +0200 | <hololeap> | davean: https://github.com/hmemcpy/milewski-ctfp-pdf/releases/download/v19-eb86347/category-theory-for-pro… |
| 2021-07-14 19:19:43 +0200 | <hololeap> | top of page 20 |
| 2021-07-14 19:19:43 +0200 | koolazer | (~koo@user/koolazer) |
| 2021-07-14 19:20:24 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 19:20:39 +0200 | <davean> | hum |
| 2021-07-14 19:21:20 +0200 | <davean> | No, I don't think he means the liquid haskell one there, and I think that claim is bullshit. |
| 2021-07-14 19:21:27 +0200 | P1RATEZ | (piratez@user/p1ratez) |
| 2021-07-14 19:21:27 +0200 | <davean> | Though possibly technically correct in a sense |
| 2021-07-14 19:21:46 +0200 | <davean> | Though the liquid-haskell one might be of interest |
| 2021-07-14 19:22:21 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
| 2021-07-14 19:22:30 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-14 19:23:37 +0200 | fef | (~thedawn@user/thedawn) (Remote host closed the connection) |
| 2021-07-14 19:24:40 +0200 | <davean> | The types are a proof of some sort of correctness, but often not valid proofs |
| 2021-07-14 19:24:55 +0200 | <davean> | and don't cover all the stuff you should care about |
| 2021-07-14 19:25:06 +0200 | <davean> | Sure, they help |
| 2021-07-14 19:25:38 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-07-14 19:27:40 +0200 | <davean> | The standard library more provides your axioms |
| 2021-07-14 19:29:38 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 265 seconds) |
| 2021-07-14 19:29:58 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-14 19:33:30 +0200 | P1RATEZ | (piratez@user/p1ratez) (Ping timeout: 265 seconds) |
| 2021-07-14 19:34:20 +0200 | Guest27 | (~Guest27@187.83.249.216.dyn.smithville.net) |
| 2021-07-14 19:35:35 +0200 | Deide | (~Deide@217.155.19.23) |
| 2021-07-14 19:35:35 +0200 | Deide | (~Deide@217.155.19.23) (Changing host) |
| 2021-07-14 19:35:35 +0200 | Deide | (~Deide@user/deide) |
| 2021-07-14 19:37:11 +0200 | <arkanoid> | hololeap: yes is by Mr Milewski |
| 2021-07-14 19:40:39 +0200 | <arkanoid> | thanks for all the answers. Yes I do understand how that sentence might raise more than one eyebrow, but the author is clearly trying to make things easier and put things into categories (ba dum tss) |
| 2021-07-14 19:45:19 +0200 | elf_fortrez | (~elf_fortr@adsl-72-50-4-118.prtc.net) (Ping timeout: 246 seconds) |
| 2021-07-14 19:45:38 +0200 | <monochrom> | I would s/not valid/weakened/ |
| 2021-07-14 19:46:06 +0200 | hexreel | (~hr@69.233.98.238) |
| 2021-07-14 19:46:14 +0200 | chris_ | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-07-14 19:46:54 +0200 | <monochrom> | Also, while we're at curry-howard, types are claims, terms are proofs. |
| 2021-07-14 19:47:37 +0200 | <monochrom> | In Haskell, types are weakened claims, not invalid claims. This is a case of PEBKAC again. |
| 2021-07-14 19:48:19 +0200 | ubert | (~Thunderbi@p2e5a50e5.dip0.t-ipconnect.de) |
| 2021-07-14 19:49:51 +0200 | chris_ | (~chris@81.96.113.213) |
| 2021-07-14 19:51:04 +0200 | pfurla_ | (~pfurla@ool-182ed2e2.dyn.optonline.net) |
| 2021-07-14 19:52:56 +0200 | <EvanR> | something tells me this is a different sort of 'weak' |
| 2021-07-14 19:53:26 +0200 | <EvanR> | by weak you mean comes with more caveats? |
| 2021-07-14 19:54:03 +0200 | ubikium | (~ubikium@113x43x248x70.ap113.ftth.arteria-hikari.net) |
| 2021-07-14 19:54:04 +0200 | koolazer | (~koo@user/koolazer) (Ping timeout: 246 seconds) |
| 2021-07-14 19:54:05 +0200 | <monochrom> | Yes. A "if it terminates" premise. |
| 2021-07-14 19:54:06 +0200 | pfurla | (~pfurla@216.131.82.58) (Ping timeout: 268 seconds) |
| 2021-07-14 19:54:27 +0200 | ubikium | (~ubikium@113x43x248x70.ap113.ftth.arteria-hikari.net) (Client Quit) |
| 2021-07-14 19:56:26 +0200 | <monochrom> | Meta-ly, I have not read Milewski's book closely, I do not know whether he actually wrote that. |
| 2021-07-14 19:57:02 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 19:57:46 +0200 | Atum_ | (IRC@user/atum/x-2392232) (Quit: Atum_) |
| 2021-07-14 20:01:17 +0200 | Atum_ | (IRC@user/atum/x-2392232) |
| 2021-07-14 20:01:31 +0200 | chris_ | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-07-14 20:02:00 +0200 | Obo | (~roberto@70.pool90-171-81.dynamic.orange.es) (Ping timeout: 258 seconds) |
| 2021-07-14 20:02:51 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection) |
| 2021-07-14 20:03:13 +0200 | euandreh | (~euandreh@2804:14c:33:9fe5:50a8:9802:856c:54ce) (Quit: WeeChat 3.2) |
| 2021-07-14 20:03:54 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2021-07-14 20:05:35 +0200 | haykam1 | (~haykam@static.100.2.21.65.clients.your-server.de) (Remote host closed the connection) |
| 2021-07-14 20:05:48 +0200 | haykam2 | (~haykam@static.100.2.21.65.clients.your-server.de) |
| 2021-07-14 20:06:34 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection) |
| 2021-07-14 20:06:56 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2021-07-14 20:07:21 +0200 | MidAutumnMoon9 | (~MidAutumn@user/midautumnmoon) (Ping timeout: 255 seconds) |
| 2021-07-14 20:11:35 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
| 2021-07-14 20:12:07 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-14 20:12:27 +0200 | <davean> | monochrom: they're not valid in the sense they're based on unsafePerformIO, unsafeCoerce, and prim-ops without axinomial specifications |
| 2021-07-14 20:12:56 +0200 | <davean> | 'base' is unbased, they have to be the axioms |
| 2021-07-14 20:13:11 +0200 | chris_ | (~chris@81.96.113.213) |
| 2021-07-14 20:14:19 +0200 | MidAutumnMoon9 | (~MidAutumn@user/midautumnmoon) |
| 2021-07-14 20:18:18 +0200 | hexreel | (~hr@69.233.98.238) (Quit: nyaa~) |
| 2021-07-14 20:20:05 +0200 | Obo | (~roberto@70.pool90-171-81.dynamic.orange.es) |
| 2021-07-14 20:22:04 +0200 | Vajb | (~Vajb@2001:999:62:1d53:26b1:6c9b:c1ed:9c01) (Read error: Connection reset by peer) |
| 2021-07-14 20:22:50 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-14 20:23:44 +0200 | epolanski | (uid312403@id-312403.brockwell.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-14 20:24:42 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-07-14 20:25:17 +0200 | ptrcmd | (~ptrcmd@user/ptrcmd) (Quit: leaving) |
| 2021-07-14 20:25:47 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) (Remote host closed the connection) |
| 2021-07-14 20:26:44 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 20:26:45 +0200 | <tomsmeding> | it's quite based! Indeed, it's based on Falso http://sigtbd.csail.mit.edu/pubs/2016/paper9.pdf |
| 2021-07-14 20:26:54 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 272 seconds) |
| 2021-07-14 20:26:57 +0200 | cheater1__ | cheater |
| 2021-07-14 20:30:33 +0200 | jneira_ | (~jneira_@28.red-80-28-169.staticip.rima-tde.net) (Quit: Connection closed) |
| 2021-07-14 20:31:43 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-07-14 20:33:06 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) (Ping timeout: 252 seconds) |
| 2021-07-14 20:35:25 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) |
| 2021-07-14 20:42:06 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) (Ping timeout: 272 seconds) |
| 2021-07-14 20:42:28 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) |
| 2021-07-14 20:47:41 +0200 | jolly | (~jolly@208.180.97.158) |
| 2021-07-14 20:49:00 +0200 | Guest27 | (~Guest27@187.83.249.216.dyn.smithville.net) (Quit: Client closed) |
| 2021-07-14 20:53:09 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) |
| 2021-07-14 21:03:22 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) (Read error: Connection reset by peer) |
| 2021-07-14 21:03:36 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) |
| 2021-07-14 21:03:46 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) |
| 2021-07-14 21:06:02 +0200 | prite | (~pritam@user/pritambaral) (Ping timeout: 255 seconds) |
| 2021-07-14 21:06:46 +0200 | <burnsidesLlama> | Hi, I'm thinking about a general definition for 'partial sums' on [a], which is a family of functions of type [a] -> [b], generalising functions such as [1,2,3] -> [0, 0+1, 0+1+2, 0+1+2+3]. The idea I'm following writing partial sums as "foldr f e . tails" or "foldr f e . inits", depending on the 'direction' of summation. I asked the question 'which choice is more natural? inits or tails?' and it seems the answer i |
| 2021-07-14 21:06:46 +0200 | <burnsidesLlama> | s that they are both natural, and in some sense 'dual' to each other. The most precise I have made this is that "forall xs :: [a], zipWith (++) (inits xs) (tails xs) = repeat xs". Is there a rigorous notion of duality here? Are there other places where a similar idea of duality shows up? I am new to irc, please let me know if I've done something inappropriate. |
| 2021-07-14 21:07:29 +0200 | koolazer | (~koo@user/koolazer) |
| 2021-07-14 21:08:01 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) |
| 2021-07-14 21:08:14 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) (Ping timeout: 265 seconds) |
| 2021-07-14 21:09:26 +0200 | <dminuoso> | burnsidesLlama: Shouldn't those definitions rather be some `fmap (foldr f e) . tails` or `fmap (foldr f e) . inits` ? |
| 2021-07-14 21:09:42 +0200 | qbt | (~edun@user/edun) (Quit: WeeChat 3.2) |
| 2021-07-14 21:09:42 +0200 | azeem | (~azeem@dynamic-adsl-84-220-239-177.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2021-07-14 21:09:47 +0200 | <burnsidesLlama> | Yes! I meant the lifted versions |
| 2021-07-14 21:09:54 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-14 21:10:32 +0200 | azeem | (~azeem@dynamic-adsl-84-220-239-177.clienti.tiscali.it) |
| 2021-07-14 21:10:57 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 21:11:11 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 268 seconds) |
| 2021-07-14 21:11:20 +0200 | cheater1__ | cheater |
| 2021-07-14 21:11:33 +0200 | <dminuoso> | burnsidesLlama: At any rate. tails seems like a far better choice |
| 2021-07-14 21:12:01 +0200 | <dminuoso> | Well. "better" is a poor qualifier |
| 2021-07-14 21:12:20 +0200 | <dminuoso> | tails has better asymptotics |
| 2021-07-14 21:13:19 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Ping timeout: 268 seconds) |
| 2021-07-14 21:14:10 +0200 | zeenk | (~zeenk@2a02:2f04:a106:9600:82fb:aed9:ca9:38d3) (Quit: Konversation terminated!) |
| 2021-07-14 21:14:39 +0200 | <burnsidesLlama> | I don't tails has better asymptotics. inits returns initial segments in increasing length order. It can be implemented as "inits [] = [], inits (x:xs) = [] : map (x:) (inits xs)" |
| 2021-07-14 21:15:18 +0200 | <zzz> | hlint: Unnecessary hiding, why not romove it? |
| 2021-07-14 21:15:20 +0200 | zzz | removes it |
| 2021-07-14 21:15:50 +0200 | <zzz> | ghc: Error: Ambiguous occurrence |
| 2021-07-14 21:16:07 +0200 | <dminuoso> | burnsidesLlama: Mmm. So it seems my information is just out-of-date here |
| 2021-07-14 21:16:22 +0200 | <dminuoso> | You cant implement inits naively if you ever expect fusion to occur. |
| 2021-07-14 21:16:37 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) (Read error: Connection reset by peer) |
| 2021-07-14 21:16:40 +0200 | <dminuoso> | Which is why the current version is implemented as: inits = map toListSB . scanl' snocSB emptySB |
| 2021-07-14 21:16:55 +0200 | myShoggoth | (~myShoggot@97-120-70-214.ptld.qwest.net) |
| 2021-07-14 21:18:24 +0200 | jippiedoe | (~david@77-171-152-62.fixed.kpn.net) |
| 2021-07-14 21:19:14 +0200 | <[exa]> | burnsidesLlama: maybe bad question, but why not instead generalize the easier "flipped" direction, i.e., [1,2,3] -> [0, 1+0, 2+1+0, 3+2+1+0] |
| 2021-07-14 21:19:49 +0200 | <burnsidesLlama> | dminuoso I wasn't looking at the source earlier. What do you mean 'if you ever expect fusion to occur?', the source says something technical about consumers and producers |
| 2021-07-14 21:20:19 +0200 | <[exa]> | burnsidesLlama: ah I re-read your question now. :D |
| 2021-07-14 21:20:27 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 21:21:03 +0200 | <dminuoso> | burnsidesLlama: See https://gitlab.haskell.org/ghc/ghc/-/issues/9345 |
| 2021-07-14 21:21:12 +0200 | <[exa]> | burnsidesLlama: you can easily convert this "flipped" one to the other, but IMO not vice versa because the "unflipped" way requires some way of counting stuff. |
| 2021-07-14 21:21:21 +0200 | drd | (~drd@93-39-151-19.ip76.fastwebnet.it) |
| 2021-07-14 21:21:24 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 21:21:40 +0200 | <dminuoso> | [exa]: This one doesnt work for infinite lists. :( |
| 2021-07-14 21:22:28 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 21:22:32 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-14 21:22:35 +0200 | <burnsidesLlama> | irc question, how do you reference someone's name like you two have been doing? |
| 2021-07-14 21:22:38 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 272 seconds) |
| 2021-07-14 21:22:41 +0200 | cheater1__ | cheater |
| 2021-07-14 21:22:54 +0200 | <zzz> | burnsidesLlama: depends on your client, most have autocomplete |
| 2021-07-14 21:22:59 +0200 | <EvanR> | i type the first few letters and hit tab |
| 2021-07-14 21:23:14 +0200 | <burnsidesLlama> | EvanR: This works for me :) |
| 2021-07-14 21:24:13 +0200 | <dminuoso> | burnsidesLlama: So in simplified terms, GHC employs an optimization called short cut fusion |
| 2021-07-14 21:24:39 +0200 | <dminuoso> | As an example, by law it's obvious that `fmap f . fmap g = fmap (f . g)` |
| 2021-07-14 21:24:40 +0200 | qbt | (~edun@user/edun) (Client Quit) |
| 2021-07-14 21:24:53 +0200 | <burnsidesLlama> | [exa]: I suspect the flipped direction is natural for 'snoc' lists. I think there are four functions of the style of init and tails, which come in two pairs. One pair is natural for cons lists, and one is natural for snoc lists. I think the snoc list ones are 'tails' in increasing length order, and 'inits' in decreasing length order |
| 2021-07-14 21:24:54 +0200 | <dminuoso> | The latter generally performs better, because it avoids the intermediate data structure |
| 2021-07-14 21:25:12 +0200 | MQ-17J | (~MQ-17J@8.21.10.15) (Ping timeout: 255 seconds) |
| 2021-07-14 21:25:38 +0200 | <dminuoso> | And short cut fusion gives GHC a way of avoiding intermediate data structures behind the scenes. |
| 2021-07-14 21:25:50 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 255 seconds) |
| 2021-07-14 21:26:10 +0200 | <burnsidesLlama> | dminuoso: So GHC automatically applies fusion laws of various kinds for optimisation (e.g. fold fusion, the map fusion you just mentioned)? |
| 2021-07-14 21:27:12 +0200 | <dminuoso> | It only does so under particular circumstances |
| 2021-07-14 21:27:28 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-14 21:27:57 +0200 | <dminuoso> | A particular example is that sum [0...10] does not actually require a list data type in the first place. |
| 2021-07-14 21:28:33 +0200 | <dminuoso> | For that to work, the list has to be constructed specially in a way that this fusion can fire |
| 2021-07-14 21:28:46 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2021-07-14 21:29:04 +0200 | <dminuoso> | It roughly works like this: |
| 2021-07-14 21:29:10 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 21:29:18 +0200 | <dminuoso> | build :: forall a . (forall b . (a -> b -> b) -> b -> b) -> [a] |
| 2021-07-14 21:29:56 +0200 | <dminuoso> | This is a way to construct lists, if you notice closely, it's a sort of "turned around foldr" |
| 2021-07-14 21:29:58 +0200 | <dminuoso> | % :t foldr |
| 2021-07-14 21:29:59 +0200 | <yahb> | dminuoso: forall {t :: * -> *} {a} {b}. Foldable t => (a -> b -> b) -> b -> t a -> b |
| 2021-07-14 21:30:34 +0200 | <dminuoso> | So GHC comes with special rewrite rules, that if you foldr right after build, they cancel each other out - and you dont have any intermedaite cons cells |
| 2021-07-14 21:30:52 +0200 | koolazer | (~koo@user/koolazer) (Ping timeout: 272 seconds) |
| 2021-07-14 21:30:58 +0200 | qbt | (~edun@user/edun) (Client Quit) |
| 2021-07-14 21:31:24 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) (Ping timeout: 252 seconds) |
| 2021-07-14 21:31:49 +0200 | <dminuoso> | Instead what you end up with is just a loop |
| 2021-07-14 21:33:22 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 21:34:50 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
| 2021-07-14 21:35:01 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-14 21:35:24 +0200 | qbt | (~edun@user/edun) (Client Quit) |
| 2021-07-14 21:36:50 +0200 | <burnsidesLlama> | dminuoso: I don't understand the type signature of build. Why is it not build :: ((a -> [a] -> [a]) -> [a] -> [a]) -> [a]? What are the foralls doing? |
| 2021-07-14 21:37:09 +0200 | alinab_ | (sid468903@id-468903.brockwell.irccloud.com) () |
| 2021-07-14 21:37:21 +0200 | alinab_ | (sid468903@id-468903.brockwell.irccloud.com) |
| 2021-07-14 21:37:43 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) |
| 2021-07-14 21:37:50 +0200 | <dminuoso> | build g = g (:) [] |
| 2021-07-14 21:37:51 +0200 | alinab_ | alinab |
| 2021-07-14 21:37:57 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 21:38:25 +0200 | <burnsidesLlama> | Related question, how does build build lists? E.g. how might we write sum using build and fold? |
| 2021-07-14 21:41:05 +0200 | burnside_ | (~burnsides@dhcp168-025.wadham.ox.ac.uk) |
| 2021-07-14 21:41:05 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) (Read error: Connection reset by peer) |
| 2021-07-14 21:41:38 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) |
| 2021-07-14 21:41:38 +0200 | <burnsidesLlama> | https://wiki.haskell.org/Correctness_of_short_cut_fusion seems like it has the answers for my fusion related questions. Thanks :) |
| 2021-07-14 21:41:38 +0200 | burnside_ | (~burnsides@dhcp168-025.wadham.ox.ac.uk) (Read error: Connection reset by peer) |
| 2021-07-14 21:42:12 +0200 | qbt | (~edun@user/edun) (Ping timeout: 245 seconds) |
| 2021-07-14 21:42:47 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-14 21:42:48 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) (Read error: Connection reset by peer) |
| 2021-07-14 21:42:54 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) |
| 2021-07-14 21:43:01 +0200 | P1RATEZ | (piratez@user/p1ratez) |
| 2021-07-14 21:43:33 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 21:43:52 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-14 21:44:01 +0200 | eight | (~eight@user/eight) (Quit: leaving) |
| 2021-07-14 21:44:58 +0200 | <dminuoso> | burnsidesLlama: Try and understand how this works: |
| 2021-07-14 21:45:04 +0200 | <dminuoso> | % foldr (:) [] [1,2,3] |
| 2021-07-14 21:45:05 +0200 | <yahb> | dminuoso: [1,2,3] |
| 2021-07-14 21:45:12 +0200 | <dminuoso> | If you do, you should be able to grok `build` |
| 2021-07-14 21:45:43 +0200 | Obo | (~roberto@70.pool90-171-81.dynamic.orange.es) (Ping timeout: 268 seconds) |
| 2021-07-14 21:45:44 +0200 | <dminuoso> | (The key idea is simply, that a list can be thought of as an arbitrary fold with (:) and [] plucked in) |
| 2021-07-14 21:46:25 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 21:46:30 +0200 | <burnsidesLlama> | Yes, we are replacing the (:) and [] in a list expression with (:) and [] respectively |
| 2021-07-14 21:46:54 +0200 | <dminuoso> | Sure, and now imagine it doesnt even matter whether the original is a list or not. |
| 2021-07-14 21:47:25 +0200 | <dminuoso> | Could be a tree for all we know |
| 2021-07-14 21:48:12 +0200 | Guest9 | (~Guest9@43.250.157.35) |
| 2021-07-14 21:48:15 +0200 | <dminuoso> | let x = \f z -> foldr f z t in ... |
| 2021-07-14 21:48:26 +0200 | <dminuoso> | burnsidesLlama: So this is just a foldr partially applied to some structure already |
| 2021-07-14 21:48:47 +0200 | qbt | (~edun@user/edun) (Read error: Connection reset by peer) |
| 2021-07-14 21:48:56 +0200 | <dminuoso> | And `build` just finalizes such a partially applied foldr by providing (:) and [] to the remaining arguments. |
| 2021-07-14 21:49:10 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 21:50:07 +0200 | <burnsidesLlama> | in the 'let x = ...' line, do you mean foldr for lists? Or a fold for possibly another kind of ADT |
| 2021-07-14 21:50:25 +0200 | qbt | (~edun@user/edun) (Read error: Connection reset by peer) |
| 2021-07-14 21:50:25 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) (Read error: Connection reset by peer) |
| 2021-07-14 21:50:41 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) |
| 2021-07-14 21:50:48 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) (Read error: Connection reset by peer) |
| 2021-07-14 21:51:04 +0200 | <dminuoso> | Maybe this is a red herring, mmm. |
| 2021-07-14 21:51:06 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) |
| 2021-07-14 21:51:41 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2021-07-14 21:51:49 +0200 | <dminuoso> | burnsidesLlama: Could be anything. |
| 2021-07-14 21:52:39 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 21:52:47 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 268 seconds) |
| 2021-07-14 21:52:51 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 21:52:52 +0200 | cheater1__ | cheater |
| 2021-07-14 21:53:22 +0200 | <burnsidesLlama> | are you saying we can make lists out of anything using build? this doesn't seem right |
| 2021-07-14 21:54:05 +0200 | qbt | (~edun@user/edun) (Client Quit) |
| 2021-07-14 21:54:22 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 21:54:23 +0200 | tomsmeding | . o O ( https://hackage.haskell.org/package/base-4.14.0.0/docs/src/Data.Foldable.html#toList ) |
| 2021-07-14 21:54:50 +0200 | <dminuoso> | burnsidesLlama: Let's for the sake of simplicity say it has to be a foldable at least. |
| 2021-07-14 21:55:16 +0200 | <dminuoso> | Or.. no. This really is a red herring |
| 2021-07-14 21:55:25 +0200 | <burnsidesLlama> | I'm not familiar with foldable, could we be even more concrete? E.g. by taking a binary tree type |
| 2021-07-14 21:56:36 +0200 | <dminuoso> | burnsidesLlama: The idea is roughly the same as church encoding a list. A list can be fully characterized by its fold. |
| 2021-07-14 21:56:42 +0200 | <dminuoso> | (its right fold) |
| 2021-07-14 21:57:03 +0200 | <dminuoso> | % :t foldr |
| 2021-07-14 21:57:03 +0200 | <yahb> | dminuoso: forall {t :: * -> *} {a} {b}. Foldable t => (a -> b -> b) -> b -> t a -> b |
| 2021-07-14 21:57:38 +0200 | <dminuoso> | burnsidesLlama: One way to understand Foldable, is that Foldable is anything that you can turn into a list. |
| 2021-07-14 21:57:51 +0200 | dunj3 | (~dunj3@2001:16b8:30fc:7f00:fd96:42cd:9d60:7ae7) |
| 2021-07-14 21:58:20 +0200 | <dminuoso> | So if we partially apply foldr in its 3rd argument already to some foldable thing, then the remaining thing fully characterizes the list |
| 2021-07-14 21:58:21 +0200 | <burnsidesLlama> | And I imagine a Foldable instance must supply a canonical translation (which is injective?) into a list |
| 2021-07-14 21:58:24 +0200 | <dminuoso> | Consider: |
| 2021-07-14 21:58:32 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) |
| 2021-07-14 21:58:37 +0200 | <dminuoso> | % x = \f z -> foldr f z [1,2,3,4,5,6] |
| 2021-07-14 21:58:37 +0200 | <yahb> | dminuoso: |
| 2021-07-14 21:58:45 +0200 | <dminuoso> | % :t x |
| 2021-07-14 21:58:45 +0200 | <yahb> | dminuoso: forall {a} {b}. Num a => (a -> b -> b) -> b -> b |
| 2021-07-14 21:58:46 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 21:58:51 +0200 | <dminuoso> | Im going to claim that `x` is fully equivalent to [1,2,3,4,5,6] |
| 2021-07-14 21:59:11 +0200 | <dminuoso> | burnsidesLlama: Remember that question, we will get to it shortly |
| 2021-07-14 21:59:34 +0200 | <dminuoso> | burnsidesLlama: Let's test my claim these things are even isomorphic. |
| 2021-07-14 21:59:53 +0200 | qbt | (~edun@user/edun) (Quit: WeeChat 3.2) |
| 2021-07-14 22:00:04 +0200 | <dminuoso> | Can we turn `x` back into a proper Haskell list? |
| 2021-07-14 22:00:06 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 22:00:12 +0200 | qbt | (~edun@user/edun) |
| 2021-07-14 22:00:44 +0200 | <burnsidesLlama> | by doing build x |
| 2021-07-14 22:00:47 +0200 | <dminuoso> | heh |
| 2021-07-14 22:00:50 +0200 | <dminuoso> | Right. |
| 2021-07-14 22:00:56 +0200 | <dminuoso> | Or just manually doing `x (:) []` |
| 2021-07-14 22:00:58 +0200 | <dminuoso> | % x (:) [] |
| 2021-07-14 22:00:59 +0200 | <yahb> | dminuoso: [1,2,3,4,5,6] |
| 2021-07-14 22:01:41 +0200 | <dminuoso> | 21:58:21 burnsidesLlama | And I imagine a Foldable instance must supply a canonical translation (which is injective?) into a list |
| 2021-07-14 22:01:49 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 246 seconds) |
| 2021-07-14 22:02:06 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 22:02:10 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-14 22:02:19 +0200 | <dminuoso> | Yes and no. While strictly speaking we could allow for an instance author to write `toList` (and it would semantically be legit), instead we demand you supply an (equivalent) foldr or foldMap instead. |
| 2021-07-14 22:02:22 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 268 seconds) |
| 2021-07-14 22:02:29 +0200 | cheater1__ | cheater |
| 2021-07-14 22:02:42 +0200 | <dminuoso> | foldr has the same power as toList, but its more flexible |
| 2021-07-14 22:03:03 +0200 | <dminuoso> | It's more flexible because you can - should you want - avoid the actual intermediate cons cells in the list |
| 2021-07-14 22:03:20 +0200 | <dminuoso> | So here comes the clue: |
| 2021-07-14 22:03:32 +0200 | <dminuoso> | `build` turns a foldr-encoded list into a proper list |
| 2021-07-14 22:03:36 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) (Ping timeout: 268 seconds) |
| 2021-07-14 22:03:54 +0200 | <dminuoso> | and foldr goes from a proper list to something else again |
| 2021-07-14 22:04:14 +0200 | <dminuoso> | build is equipped with special fusion rules that essentially say: |
| 2021-07-14 22:04:34 +0200 | <dminuoso> | With some luck: foldr k z (build g) = g k z |
| 2021-07-14 22:05:14 +0200 | jumper149 | (~jumper149@80.240.31.34) |
| 2021-07-14 22:05:15 +0200 | juhp | (~juhp@128.106.188.66) (Ping timeout: 255 seconds) |
| 2021-07-14 22:05:44 +0200 | <burnsidesLlama> | is it saying: "if we are building a list out of g, only to destroy it, then we can directly compute the result"? |
| 2021-07-14 22:05:50 +0200 | <dminuoso> | Yes. |
| 2021-07-14 22:05:52 +0200 | <dminuoso> | With some luck. |
| 2021-07-14 22:06:17 +0200 | <dminuoso> | You're still at the merci of the inliner and the magic whistles of the GHC simplifier - so there's no actual guarantee. |
| 2021-07-14 22:06:32 +0200 | Obo | (~roberto@70.pool90-171-81.dynamic.orange.es) |
| 2021-07-14 22:06:32 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-14 22:06:36 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 255 seconds) |
| 2021-07-14 22:07:05 +0200 | <burnsidesLlama> | that sounds mysterious and/or ominous |
| 2021-07-14 22:07:10 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
| 2021-07-14 22:07:13 +0200 | <burnsidesLlama> | one last question, then i need to go to sleep |
| 2021-07-14 22:07:42 +0200 | <burnsidesLlama> | how is this kind of 'deforestation' related to deforesting a function of the form 'fold . unfold'? |
| 2021-07-14 22:08:08 +0200 | juhp | (~juhp@128.106.188.66) |
| 2021-07-14 22:09:25 +0200 | <dminuoso> | burnsidesLlama: https://www.cs.ox.ac.uk/ralf.hinze/publications/IFL10.pdf |
| 2021-07-14 22:09:50 +0200 | ph88^ | (~ph88@2a02:8109:9e00:2b48:9925:18b1:79f7:f242) |
| 2021-07-14 22:10:07 +0200 | <dminuoso> | This optimization I described above is called foldr/build fusion in GHC slang. |
| 2021-07-14 22:10:14 +0200 | <dminuoso> | There's an equivalent dual optimizatoin called unfold/destroy |
| 2021-07-14 22:11:43 +0200 | <burnsidesLlama> | thank you! :) |
| 2021-07-14 22:12:12 +0200 | ph88 | (~ph88@2a02:8109:9e00:7e5c:9925:18b1:79f7:f242) (Ping timeout: 245 seconds) |
| 2021-07-14 22:12:23 +0200 | <dminuoso> | % :t unfoldr |
| 2021-07-14 22:12:24 +0200 | <yahb> | dminuoso: forall {t} {a}. (t -> Maybe (a, t)) -> t -> [a] |
| 2021-07-14 22:12:25 +0200 | <dminuoso> | % :t destroy |
| 2021-07-14 22:12:25 +0200 | <yahb> | dminuoso: forall {a} {t1} {t2}. (([a] -> Maybe (a, [a])) -> t1 -> t2) -> t1 -> t2 |
| 2021-07-14 22:12:48 +0200 | <dminuoso> | % destroy unfoldr [1..5] |
| 2021-07-14 22:12:48 +0200 | <yahb> | dminuoso: [1,2,3,4,5] |
| 2021-07-14 22:13:14 +0200 | juhp | (~juhp@128.106.188.66) (Quit: juhp) |
| 2021-07-14 22:13:23 +0200 | <dminuoso> | Please dont ask me why we have foldr/build fusion. I expect other folks to be more knowledgable here. |
| 2021-07-14 22:13:28 +0200 | juhp | (~juhp@128.106.188.66) |
| 2021-07-14 22:13:50 +0200 | <dminuoso> | burnsidesLlama: By the way, as an interesting side note: |
| 2021-07-14 22:14:00 +0200 | <dminuoso> | Recall my example of: fmap f . fmap g = fmap (f . g) ? |
| 2021-07-14 22:14:29 +0200 | <dminuoso> | It would be nice if GHC could observe this law, and always transform the former into the latter. But it cant, GHC is not even aware of any class laws. |
| 2021-07-14 22:14:37 +0200 | <dminuoso> | (It wouldn't even know if they are satisfied) |
| 2021-07-14 22:15:11 +0200 | <dminuoso> | However, there's tricks to tie GHCs hands and gain this optimization in a guaranteed manner |
| 2021-07-14 22:18:02 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) (Ping timeout: 245 seconds) |
| 2021-07-14 22:18:24 +0200 | Guest9 | (~Guest9@43.250.157.35) (Quit: Connection closed) |
| 2021-07-14 22:19:03 +0200 | <burnsidesLlama> | Making GHC aware of class laws seems like something type-level programming can address. I can't think of how exactly yet. It is like embedding a proof assistant able to work with user-defined axioms into the compiler. |
| 2021-07-14 22:19:25 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) (Read error: Connection reset by peer) |
| 2021-07-14 22:19:42 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2021-07-14 22:19:49 +0200 | Atum__ | (IRC@user/atum/x-2392232) |
| 2021-07-14 22:19:50 +0200 | <Hecate> | burnsidesLlama: LiquidHaskell |
| 2021-07-14 22:19:56 +0200 | <Hecate> | (I think?) |
| 2021-07-14 22:20:09 +0200 | <dminuoso> | burnsidesLlama: Well, we can get away with something far more trivial in Haskell |
| 2021-07-14 22:20:17 +0200 | <Hecate> | Ryan Scott wrote a paper about it as well |
| 2021-07-14 22:20:50 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Quit: Lost terminal) |
| 2021-07-14 22:21:03 +0200 | <dminuoso> | % newtype F f a = F { runF :: forall b. (a -> b) -> f b } |
| 2021-07-14 22:21:04 +0200 | <yahb> | dminuoso: |
| 2021-07-14 22:21:05 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-14 22:21:50 +0200 | <dminuoso> | burnsidesLlama: ^- here. This is just a newtype wrapper where we represent a functor as partially applied to fmap, sort of how the argument to `build` is a foldr partially applied to something list like. |
| 2021-07-14 22:22:11 +0200 | Atum_ | (IRC@user/atum/x-2392232) (Ping timeout: 265 seconds) |
| 2021-07-14 22:22:15 +0200 | <dminuoso> | % someList = F (`fmap` [1,2,3,4,5]) |
| 2021-07-14 22:22:15 +0200 | <yahb> | dminuoso: |
| 2021-07-14 22:22:43 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 268 seconds) |
| 2021-07-14 22:22:44 +0200 | <dminuoso> | % instance Functor (F f) where fmap f m = F (\k -> runF m (k . f)) |
| 2021-07-14 22:22:44 +0200 | <yahb> | dminuoso: |
| 2021-07-14 22:22:49 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 22:22:52 +0200 | cheater1__ | cheater |
| 2021-07-14 22:23:43 +0200 | <dminuoso> | Here. So we can turn say a list into this `F` representation, then do a bunch of `fmap f . fmap g . fmap h . fmap i . fmap j` on it, and then go back again - and tadaa - its fused. |
| 2021-07-14 22:23:51 +0200 | <dminuoso> | It will go over the list only once |
| 2021-07-14 22:24:47 +0200 | <tomsmeding> | because the actual 'fmap' on the list is only executed once: when the original function (`fmap` [1,2,3,4,5]) is executed; all the other fmaps translate to function composition, of which ghc does know that it can fuse |
| 2021-07-14 22:24:52 +0200 | ptrcmd | (~ptrcmd@user/ptrcmd) |
| 2021-07-14 22:25:45 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Remote host closed the connection) |
| 2021-07-14 22:25:58 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-14 22:26:33 +0200 | <dminuoso> | % lowerF (F f) = f id |
| 2021-07-14 22:26:33 +0200 | <yahb> | dminuoso: |
| 2021-07-14 22:26:40 +0200 | <dminuoso> | % lowerF . fmap (+1) . fmap (*20) . fmap (/5) $ someList |
| 2021-07-14 22:26:40 +0200 | <yahb> | dminuoso: [5.0,9.0,13.0,17.0,21.0] |
| 2021-07-14 22:28:12 +0200 | <dminuoso> | We can then also write ourselves some: |
| 2021-07-14 22:28:36 +0200 | <dminuoso> | % liftF a = F (`fmap` a) |
| 2021-07-14 22:28:36 +0200 | <yahb> | dminuoso: |
| 2021-07-14 22:28:41 +0200 | <burnsidesLlama> | in the definition of F, is runF missing an argument? the call in the instance declaration to runF m (k . f) seems to need two arguments rather than one |
| 2021-07-14 22:28:47 +0200 | <dminuoso> | % lowerF . fmap (+1) . fmap (*20) . fmap (/5) .liftF $ [1,2,3,4,5,6] |
| 2021-07-14 22:28:47 +0200 | <yahb> | dminuoso: [5.0,9.0,13.0,17.0,21.0,25.0] |
| 2021-07-14 22:29:05 +0200 | <dminuoso> | Then all we have to do is wrap this large fmap composition between `lowerF` and `liftF`, and we get fusion for free. |
| 2021-07-14 22:29:23 +0200 | <dminuoso> | Nothing else even knows about this F representation! At runtime its even gone because its a newtype |
| 2021-07-14 22:29:51 +0200 | P1RATEZ | (piratez@user/p1ratez) (Remote host closed the connection) |
| 2021-07-14 22:29:54 +0200 | <dminuoso> | burnsidesLlama: No. This is field-syntax for newtype |
| 2021-07-14 22:29:59 +0200 | <dminuoso> | % :t runF |
| 2021-07-14 22:29:59 +0200 | <yahb> | dminuoso: forall {f :: * -> *} {a}. F f a -> forall b. (a -> b) -> f b |
| 2021-07-14 22:30:27 +0200 | beka | (~beka@104.193.170-244.PUBLIC.monkeybrains.net) |
| 2021-07-14 22:30:52 +0200 | <tomsmeding> | 'runF m' is the field, which has type (forall b. (a -> b) -> f b), of the record m |
| 2021-07-14 22:31:00 +0200 | <dminuoso> | Correkt |
| 2021-07-14 22:33:12 +0200 | <burnsidesLlama> | I'll need time to digest what's been said :), bye for now. |
| 2021-07-14 22:33:12 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-07-14 22:33:12 +0200 | amirouche | (~amirouche@user/amirouche) (Read error: Connection reset by peer) |
| 2021-07-14 22:34:29 +0200 | chexum | (~chexum@gateway/tor-sasl/chexum) (Quit: -) |
| 2021-07-14 22:34:42 +0200 | smichel17 | smichel |
| 2021-07-14 22:36:18 +0200 | chexum | (~chexum@gateway/tor-sasl/chexum) |
| 2021-07-14 22:37:40 +0200 | analognoise | (~analognoi@83.136.182.93) |
| 2021-07-14 22:38:02 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 245 seconds) |
| 2021-07-14 22:38:25 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-14 22:38:33 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-14 22:38:44 +0200 | Guest239 | (~Guest23@50.47.115.102) |
| 2021-07-14 22:38:55 +0200 | finsternis | (~X@23.226.237.192) (Remote host closed the connection) |
| 2021-07-14 22:38:58 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-14 22:39:21 +0200 | amirouche | (~amirouche@user/amirouche) |
| 2021-07-14 22:39:41 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2021-07-14 22:40:07 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) |
| 2021-07-14 22:44:09 +0200 | <Guest239> | Does anyone know how to make autocompletion and automatic refactoring to work for Haskell in Spacemacs? |
| 2021-07-14 22:44:55 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) (Ping timeout: 268 seconds) |
| 2021-07-14 22:45:03 +0200 | Topsi | (~Tobias@dyndsl-095-033-020-123.ewe-ip-backbone.de) |
| 2021-07-14 22:46:16 +0200 | beka | (~beka@104.193.170-244.PUBLIC.monkeybrains.net) (Ping timeout: 246 seconds) |
| 2021-07-14 22:47:03 +0200 | smichel | smichel17 |
| 2021-07-14 22:47:28 +0200 | silverwhitefish | (~hidden@47.202.102.10) (Quit: One for all, all for One (2 Corinthians 5)) |
| 2021-07-14 22:48:54 +0200 | MidAutumnMoon9 | (~MidAutumn@user/midautumnmoon) (Ping timeout: 255 seconds) |
| 2021-07-14 22:49:14 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) (Ping timeout: 268 seconds) |
| 2021-07-14 22:50:35 +0200 | jess | (~jess@libera/staff/jess) |
| 2021-07-14 22:50:54 +0200 | o1lo01ol1o | (~o1lo01ol1@bl11-109-140.dsl.telepac.pt) |
| 2021-07-14 22:51:50 +0200 | jippiedoe | (~david@77-171-152-62.fixed.kpn.net) (Quit: Leaving) |
| 2021-07-14 22:51:53 +0200 | jneira_ | (~jneira_@28.red-80-28-169.staticip.rima-tde.net) |
| 2021-07-14 22:52:09 +0200 | <Guest239> | In spacemacs the Haskell layer is able to suggest refactorings but is unable to apply them with SPC m r r. How can I fix this? |
| 2021-07-14 22:56:01 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 268 seconds) |
| 2021-07-14 22:56:05 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-07-14 22:56:08 +0200 | cheater1__ | cheater |
| 2021-07-14 22:56:20 +0200 | MidAutumnMoon9 | (~MidAutumn@user/midautumnmoon) |
| 2021-07-14 22:58:32 +0200 | ph88^ | (~ph88@2a02:8109:9e00:2b48:9925:18b1:79f7:f242) (Ping timeout: 255 seconds) |
| 2021-07-14 23:01:10 +0200 | DNH | (~DNH@2a02:8108:1100:16d8:4c45:cc63:abad:ed54) |
| 2021-07-14 23:01:12 +0200 | DNH | (~DNH@2a02:8108:1100:16d8:4c45:cc63:abad:ed54) (Client Quit) |
| 2021-07-14 23:01:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Quit: ec) |
| 2021-07-14 23:03:42 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) (Ping timeout: 258 seconds) |
| 2021-07-14 23:04:14 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 265 seconds) |
| 2021-07-14 23:04:34 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-14 23:05:15 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-14 23:05:51 +0200 | spruit11_ | (~quassel@2a02:a467:ccd6:1:4852:6669:da0c:37fe) |
| 2021-07-14 23:06:42 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 23:09:20 +0200 | spruit11 | (~quassel@2a02:a467:ccd6:1:f403:cf1e:97b5:1c9b) (Ping timeout: 255 seconds) |
| 2021-07-14 23:10:32 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) |
| 2021-07-14 23:11:03 +0200 | zebrag | (~chris@user/zebrag) |
| 2021-07-14 23:11:34 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-14 23:11:58 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-07-14 23:13:12 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2021-07-14 23:13:37 +0200 | Atum_ | (IRC@user/atum/x-2392232) |
| 2021-07-14 23:15:21 +0200 | smichel17 | (~smichel17@c-73-68-217-18.hsd1.ma.comcast.net) (Ping timeout: 265 seconds) |
| 2021-07-14 23:15:23 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2021-07-14 23:15:27 +0200 | zebrag | (~chris@user/zebrag) (Ping timeout: 255 seconds) |
| 2021-07-14 23:15:52 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) |
| 2021-07-14 23:16:38 +0200 | Atum__ | (IRC@user/atum/x-2392232) (Ping timeout: 272 seconds) |
| 2021-07-14 23:16:47 +0200 | neceve | (~quassel@2a02:c7f:607e:d600:f762:20dd:304e:4b1f) (Ping timeout: 245 seconds) |
| 2021-07-14 23:17:34 +0200 | zebrag | (~chris@user/zebrag) |
| 2021-07-14 23:17:38 +0200 | zebrag | (~chris@user/zebrag) (Client Quit) |
| 2021-07-14 23:18:01 +0200 | zebrag | (~chris@user/zebrag) |
| 2021-07-14 23:19:09 +0200 | koolazer | (~koo@user/koolazer) |
| 2021-07-14 23:20:16 +0200 | silverwhitefish | (~hidden@47.202.102.10) |
| 2021-07-14 23:20:30 +0200 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-14 23:20:41 +0200 | burnsidesLlama | (~burnsides@dhcp168-025.wadham.ox.ac.uk) (Ping timeout: 268 seconds) |
| 2021-07-14 23:20:58 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-07-14 23:21:49 +0200 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 2021-07-14 23:22:41 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-07-14 23:29:51 +0200 | Obo | (~roberto@70.pool90-171-81.dynamic.orange.es) (Ping timeout: 265 seconds) |
| 2021-07-14 23:32:17 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 255 seconds) |
| 2021-07-14 23:33:11 +0200 | mikoto-chan | (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) (Ping timeout: 255 seconds) |
| 2021-07-14 23:36:57 +0200 | agua | (~agua@2804:14c:8793:8e2f:d158:60e:567f:c699) |
| 2021-07-14 23:40:39 +0200 | pesada | (~agua@2804:18:4f:750a:1:0:192e:7017) (Ping timeout: 255 seconds) |
| 2021-07-14 23:41:24 +0200 | acidjnk_new3 | (~acidjnk@p200300d0c72b9516b9158842f1cb7e92.dip0.t-ipconnect.de) |
| 2021-07-14 23:42:53 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 23:45:36 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
| 2021-07-14 23:45:45 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-14 23:46:21 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2021-07-14 23:47:15 +0200 | dunj3 | (~dunj3@2001:16b8:30fc:7f00:fd96:42cd:9d60:7ae7) (Remote host closed the connection) |
| 2021-07-14 23:47:39 +0200 | Franciman | (~francesco@openglass.it) |
| 2021-07-14 23:47:53 +0200 | <Franciman> | Hi all, if I want to learn about ghc internals |
| 2021-07-14 23:48:00 +0200 | <Franciman> | do you know a good source? |
| 2021-07-14 23:48:08 +0200 | <maerwald> | Franciman: ghc devs |
| 2021-07-14 23:48:20 +0200 | <Franciman> | hi maerwald |
| 2021-07-14 23:48:21 +0200 | <Franciman> | thanks |
| 2021-07-14 23:49:04 +0200 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) (Quit: WeeChat 3.2) |
| 2021-07-14 23:50:02 +0200 | <geekosaur> | there's some decent docs on the ghc wiki https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/#the-ghc-commentary |
| 2021-07-14 23:53:42 +0200 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-07-14 23:54:25 +0200 | <Franciman> | ty |
| 2021-07-14 23:58:02 +0200 | mei | (~mei@user/mei) (Read error: Connection reset by peer) |