| 2021-09-21 00:00:40 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-21 00:04:27 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 00:04:49 +0200 | <Sqaure> | Say i have a tree-type where each node has a 'parentOpt :: Maybe (Node a)' function defined for it. The traversal from some node to root becomes a list of sorts. Is there some handy type/function that lets me expand that list? Sure, i could write the code for it, but it feels like im dealing with an iterator of sorts here? |
| 2021-09-21 00:05:46 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 00:06:20 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 00:06:38 +0200 | dfg | (~dfg@user/dfg) (Quit: I hate quit messages.) |
| 2021-09-21 00:06:56 +0200 | dfg | (~dfg@li490-89.members.linode.com) |
| 2021-09-21 00:06:56 +0200 | dfg | (~dfg@li490-89.members.linode.com) (Changing host) |
| 2021-09-21 00:06:56 +0200 | dfg | (~dfg@user/dfg) |
| 2021-09-21 00:09:24 +0200 | Guest9212 | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-09-21 00:09:55 +0200 | <awpr> | if you've written a Traversal for it, then `toListOf` will do it. but having a tree with a parent pointer is a bit weird in Haskell, since then either it can't have child pointers, or adding to the tree requires recreating the entire tree |
| 2021-09-21 00:11:15 +0200 | Guest5342 | (~Guest53@103.121.152.207) |
| 2021-09-21 00:12:17 +0200 | <Guest5342> | Hello Everyone, I wanted to know if there's a way to implement a triply linked list in haskell |
| 2021-09-21 00:12:54 +0200 | <Guest5342> | It'll be really great if any of you can help me with this |
| 2021-09-21 00:12:59 +0200 | cuz | (~user@38.140.58.234) (Ping timeout: 246 seconds) |
| 2021-09-21 00:13:12 +0200 | <awpr> | lol awesome, I get to re-send the message I just sent immediately before you joined :) |
| 2021-09-21 00:13:34 +0200 | <awpr> | "having a tree with a parent pointer is a bit weird in Haskell, since then either it can't have child pointers, or adding to the tree requires recreating the entire tree" same applies for doubly- or triply-linked lists |
| 2021-09-21 00:14:16 +0200 | <awpr> | you could make a mutable one in ST or something, but it'd be a bit more cumbersome to use |
| 2021-09-21 00:14:38 +0200 | <Guest5342> | you mean like a finger tree? |
| 2021-09-21 00:14:40 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 268 seconds) |
| 2021-09-21 00:15:34 +0200 | <awpr> | what I mean is that data structures with pointer cycles don't mesh very well with immutability, because every node transitively points to the entire structure |
| 2021-09-21 00:16:06 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 00:16:18 +0200 | <Guest5342> | makes sense but How can i go about creating one anyways? |
| 2021-09-21 00:16:41 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 00:16:46 +0200 | Guest4483 | (~chris@81.96.113.213) |
| 2021-09-21 00:17:06 +0200 | <awpr> | if you want an immutable one despite the fact it can't be used efficiently at all, then "tying the knot" is the term for the trick you'd use |
| 2021-09-21 00:17:53 +0200 | <awpr> | if you want one that can be used efficiently despite it being a bit cumbersome, then you could build one with STRefs for head, prev, and next |
| 2021-09-21 00:18:37 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-21 00:18:37 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-21 00:18:37 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-21 00:18:48 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-09-21 00:19:00 +0200 | <Guest5342> | Ok. Thanks for you help |
| 2021-09-21 00:19:16 +0200 | <awpr> | or I guess there's a third option: if you want a container type you'd use in similar situations to where you'd use doubly-linked lists in imperative languages, then check out Data.Sequence |
| 2021-09-21 00:19:32 +0200 | <Sqaure> | awpr, yeah i know. Im actually asking for a "friend" language. Haskell usually has the answer. =D |
| 2021-09-21 00:20:00 +0200 | pera | (~pera@user/pera) (Quit: leaving) |
| 2021-09-21 00:20:00 +0200 | <Sqaure> | (about parent reference) |
| 2021-09-21 00:20:00 +0200 | <awpr> | (which is based on finger trees and has sub-linear prepend and append) |
| 2021-09-21 00:21:26 +0200 | Guest4483 | (~chris@81.96.113.213) (Ping timeout: 252 seconds) |
| 2021-09-21 00:21:44 +0200 | <Guest5342> | ok. I'll have have a look at that too. |
| 2021-09-21 00:21:53 +0200 | <Guest5342> | Thanks for your time |
| 2021-09-21 00:22:42 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) (Ping timeout: 260 seconds) |
| 2021-09-21 00:23:17 +0200 | fresheyeball | (~fresheyeb@c-76-25-93-164.hsd1.co.comcast.net) |
| 2021-09-21 00:23:29 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 246 seconds) |
| 2021-09-21 00:24:53 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 246 seconds) |
| 2021-09-21 00:25:37 +0200 | cheater | (~Username@user/cheater) |
| 2021-09-21 00:26:26 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 00:27:00 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 00:28:06 +0200 | favonia | (~favonia@user/favonia) |
| 2021-09-21 00:31:22 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-21 00:31:23 +0200 | <awpr> | Sqaure: there's also `unfoldr (fmap (\x -> (x, getParent x))) . Just` |
| 2021-09-21 00:33:06 +0200 | <Sqaure> | awpr, ah. Great, i actually found that one in the java-fp library im using here. Good to know its the same in Haskell. |
| 2021-09-21 00:33:32 +0200 | chris | (~chris@81.96.113.213) |
| 2021-09-21 00:33:36 +0200 | chris | Guest4814 |
| 2021-09-21 00:33:56 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-21 00:33:56 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-21 00:33:56 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-21 00:35:44 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 246 seconds) |
| 2021-09-21 00:36:02 +0200 | phma_ | phma |
| 2021-09-21 00:36:46 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 00:37:20 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 00:42:44 +0200 | acidjnk | (~acidjnk@p200300d0c703cb9700deea61f82c37e2.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2021-09-21 00:46:11 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-09-21 00:46:16 +0200 | cjb | (~cjbayliss@user/cjb) |
| 2021-09-21 00:46:27 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-21 00:47:05 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 00:47:39 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 00:49:22 +0200 | pbrisbin | (~patrick@pool-173-49-147-250.phlapa.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2021-09-21 00:52:25 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 00:57:25 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 00:57:59 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 00:59:03 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 00:59:30 +0200 | <Cajun> | java functional programming sounds scary.. i can only imagine how many angle brackets you would need |
| 2021-09-21 01:00:27 +0200 | <meejah> | probably same order as brackets in lisp ;) |
| 2021-09-21 01:06:42 +0200 | <hpc> | the creator of java generics is one of the creators of haskell |
| 2021-09-21 01:07:44 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 01:08:18 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 01:09:34 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 01:13:02 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2021-09-21 01:15:32 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-50.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2021-09-21 01:18:04 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 01:18:38 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 01:21:59 +0200 | Guest5342 | (~Guest53@103.121.152.207) (Ping timeout: 256 seconds) |
| 2021-09-21 01:23:55 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2021-09-21 01:28:24 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 01:28:58 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 01:32:11 +0200 | alzgh | (~alzgh@user/alzgh) (Ping timeout: 256 seconds) |
| 2021-09-21 01:32:58 +0200 | <monochrom> | Angle brackets would be parametric polymorphic programming, which is orthogonal to functional programming. |
| 2021-09-21 01:33:43 +0200 | <monochrom> | To wit, you could already do that in Ada and C++. |
| 2021-09-21 01:34:52 +0200 | tremon | (~tremon@217-63-61-89.cable.dynamic.v4.ziggo.nl) (Quit: getting boxed in) |
| 2021-09-21 01:35:24 +0200 | <monochrom> | Functional programming in Java would be full of lambdas and/or anonymous classes instead. |
| 2021-09-21 01:37:46 +0200 | <monochrom> | Unpopular opinion: Anonymous subclassing is a kind of defunctionalization. >:) |
| 2021-09-21 01:38:18 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 01:38:44 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 01:39:18 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 01:42:19 +0200 | <Cajun> | i had a good time using a basic GUI library in java, it was fairly simple to just make Runnables with the sugar java 13 (?) gives for it. i havent tried to GUI program in haskell (but it seems rather complicated, but i havent read the docs! :P ) |
| 2021-09-21 01:43:44 +0200 | <Cajun> | it just never felt ergonomic to use generics in java, as much as i love the language. it was really heavy to use them, lots and lots of ugly angle brackets. but it worked well and i didnt touch it much, so i dont have much room to complain *shrug* |
| 2021-09-21 01:47:20 +0200 | <Cajun> | then haskell felt like magic with polymorphism, it was so amazing to basically have it extremely ergonomic to just type `a` (and faster than typing the monomorphic type!) |
| 2021-09-21 01:47:57 +0200 | cuz | (~user@2601:182:cc02:8b0:88fe:7ac8:b1af:1fac) |
| 2021-09-21 01:48:05 +0200 | cuz | (~user@2601:182:cc02:8b0:88fe:7ac8:b1af:1fac) (Remote host closed the connection) |
| 2021-09-21 01:48:18 +0200 | cuz | (~user@2601:182:cc02:8b0:88fe:7ac8:b1af:1fac) |
| 2021-09-21 01:49:04 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 01:49:04 +0200 | <Cajun> | javas done a lot to become more multi-paradigm, but it doesnt seem as eager as C# is in that respect |
| 2021-09-21 01:49:39 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 01:50:03 +0200 | <shapr> | C# also got a bunch of stuff from Haskell: https://en.wikipedia.org/wiki/Erik_Meijer_(computer_scientist) |
| 2021-09-21 01:50:12 +0200 | <shapr> | linq, etc |
| 2021-09-21 01:52:26 +0200 | <Cajun> | ive heard good things about LINQ. but i dont really like the flexibility of case insensitivity the language has (functions should start lowercase...) |
| 2021-09-21 01:55:58 +0200 | <sclv> | really elegant gui programming just requires a level of engineering polish and support that's not out there enough in the haskell ecosystem (not to mention solving all the linker woes, etc, which java sidesteps by shipping a full gui lib for each platform as part of the core) |
| 2021-09-21 01:56:15 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-21 01:56:44 +0200 | <sclv> | like, conceptually, guis in haskell can be nice. but practically there's only a few choices of libs out there that tick all the boxes of being cross-platform, ergonomic, not insane to install, etc |
| 2021-09-21 01:57:18 +0200 | <sclv> | and the fact that all the gui libs we bind to tend to be so soaked in the OO paradigm makes for some unfortunate impedance mismatch too |
| 2021-09-21 01:59:24 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 01:59:59 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 02:03:33 +0200 | <Cale> | There's gi-gtk-hs, which has seemed pretty usable. I've barely been using it though, really, since we've just been drawing most of our UI with cairo :P |
| 2021-09-21 02:03:50 +0200 | <sclv> | and fltkhs too |
| 2021-09-21 02:04:06 +0200 | <sclv> | i don't consider the gtk stuff super cross platform based on past experience, but things may be substantially better now |
| 2021-09-21 02:04:40 +0200 | <sm> | monomer is the latest contender |
| 2021-09-21 02:05:02 +0200 | <Cale> | Coming at it from another angle, reflex-dom is another option |
| 2021-09-21 02:05:25 +0200 | <Cajun> | i tried to use monomer a while back and it was a bit broken to say the least |
| 2021-09-21 02:05:48 +0200 | <sclv> | hrm, hadn't seen it before, might have missed some announcements on it? on the face of it, claims a nice set of features |
| 2021-09-21 02:05:52 +0200 | <sm> | darn I was just thinking "no-one has panned it yet" |
| 2021-09-21 02:06:05 +0200 | <sm> | Cajun: do you mean, after you got it installed ? |
| 2021-09-21 02:06:17 +0200 | <sclv> | 😂 |
| 2021-09-21 02:06:23 +0200 | vysn | (~vysn@user/vysn) (Remote host closed the connection) |
| 2021-09-21 02:06:37 +0200 | <Cale> | (We use it to make apps for the Web, iOS and Android mobile devices from the same codebase, which are the three platforms anyone cares about these days.) |
| 2021-09-21 02:06:44 +0200 | <Cajun> | well that may not entirely be true, it seemed to be tuned for windows (it couldnt find the library on linux) and one of the dev's pushes to a library wasnt fully accepted yet |
| 2021-09-21 02:06:46 +0200 | <sm> | https://www.reddit.com/r/haskell/comments/p12pjs/ann_monomer_a_gui_library_for_haskell/, sclv |
| 2021-09-21 02:07:20 +0200 | <Cajun> | i havent checked on it since, but i really do hope it works well |
| 2021-09-21 02:07:25 +0200 | <sm> | ah, that's small stuff |
| 2021-09-21 02:07:50 +0200 | <Cajun> | small stuff that made it a pita to deal with, so i just dropped it and promised myself to try it again at a later date |
| 2021-09-21 02:08:07 +0200 | <sm> | sure, same here (it doesn't build on m1 yet) |
| 2021-09-21 02:08:18 +0200 | <sm> | s/small/fixable/ |
| 2021-09-21 02:09:41 +0200 | Gurkenglas | (~Gurkengla@dslb-002-207-014-195.002.207.pools.vodafone-ip.de) (Ping timeout: 264 seconds) |
| 2021-09-21 02:09:44 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 02:10:19 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 02:10:57 +0200 | alx741 | (~alx741@186.178.109.159) |
| 2021-09-21 02:11:02 +0200 | <sclv> | reading through monomer's docs i'm reminded again that the "elm architecture" seems to be just like a rebranded mvc |
| 2021-09-21 02:11:31 +0200 | <sclv> | which i didn't mind when it was in elm, but now seeing it as a term of the art in other contexts is frying my head a bit |
| 2021-09-21 02:11:58 +0200 | Guest57 | (~Guest57@134.3.172.96) |
| 2021-09-21 02:12:27 +0200 | hexfive | (~eric@50.35.83.177) |
| 2021-09-21 02:12:41 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-21 02:13:20 +0200 | jespada | (~jespada@2803:9800:9842:7a62:edd5:5e74:3ec2:1b19) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-09-21 02:17:58 +0200 | Guest57 | (~Guest57@134.3.172.96) (Quit: Client closed) |
| 2021-09-21 02:20:04 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 02:20:40 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 02:22:36 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 02:22:49 +0200 | hexfive | (~eric@50.35.83.177) (Quit: WeeChat 3.0.1) |
| 2021-09-21 02:25:04 +0200 | Igloo | (~ian@matrix.chaos.earth.li) (Ping timeout: 252 seconds) |
| 2021-09-21 02:26:50 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-21 02:29:28 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 252 seconds) |
| 2021-09-21 02:30:34 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 02:31:07 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2021-09-21 02:31:08 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 02:37:18 +0200 | maroloccio | (~marolocci@89-172-7-22.adsl.net.t-com.hr) |
| 2021-09-21 02:38:45 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) (Good Bye) |
| 2021-09-21 02:40:54 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 02:41:28 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 02:41:39 +0200 | Igloo | (~ian@matrix.chaos.earth.li) |
| 2021-09-21 02:42:37 +0200 | <justsomeguy> | I felt the same way when reading about "stateless" "declarative" configuration management platforms. |
| 2021-09-21 02:43:53 +0200 | cuz | (~user@2601:182:cc02:8b0:88fe:7ac8:b1af:1fac) (Ping timeout: 264 seconds) |
| 2021-09-21 02:45:12 +0200 | <Cale> | You really need a way to structure the state in large interactive applications a bit better. Having the top level need to "know about" everything in the entire application is really not okay past a certain point. |
| 2021-09-21 02:46:25 +0200 | <Cale> | I think the right thing is for the accumulation of any given piece of state to happen just above every part of the application that cares about it, and no higher up than that. |
| 2021-09-21 02:47:03 +0200 | <Cale> | At least, that's a decent rule of thumb. |
| 2021-09-21 02:50:00 +0200 | <Cale> | "Everything potentially depends on everything else" is still bad, even if you can describe the relationship through time using a pure function. |
| 2021-09-21 02:51:14 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 02:51:48 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 02:57:21 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 03:01:25 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-21 03:01:34 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 03:02:08 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 03:02:43 +0200 | Guest4814 | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-09-21 03:03:40 +0200 | chris | (~chris@81.96.113.213) |
| 2021-09-21 03:03:44 +0200 | chris | Guest8879 |
| 2021-09-21 03:06:46 +0200 | <sm> | +1! |
| 2021-09-21 03:08:05 +0200 | Guest8879 | (~chris@81.96.113.213) (Ping timeout: 252 seconds) |
| 2021-09-21 03:11:16 +0200 | waleee | (~waleee@h-98-128-228-119.na.cust.bahnhof.se) (Ping timeout: 252 seconds) |
| 2021-09-21 03:11:29 +0200 | xff0x | (~xff0x@83.236.31.114) (Ping timeout: 264 seconds) |
| 2021-09-21 03:11:50 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 246 seconds) |
| 2021-09-21 03:11:54 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 03:12:28 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 03:13:16 +0200 | xff0x | (~xff0x@2001:1a81:53a2:cb00:c07c:d089:8b2f:814c) |
| 2021-09-21 03:22:13 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 03:22:30 +0200 | alx741 | (~alx741@186.178.109.159) (Quit: alx741) |
| 2021-09-21 03:22:47 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 03:23:49 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 03:25:08 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 246 seconds) |
| 2021-09-21 03:26:33 +0200 | neurocyte0133 | (~neurocyte@212.232.95.106) |
| 2021-09-21 03:26:33 +0200 | neurocyte0133 | (~neurocyte@212.232.95.106) (Changing host) |
| 2021-09-21 03:26:33 +0200 | neurocyte0133 | (~neurocyte@user/neurocyte) |
| 2021-09-21 03:28:54 +0200 | neurocyte013 | (~neurocyte@user/neurocyte) (Ping timeout: 260 seconds) |
| 2021-09-21 03:28:54 +0200 | neurocyte0133 | neurocyte013 |
| 2021-09-21 03:30:30 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 03:31:55 +0200 | cheater | (~Username@user/cheater) |
| 2021-09-21 03:32:33 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 03:33:07 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 03:33:52 +0200 | <justsomeguy> | I think I've just started keeping a list of maintenance programmer adages, starting with your quote :^) |
| 2021-09-21 03:41:49 +0200 | brettgilio | (~brettgili@x-node.gq) (Quit: Leaving...) |
| 2021-09-21 03:42:53 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 03:42:56 +0200 | brettgilio | (~brettgili@x-node.gq) |
| 2021-09-21 03:43:28 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 03:53:14 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 03:53:50 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 03:58:27 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2021-09-21 04:00:52 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 04:03:06 +0200 | favonia | (~favonia@user/favonia) |
| 2021-09-21 04:06:51 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 04:09:06 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 04:09:31 +0200 | Jonno_FTW | (~come@api.carswap.me) (Changing host) |
| 2021-09-21 04:09:31 +0200 | Jonno_FTW | (~come@user/jonno-ftw/x-0835346) |
| 2021-09-21 04:10:48 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 276 seconds) |
| 2021-09-21 04:16:41 +0200 | yinghua | (~yinghua@2800:2121:1400:1db:3d91:483:36a2:ad4f) (Quit: Leaving) |
| 2021-09-21 04:16:48 +0200 | td_ | (~td@muedsl-82-207-238-087.citykom.de) (Ping timeout: 268 seconds) |
| 2021-09-21 04:18:20 +0200 | td_ | (~td@muedsl-82-207-238-060.citykom.de) |
| 2021-09-21 04:18:50 +0200 | tommd | (~tommd@75-164-130-101.ptld.qwest.net) (Ping timeout: 260 seconds) |
| 2021-09-21 04:19:01 +0200 | chris | (~chris@81.96.113.213) |
| 2021-09-21 04:19:05 +0200 | chris | Guest3810 |
| 2021-09-21 04:20:11 +0200 | Guest3810 | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-09-21 04:23:44 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2021-09-21 04:27:11 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-09-21 04:30:02 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-09-21 04:36:41 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 264 seconds) |
| 2021-09-21 04:37:40 +0200 | Katarushisu | (~Katarushi@cpc147334-finc20-2-0-cust27.4-2.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2021-09-21 04:39:14 +0200 | xiongxin | (~quassel@119.123.103.94) |
| 2021-09-21 04:42:19 +0200 | chris | (~chris@81.96.113.213) |
| 2021-09-21 04:42:23 +0200 | chris | Guest8457 |
| 2021-09-21 04:43:17 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-21 04:43:54 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-21 04:44:53 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 252 seconds) |
| 2021-09-21 04:45:29 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 04:46:29 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2021-09-21 04:50:23 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-21 04:53:10 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-21 04:53:10 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-21 04:53:10 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-21 04:54:37 +0200 | Katarushisu | (~Katarushi@cpc147334-finc20-2-0-cust27.4-2.cable.virginm.net) |
| 2021-09-21 04:57:41 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 264 seconds) |
| 2021-09-21 04:57:41 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-21 04:58:22 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 05:02:29 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 264 seconds) |
| 2021-09-21 05:06:53 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-09-21 05:07:14 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-21 05:11:53 +0200 | hiruji` | (~hiruji@2606:6080:1001:f:ed79:9361:ea0e:3e88) (Ping timeout: 246 seconds) |
| 2021-09-21 05:14:24 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 05:15:23 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) |
| 2021-09-21 05:16:57 +0200 | statusbot | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) (Read error: Connection reset by peer) |
| 2021-09-21 05:17:03 +0200 | statusbot1 | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) |
| 2021-09-21 05:17:29 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-21 05:19:58 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2021-09-21 05:22:59 +0200 | cjb41988 | (~cjbayliss@user/cjb) |
| 2021-09-21 05:23:20 +0200 | cjb41988 | (~cjbayliss@user/cjb) (Client Quit) |
| 2021-09-21 05:24:08 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 05:24:43 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 05:24:50 +0200 | cjb84397 | (~cjbayliss@user/cjb) |
| 2021-09-21 05:25:15 +0200 | cjb | Guest2446 |
| 2021-09-21 05:25:15 +0200 | cjb84397 | cjb |
| 2021-09-21 05:25:16 +0200 | Guest2446 | (~cjbayliss@user/cjb) (Ping timeout: 260 seconds) |
| 2021-09-21 05:26:00 +0200 | wei2912 | (~wei2912@112.199.250.21) |
| 2021-09-21 05:32:37 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 05:32:57 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.2) |
| 2021-09-21 05:34:29 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 05:35:03 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 05:35:17 +0200 | hiruji | (~hiruji@user/hiruji) |
| 2021-09-21 05:37:17 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 264 seconds) |
| 2021-09-21 05:38:07 +0200 | juhp | (~juhp@bb42-60-204-249.singnet.com.sg) (Ping timeout: 265 seconds) |
| 2021-09-21 05:39:53 +0200 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) (Ping timeout: 246 seconds) |
| 2021-09-21 05:43:48 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) (Good Bye) |
| 2021-09-21 05:46:03 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2021-09-21 05:46:16 +0200 | favonia | (~favonia@user/favonia) |
| 2021-09-21 05:47:16 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 05:47:50 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 05:51:53 +0200 | Guest8457 | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-09-21 05:55:48 +0200 | sagax | (~sagax_nb@user/sagax) |
| 2021-09-21 05:57:29 +0200 | neo1 | (~neo3@cpe-292712.ip.primehome.com) |
| 2021-09-21 05:57:34 +0200 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2021-09-21 05:57:37 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 05:58:10 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 06:03:16 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) |
| 2021-09-21 06:07:56 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 06:08:31 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 06:14:51 +0200 | Guest372 | (~xxx@47.245.54.240) (Remote host closed the connection) |
| 2021-09-21 06:15:58 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2021-09-21 06:15:58 +0200 | Guest372 | (~xxx@47.245.54.240) |
| 2021-09-21 06:17:05 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2021-09-21 06:19:34 +0200 | slowButPresent | (~slowButPr@user/slowbutpresent) (Quit: leaving) |
| 2021-09-21 06:19:53 +0200 | maroloccio | (~marolocci@89-172-7-22.adsl.net.t-com.hr) (Ping timeout: 264 seconds) |
| 2021-09-21 06:21:50 +0200 | maroloccio | (~marolocci@93-142-92-177.adsl.net.t-com.hr) |
| 2021-09-21 06:24:08 +0200 | ubert | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) |
| 2021-09-21 06:25:15 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 06:25:49 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 06:30:33 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 06:33:05 +0200 | doyougnu | (~user@c-73-25-202-122.hsd1.or.comcast.net) (Ping timeout: 264 seconds) |
| 2021-09-21 06:35:35 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 06:36:05 +0200 | xiongxin | (~quassel@119.123.103.94) (Ping timeout: 264 seconds) |
| 2021-09-21 06:36:10 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 06:39:38 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 06:44:31 +0200 | shriekingnoise | (~shrieking@186.137.144.80) (Quit: Quit) |
| 2021-09-21 06:45:56 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 06:46:30 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 06:48:02 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-21 06:49:20 +0200 | <Izem> | Are the items in parentheses sections? `showsTree (Branch l r) = ('<':) . showsTree l . ('|':) . showsTree r . ('>':)` |
| 2021-09-21 06:50:10 +0200 | <awpr> | yes, operator sections of `(:)` |
| 2021-09-21 06:50:59 +0200 | <awpr> | they could also be replaced with `showChar '<'`, for example |
| 2021-09-21 06:51:23 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2021-09-21 06:52:37 +0200 | xiongxin | (~quassel@119.123.103.94) |
| 2021-09-21 06:52:53 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 264 seconds) |
| 2021-09-21 06:56:03 +0200 | flouflou | (~flouflou@modemcable032.110-177-173.mc.videotron.ca) (Quit: WeeChat 3.2) |
| 2021-09-21 06:56:16 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 06:56:50 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 06:57:05 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 06:59:16 +0200 | <jle`> | Izem: if it's easier to see, you can write it as ('<' :) . showsTree l . ('|' :) . showsTree r . ('>' :) |
| 2021-09-21 06:59:49 +0200 | <Izem> | yeah, good call |
| 2021-09-21 07:00:08 +0200 | <Izem> | (in this case not much difference because my client does not use monospace characters) |
| 2021-09-21 07:00:19 +0200 | <jle`> | i'll admit the '<': four symbols in a row did throw me off |
| 2021-09-21 07:00:31 +0200 | <jle`> | despite writing haskell for a while now |
| 2021-09-21 07:04:48 +0200 | <Izem> | I'll take a note when I write "Elements of Style" for Haskell ;) |
| 2021-09-21 07:05:44 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) (Quit: Izem) |
| 2021-09-21 07:06:36 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 07:07:09 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 07:07:17 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-21 07:07:43 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-21 07:07:43 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-21 07:07:43 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-21 07:08:50 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) |
| 2021-09-21 07:08:53 +0200 | Guest68 | (~Guest68@103.121.152.207) |
| 2021-09-21 07:12:17 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2021-09-21 07:13:56 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-21 07:21:18 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 07:26:53 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 07:27:27 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 07:31:00 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 07:35:01 +0200 | cjb | (~cjbayliss@user/cjb) () |
| 2021-09-21 07:37:12 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 07:37:38 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 07:37:46 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 07:44:11 +0200 | <Axman6> | > let (<') a b = a <> b in "hello"<'" "<'"world" |
| 2021-09-21 07:44:13 +0200 | <lambdabot> | <hint>:1:8: error: parse error on input ‘)’ |
| 2021-09-21 07:44:14 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2021-09-21 07:44:44 +0200 | <Axman6> | pretty happy that didn't work tbh |
| 2021-09-21 07:45:39 +0200 | <ldlework> | > let (<:) a b = a < b in "hello" <: " " <: "world" |
| 2021-09-21 07:45:40 +0200 | <lambdabot> | error: |
| 2021-09-21 07:45:40 +0200 | <lambdabot> | • Couldn't match expected type ‘Bool’ with actual type ‘[Char]’ |
| 2021-09-21 07:45:40 +0200 | <lambdabot> | • In the second argument of ‘(<:)’, namely ‘"world"’ |
| 2021-09-21 07:46:18 +0200 | <ldlework> | > let (:<<) a b = a < b in "hello" :<< " " :<< "world" |
| 2021-09-21 07:46:20 +0200 | <lambdabot> | error: |
| 2021-09-21 07:46:20 +0200 | <lambdabot> | Not in scope: data constructor ‘:<<’ |
| 2021-09-21 07:46:20 +0200 | <lambdabot> | Perhaps you meant one of these: |
| 2021-09-21 07:46:26 +0200 | ldlework | shrugs |
| 2021-09-21 07:46:44 +0200 | <ldlework> | oops |
| 2021-09-21 07:46:52 +0200 | <ldlework> | > let (:<<) a b = a <> b in "hello" :<< " " :<< "world" |
| 2021-09-21 07:46:53 +0200 | <lambdabot> | error: |
| 2021-09-21 07:46:53 +0200 | <lambdabot> | Not in scope: data constructor ‘:<<’ |
| 2021-09-21 07:46:53 +0200 | <lambdabot> | Perhaps you meant one of these: |
| 2021-09-21 07:46:57 +0200 | ldlework | shrugs |
| 2021-09-21 07:47:03 +0200 | <Axman6> | can't start functions with : |
| 2021-09-21 07:47:13 +0200 | <Axman6> | only constructors |
| 2021-09-21 07:47:21 +0200 | <ldlework> | > let (<<:) a b = a <> b in "hello" <<: " " <<: "world" |
| 2021-09-21 07:47:22 +0200 | <lambdabot> | "hello world" |
| 2021-09-21 07:47:26 +0200 | <ldlework> | \o/ |
| 2021-09-21 07:47:45 +0200 | <Axman6> | stop making the C++ devs feel comfortable |
| 2021-09-21 07:48:06 +0200 | <ldlework> | a friend of mine was dissing haskell because of all the wierd operators |
| 2021-09-21 07:48:19 +0200 | <ldlework> | and i'm like, dude, they're just functions, with non-alphanumeric names, that can be called infix |
| 2021-09-21 07:48:27 +0200 | <ldlework> | eventually he reduced his argument to "the names are dumb" |
| 2021-09-21 07:48:39 +0200 | <ldlework> | hehe |
| 2021-09-21 07:48:59 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2021-09-21 07:50:32 +0200 | <awpr> | tbf some of the names can get pretty crazy... `<<%@~` is a real operator in `lens` |
| 2021-09-21 07:51:08 +0200 | <Axman6> | but is a completely consistent operator, and I can probably figure out what it does even without its type |
| 2021-09-21 07:51:09 +0200 | <awpr> | I'm sure it means something if you've learned the symbolic etymology of the lens operators, but I haven't |
| 2021-09-21 07:51:13 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) (Remote host closed the connection) |
| 2021-09-21 07:51:40 +0200 | <awpr> | from scrolling I've gathered the @ is an indexed variant |
| 2021-09-21 07:51:41 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) (Ping timeout: 264 seconds) |
| 2021-09-21 07:51:47 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) |
| 2021-09-21 07:51:58 +0200 | <Axman6> | ~ means apply a function, @ I think means apply to an indexed lens, and I thing << means return the value before the function was applied that the optic pointed to |
| 2021-09-21 07:52:16 +0200 | <Axman6> | % :t (<<%@~) |
| 2021-09-21 07:52:16 +0200 | <yahb> | Axman6: Over (Indexed i) ((,) a) s t a b -> (i -> a -> b) -> s -> (a, t) |
| 2021-09-21 07:53:37 +0200 | <Axman6> | yep - an indexed lens pointing to an a, a function whicht akes the index and the a and produces a b, that b is set in s to give a t and the original a is returned. Generalised x++ where you can choose what ++ is and change the type |
| 2021-09-21 07:54:27 +0200 | <Axman6> | jackdk will remember the day I replaced five lines of code using MonadState with a single line using the stateful version of this function which ended up being clearer too (IMO) |
| 2021-09-21 07:54:39 +0200 | <Axman6> | % :t (<<%@=) |
| 2021-09-21 07:54:39 +0200 | <yahb> | Axman6: MonadState s m => Over (Indexed i) ((,) a) s s a b -> (i -> a -> b) -> m a |
| 2021-09-21 07:55:32 +0200 | <jackdk> | oh yeah, indexed monadic state update, returning original result. The power of a consistent symbol language |
| 2021-09-21 08:00:50 +0200 | Guest68 | (~Guest68@103.121.152.207) (Quit: Client closed) |
| 2021-09-21 08:00:54 +0200 | Null_A | (~null_a@2601:645:8700:2290:6daa:6a79:97ab:557) () |
| 2021-09-21 08:06:41 +0200 | xiongxin | (~quassel@119.123.103.94) (Ping timeout: 264 seconds) |
| 2021-09-21 08:06:57 +0200 | xiongxin | (~quassel@113.116.32.188) |
| 2021-09-21 08:13:19 +0200 | kuribas | (~user@ptr-25vy0i747grimuk7ofw.18120a2.ip6.access.telenet.be) |
| 2021-09-21 08:15:01 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:4252:bf51:4908:8ea0) |
| 2021-09-21 08:17:13 +0200 | bgamari_ | (~bgamari@64.223.239.239) |
| 2021-09-21 08:17:25 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 08:17:39 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 08:18:42 +0200 | bgamari | (~bgamari@71.241.201.27) (Ping timeout: 260 seconds) |
| 2021-09-21 08:26:45 +0200 | <awpr> | `profunctors` package synopsis: "Profunctors", package description: "Profunctors." |
| 2021-09-21 08:27:09 +0200 | <awpr> | cabal has a warning when uploading packages, "the description should be longer than the synopsis" :D |
| 2021-09-21 08:27:53 +0200 | xiongxin | (~quassel@113.116.32.188) (Ping timeout: 246 seconds) |
| 2021-09-21 08:31:23 +0200 | neurocyte013 | (~neurocyte@user/neurocyte) (Ping timeout: 246 seconds) |
| 2021-09-21 08:32:52 +0200 | qbt | (~edun@user/edun) |
| 2021-09-21 08:33:56 +0200 | alzgh | (~alzgh@user/alzgh) |
| 2021-09-21 08:40:34 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-09-21 08:43:11 +0200 | <ldlework> | awpr: I think they meant more like "functor" "monoid" etc |
| 2021-09-21 08:44:08 +0200 | <ldlework> | Which of course are not the names of the operators, but I knew what they meant. |
| 2021-09-21 08:47:05 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 08:47:53 +0200 | <[exa]> | awpr: that's mean, they made such an effort with the '.' |
| 2021-09-21 08:49:15 +0200 | Gurkenglas | (~Gurkengla@dslb-002-207-014-195.002.207.pools.vodafone-ip.de) |
| 2021-09-21 08:50:57 +0200 | vaucouleur | (~vaucouleu@78.194.70.105) |
| 2021-09-21 08:51:50 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-21 08:52:39 +0200 | <c_wraith> | Honestly, the profunctors package is in an awkward spot. It would be in base, if it wasn't for the usefulness of #. and .# |
| 2021-09-21 08:52:53 +0200 | <c_wraith> | No one quite wants to commit to putting hacks like that in base |
| 2021-09-21 08:53:11 +0200 | xiongxin | (~quassel@119.123.103.94) |
| 2021-09-21 08:53:24 +0200 | <ldlework> | profunctors - must be something to do with lifing a function over structure, but what |
| 2021-09-21 08:53:51 +0200 | <ldlework> | maybe they get paid to lift, that's why they're "pro" |
| 2021-09-21 08:54:35 +0200 | <c_wraith> | Profunctors are function-shaped functors. Contravariant in one type variable, covariant in the other. |
| 2021-09-21 08:54:39 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-09-21 08:54:58 +0200 | <awpr> | profunctors are just functors from op(Hask) x Hask to Hask, what's the problem? |
| 2021-09-21 08:55:45 +0200 | <ldlework> | :S |
| 2021-09-21 08:55:51 +0200 | <awpr> | (I've always wanted to write my own needlessly inscrutable "what's the problem?" statement!) |
| 2021-09-21 08:56:00 +0200 | <ldlework> | function-shaped functors? But functors are already functions being lifted over structure. |
| 2021-09-21 08:56:18 +0200 | <ldlework> | Or do we mean, that the lhs of fmap is a function returning a function? |
| 2021-09-21 08:56:25 +0200 | <c_wraith> | neither. |
| 2021-09-21 08:56:28 +0200 | <ldlework> | I tried. |
| 2021-09-21 08:57:04 +0200 | <c_wraith> | It means that in Profunctor p => p a b, a is negative and b is positive, and you can map over either appropriately |
| 2021-09-21 08:57:19 +0200 | <c_wraith> | functions are a trivial example of that. |
| 2021-09-21 08:57:30 +0200 | <ldlework> | what's meant by negative/positive? |
| 2021-09-21 08:57:54 +0200 | <ldlework> | Or are we talking about something like Either's Left/Right? |
| 2021-09-21 08:58:06 +0200 | <c_wraith> | Nah, Either is positive in both |
| 2021-09-21 08:58:16 +0200 | <ldlework> | o_O |
| 2021-09-21 08:58:16 +0200 | <c_wraith> | that is, it can produce a value of those types |
| 2021-09-21 08:58:27 +0200 | <c_wraith> | it produces trivially by containing one of them. |
| 2021-09-21 08:58:45 +0200 | <c_wraith> | A type in a negative position is being consumed |
| 2021-09-21 08:58:56 +0200 | <c_wraith> | which basically means "an argument to a function" |
| 2021-09-21 08:59:15 +0200 | <ldlework> | So you're saying `b` is the type being produced, `a` is the type we're computing over? |
| 2021-09-21 08:59:33 +0200 | <c_wraith> | `a` is being consumed. |
| 2021-09-21 08:59:44 +0200 | <ldlework> | that's what i meant by being computed over I guess |
| 2021-09-21 08:59:49 +0200 | <ldlework> | not sure what other sense there is |
| 2021-09-21 08:59:53 +0200 | <c_wraith> | There's no guarantee it's related to the b value |
| 2021-09-21 09:00:14 +0200 | <ldlework> | Is there a trivial list/string example |
| 2021-09-21 09:00:20 +0200 | <c_wraith> | like... data Z a b = Z (a -> String) (Int -> b) |
| 2021-09-21 09:00:33 +0200 | <c_wraith> | there's no relationship between the a values and the b values |
| 2021-09-21 09:00:46 +0200 | <c_wraith> | they just are the right sorts of things |
| 2021-09-21 09:00:46 +0200 | vaucouleur | (~vaucouleu@78.194.70.105) (Remote host closed the connection) |
| 2021-09-21 09:00:52 +0200 | <ldlework> | Then what are we doing with them |
| 2021-09-21 09:01:01 +0200 | <c_wraith> | Profunctor doesn't care. |
| 2021-09-21 09:01:08 +0200 | <c_wraith> | It just lets you map over each |
| 2021-09-21 09:01:22 +0200 | <ldlework> | How do you map over a function |
| 2021-09-21 09:01:56 +0200 | <ldlework> | IIRC, that just means to map over its output value right? |
| 2021-09-21 09:02:11 +0200 | <c_wraith> | actually, let me simplify that. |
| 2021-09-21 09:02:14 +0200 | <ldlework> | OK |
| 2021-09-21 09:02:20 +0200 | <c_wraith> | data Z a b = Z (a -> String) b |
| 2021-09-21 09:02:40 +0200 | <ldlework> | So would profunctor call a, disregard the string, and then return b? |
| 2021-09-21 09:02:52 +0200 | <c_wraith> | No, the a and b type variables are totally separate. |
| 2021-09-21 09:02:56 +0200 | nctcf^ | (~nctcf@12.203.127.82) (Remote host closed the connection) |
| 2021-09-21 09:03:05 +0200 | <c_wraith> | Profunctor does not assume they're related. |
| 2021-09-21 09:03:07 +0200 | <ldlework> | they're not related in my description |
| 2021-09-21 09:03:17 +0200 | <c_wraith> | calling a function assumes they're related. |
| 2021-09-21 09:03:27 +0200 | <ldlework> | Z somFun someConst |
| 2021-09-21 09:03:35 +0200 | <ldlework> | someFun someA |
| 2021-09-21 09:03:37 +0200 | <ldlework> | then just return b |
| 2021-09-21 09:03:40 +0200 | <ldlework> | return someConst |
| 2021-09-21 09:03:43 +0200 | <ldlework> | how are they related? |
| 2021-09-21 09:04:30 +0200 | <ldlework> | i guess there's no point in calling `someFun someA` if it's output isn't used, and it has no effects though? |
| 2021-09-21 09:04:39 +0200 | <c_wraith> | exactly. That's why it doesn't do that. |
| 2021-09-21 09:05:32 +0200 | <ldlework> | I should probably learn what contravariance and covariance are |
| 2021-09-21 09:05:43 +0200 | <c_wraith> | it's basically just the direction of mapping. |
| 2021-09-21 09:06:33 +0200 | <c_wraith> | dimap :: (a -> b) -> (c -> d) -> Z b c -> Z a d ; dimap f g (Z h x) = Z (h . f) (g x) |
| 2021-09-21 09:07:21 +0200 | <c_wraith> | Contravariant means the map goes backwards. |
| 2021-09-21 09:08:02 +0200 | <c_wraith> | You see how there's an (a -> b) argument, but the type change is Z *b* c -> Z *a* d? |
| 2021-09-21 09:08:34 +0200 | <c_wraith> | the types change in the opposite direction as the conversion function |
| 2021-09-21 09:08:41 +0200 | <ldlework> | contramap :: (a0 -> a1) -> f a1 -> f a0 |
| 2021-09-21 09:08:44 +0200 | <ldlework> | this is confusing indeed |
| 2021-09-21 09:09:03 +0200 | <c_wraith> | It only works with things that are function arguments or phantom |
| 2021-09-21 09:09:32 +0200 | neo1 | (~neo3@cpe-292712.ip.primehome.com) (Read error: Connection reset by peer) |
| 2021-09-21 09:10:23 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 09:10:24 +0200 | <ldlework> | I think I need to better my understanding of the Functor of functions |
| 2021-09-21 09:10:56 +0200 | <c_wraith> | write a Functor instance for data F a b = F (a -> b) |
| 2021-09-21 09:11:19 +0200 | <c_wraith> | or newtype, whatever :) |
| 2021-09-21 09:12:09 +0200 | chele | (~chele@user/chele) |
| 2021-09-21 09:14:46 +0200 | <Guest372> | :t withFile |
| 2021-09-21 09:14:47 +0200 | <lambdabot> | error: |
| 2021-09-21 09:14:47 +0200 | <lambdabot> | • Variable not in scope: withFile |
| 2021-09-21 09:14:47 +0200 | <lambdabot> | • Perhaps you meant one of these: |
| 2021-09-21 09:17:05 +0200 | <Guest372> | withFile :: FilePath -> IOMode -> (Handle -> IO r) -> IO r, why it uses (Handle -> IO r) -> IO r? not just IO r? |
| 2021-09-21 09:17:18 +0200 | neo1 | (~neo3@cpe-292712.ip.primehome.com) |
| 2021-09-21 09:17:32 +0200 | <c_wraith> | because the point is it closes the file when the function you pass to it completes |
| 2021-09-21 09:17:52 +0200 | <Guest372> | or just ContT r IO Handle? |
| 2021-09-21 09:17:53 +0200 | max22- | (~maxime@2a01cb08833598000f1fa44417d80ccf.ipv6.abo.wanadoo.fr) |
| 2021-09-21 09:18:11 +0200 | <c_wraith> | Because Codensity IO Handle is better. :P |
| 2021-09-21 09:18:19 +0200 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) |
| 2021-09-21 09:19:05 +0200 | <Guest372> | close the file by the function you pass it or withFile itself? |
| 2021-09-21 09:19:30 +0200 | <c_wraith> | withFile closes the file when the function passed to it exits - normally or via exception |
| 2021-09-21 09:19:33 +0200 | jstolarek | (~jstolarek@erx128.neoplus.adsl.tpnet.pl) |
| 2021-09-21 09:19:52 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 09:20:25 +0200 | <Guest372> | aha, it will retur to withFile, that's I dont know |
| 2021-09-21 09:20:31 +0200 | <c_wraith> | And you're right about ContT being usable to flip that control flow back around. http://blog.sigfpe.com/2011/10/quick-and-dirty-reinversion-of-control.html |
| 2021-09-21 09:20:31 +0200 | <Guest372> | return |
| 2021-09-21 09:20:51 +0200 | acidjnk | (~acidjnk@p200300d0c703cb44319f4c33bc64626e.dip0.t-ipconnect.de) |
| 2021-09-21 09:21:02 +0200 | <c_wraith> | Codensity is a slightly less expressive monad that can be used in the same way: https://hackage.haskell.org/package/kan-extensions-5.2.3/docs/Control-Monad-Codensity.html#t:Coden… |
| 2021-09-21 09:24:02 +0200 | Guest7264 | (~Guest72@117.223.48.235) |
| 2021-09-21 09:24:14 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 2021-09-21 09:24:16 +0200 | <Axman6> | but if you use ContT, the file will remain open until you run runContT right? |
| 2021-09-21 09:24:33 +0200 | <Axman6> | so if you need timely file closure, ContT is not the right thing to do |
| 2021-09-21 09:24:35 +0200 | <awpr> | it'll be opened and closed inside the runContT |
| 2021-09-21 09:24:48 +0200 | <c_wraith> | I mean, withFile isn't the right thing to do if you need timely file closure either |
| 2021-09-21 09:25:04 +0200 | <Axman6> | it is if you want the file to be closed before returning the r |
| 2021-09-21 09:25:15 +0200 | <Axman6> | which is not what will happen with ContT |
| 2021-09-21 09:25:48 +0200 | <c_wraith> | ContT doesn't change any logic |
| 2021-09-21 09:25:59 +0200 | <c_wraith> | It just lets you escape nesting |
| 2021-09-21 09:26:10 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2021-09-21 09:26:17 +0200 | <c_wraith> | If you don't want nested logic, don't use it |
| 2021-09-21 09:26:39 +0200 | <Axman6> | Don't you end up with the continuation that is passed to withFile being the entire rest of the ContT computation? |
| 2021-09-21 09:27:01 +0200 | <c_wraith> | Just like you end up needing to pass the entire function that processes the Handle to withFile |
| 2021-09-21 09:27:07 +0200 | <c_wraith> | It's the same thing |
| 2021-09-21 09:27:29 +0200 | <awpr> | oh, you're picturing using ContT as the monad for the entirety of some big chunk of the program |
| 2021-09-21 09:27:51 +0200 | <awpr> | yeah, that's how you get "open everything and release it all on exit" |
| 2021-09-21 09:28:59 +0200 | <Axman6> | do { withFile "foo" RW (\h -> hPut h "Hello!"); putStrLn "File is now closed") } vs do { h <- ContT (withFile "foo" RW); liftIO (hPut "foo"); putStrLn "File is still open here" }? |
| 2021-09-21 09:29:20 +0200 | <Axman6> | missing a liftIO but you get it |
| 2021-09-21 09:29:24 +0200 | <awpr> | yes, that's why you shouldn't use ContT that way :) |
| 2021-09-21 09:30:00 +0200 | <awpr> | if that's gonna be the return type of a withFile-alike, it should be used in as-small-as-possible ContT blocks wrapped in runContT |
| 2021-09-21 09:30:18 +0200 | <c_wraith> | You only really want to use it on something like withFile if you need multiple handles open at the same time to do something. |
| 2021-09-21 09:30:28 +0200 | <awpr> | +1 exactly |
| 2021-09-21 09:30:35 +0200 | <c_wraith> | And you don't want to write syntactically nested functions for it |
| 2021-09-21 09:31:02 +0200 | rond_ | (~rond_@2a02:a31a:a23c:f480:2fd7:e087:5546:a438) |
| 2021-09-21 09:31:09 +0200 | <awpr> | can think of ContT/Codensity as the monad of nested resource scopes in this context |
| 2021-09-21 09:31:33 +0200 | <c_wraith> | I've used them that way for FFI code. |
| 2021-09-21 09:31:58 +0200 | <awpr> | yeah, pretty great for that. I've _tried_ to use IxContT too, but it got tedious |
| 2021-09-21 09:33:31 +0200 | <Axman6> | I wou;dn't mind reading more about that technique, got any good links? |
| 2021-09-21 09:33:40 +0200 | <ldlework> | you all are on another level |
| 2021-09-21 09:34:20 +0200 | <ldlework> | really glad I spent 15 years doing Python, real glad |
| 2021-09-21 09:34:35 +0200 | <Axman6> | Now you have 15 years of bad ideas to unlearn though ;) |
| 2021-09-21 09:34:44 +0200 | <ldlework> | Yeah there was an /s there |
| 2021-09-21 09:34:47 +0200 | <Guest372> | about withFile s result type IO r, its coming from Handle -> IO r or withFile itself? |
| 2021-09-21 09:35:02 +0200 | <Axman6> | it can only come from the function you pass to it |
| 2021-09-21 09:35:15 +0200 | <c_wraith> | eh, whatever. I spent like 12 years doing BASIC before learning other languages. Despite Dijkstra's remarks, the language wasn't actively harmful. |
| 2021-09-21 09:35:31 +0200 | <Axman6> | there is no other possible way to return an r unless it throws an exception or never returns |
| 2021-09-21 09:35:51 +0200 | <Guest372> | but withFile will get control after the functuin is done |
| 2021-09-21 09:35:57 +0200 | <Axman6> | yes |
| 2021-09-21 09:36:14 +0200 | <c_wraith> | But it stores the result of your function. Then it closes the file. Then it returns what it stored. |
| 2021-09-21 09:36:38 +0200 | <Guest372> | why withFile doesn't return anything else, can it? |
| 2021-09-21 09:36:48 +0200 | <Axman6> | withFile is basically: withFile path mode f = do {h <- openHandle mode path; r <- f h; closeHandle h; return r } |
| 2021-09-21 09:37:13 +0200 | <c_wraith> | with some error handling thrown in, but that would just make it noisy and harder to read. |
| 2021-09-21 09:37:17 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2021-09-21 09:37:31 +0200 | <Axman6> | (It's actual implementation is very different but that semantically what it does if f doesn't throw any exceptions) |
| 2021-09-21 09:37:48 +0200 | <Guest372> | can withFile return 0 or 1? |
| 2021-09-21 09:37:58 +0200 | <Axman6> | only if the function you pass it does |
| 2021-09-21 09:39:11 +0200 | <Guest372> | (Handle -> IO r) is a continuation, right? |
| 2021-09-21 09:39:29 +0200 | <Axman6> | yes |
| 2021-09-21 09:39:38 +0200 | <c_wraith> | well. not exactly. |
| 2021-09-21 09:39:39 +0200 | <Guest372> | and that closeHandle h; return r is contiuation too? |
| 2021-09-21 09:39:45 +0200 | <c_wraith> | it has the same type |
| 2021-09-21 09:39:49 +0200 | <c_wraith> | but it isn't a tail call |
| 2021-09-21 09:39:54 +0200 | <Axman6> | I wouldn't have said that, no |
| 2021-09-21 09:40:35 +0200 | <Axman6> | note that the return type of withFile is determined by the function, or continuation, that you pass it |
| 2021-09-21 09:40:37 +0200 | <Guest372> | that closeHandle and return is behind the contiuation |
| 2021-09-21 09:40:53 +0200 | <Axman6> | I think you're over complicating this - read the colde I wrote a bove |
| 2021-09-21 09:40:58 +0200 | <Axman6> | above* |
| 2021-09-21 09:41:36 +0200 | <c_wraith> | I think you're conflating something with the type of a continuation vs... a continuation. |
| 2021-09-21 09:41:58 +0200 | <Guest372> | confuse |
| 2021-09-21 09:42:36 +0200 | <ldlework> | Guest372: welcome to the club |
| 2021-09-21 09:42:42 +0200 | <ldlework> | we have drinks and snacks at the bar |
| 2021-09-21 09:43:07 +0200 | <c_wraith> | You've got a baseline assumption that calling a continuation is the last thing a function does. |
| 2021-09-21 09:43:26 +0200 | <c_wraith> | And that's fair - that's what a continuation *is* - where to go next. |
| 2021-09-21 09:43:54 +0200 | <c_wraith> | But you've mistaken withFile for being an example of using a continuation because it has the same type as stuff that does |
| 2021-09-21 09:44:09 +0200 | <c_wraith> | But it's different - it's more of a traditional callback |
| 2021-09-21 09:44:11 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
| 2021-09-21 09:45:00 +0200 | <Guest372> | but in that withFile code above, call f isn't the last thing to do, there are closeHandle |
| 2021-09-21 09:45:10 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 09:45:13 +0200 | <ldlework> | Guest372: that's their point |
| 2021-09-21 09:46:02 +0200 | <Cale> | I think it's fine to think of it as a continuation of sorts. After all, you can use the Cont/ContT monad to work with such withFoo-style functions and handle all the nesting for you. |
| 2021-09-21 09:46:55 +0200 | <c_wraith> | it's fine until your definition of "continuation" forbids what it does, and you get confused. |
| 2021-09-21 09:47:41 +0200 | <Guest372> | Handle -> IO r inside withFile is a cotinuation? |
| 2021-09-21 09:47:41 +0200 | <Cale> | It's not an unbounded continuation-until-the-end-of-time sort of continuation, but one which specifies what happens up until the file gets closed (or whatever) |
| 2021-09-21 09:49:32 +0200 | <Guest372> | more confused, withFile will call f to handle its Handle, and when f is done, control return to withFile, then withFile close Handle |
| 2021-09-21 09:49:55 +0200 | <ldlework> | you don't seem confused at all! |
| 2021-09-21 09:49:59 +0200 | <Guest372> | f is not the last thing withFile do |
| 2021-09-21 09:50:10 +0200 | <Guest372> | f is a continuation? |
| 2021-09-21 09:50:17 +0200 | <c_wraith> | if your definition of continuation includes "the last thing a function does", then no, it's not. |
| 2021-09-21 09:50:22 +0200 | <ldlework> | lol |
| 2021-09-21 09:50:34 +0200 | <c_wraith> | If you relax the definition as Cale suggested, then sure. |
| 2021-09-21 09:51:11 +0200 | <Guest372> | whats the right definiton? |
| 2021-09-21 09:51:26 +0200 | <Guest372> | that most people using |
| 2021-09-21 09:52:23 +0200 | <awpr> | the ContT monad evidently uses the relaxed version. in the context of "CPS", it's the stricter version. I'm not sure I'd call either one "right" or "wrong", they're just two very similar concepts |
| 2021-09-21 09:52:46 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 09:53:00 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 09:53:41 +0200 | <ldlework> | So when you use a function functor, you are basically transforming a function of `a -> z0` to `a -> z1` ? |
| 2021-09-21 09:54:23 +0200 | <Guest372> | so turn that (Handle -> IO r) -> IO r to ContT r IO Handle, who will close the handle? withFile itself or ContT? |
| 2021-09-21 09:54:35 +0200 | <ldlework> | Oh that makes sense because that's what function composition does too |
| 2021-09-21 09:55:12 +0200 | <ldlework> | x :: a -> b, y:: b -> c, then y . x :: a -> c |
| 2021-09-21 09:58:29 +0200 | <ldlework> | Hmm, I just got to the end of the section that concludes: `To put another way: The type constructor (->) a z is covariant in its second argument.` |
| 2021-09-21 09:58:36 +0200 | <ldlework> | But I still dont understand what is meant by that. |
| 2021-09-21 09:58:44 +0200 | Guest7264 | (~Guest72@117.223.48.235) (Quit: Client closed) |
| 2021-09-21 09:58:45 +0200 | <c_wraith> | all it means is that it maps "forwards" |
| 2021-09-21 09:59:07 +0200 | <c_wraith> | (a -> b) -> T a -> T b |
| 2021-09-21 09:59:26 +0200 | <c_wraith> | contravariant means the mapping goes backwards: (a -> b) -> T b -> T a |
| 2021-09-21 09:59:41 +0200 | <c_wraith> | covariant is much more common |
| 2021-09-21 09:59:54 +0200 | <ldlework> | how would the latter even work |
| 2021-09-21 10:00:09 +0200 | <ldlework> | if you have a -> b, you need an `a` on hand to pass |
| 2021-09-21 10:00:14 +0200 | <ldlework> | well a T a |
| 2021-09-21 10:00:21 +0200 | <c_wraith> | Not necessarily true! |
| 2021-09-21 10:00:22 +0200 | <ldlework> | but you got a T b instead |
| 2021-09-21 10:00:46 +0200 | <c_wraith> | newtype Predicate a = P (a -> Bool) |
| 2021-09-21 10:00:49 +0200 | <awpr> | `newtype Predicate a = Predicat |
| 2021-09-21 10:00:55 +0200 | <awpr> | ^ aborted |
| 2021-09-21 10:01:17 +0200 | <ldlework> | was that supposed to be clarifying? :P |
| 2021-09-21 10:01:22 +0200 | <c_wraith> | You don't have a value of type a in a Predicate a |
| 2021-09-21 10:01:35 +0200 | <c_wraith> | you have an empty spot that accepts an a |
| 2021-09-21 10:02:01 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 10:02:07 +0200 | <c_wraith> | So a function of type (a -> b) transforms something going into the empty spot. |
| 2021-09-21 10:02:43 +0200 | <ldlework> | I understand that a data type doesn't need to structurally compose every type in its type constructor |
| 2021-09-21 10:02:51 +0200 | <ldlework> | But I feel I'm no closer to understanding the backwards case |
| 2021-09-21 10:03:27 +0200 | <awpr> | maybe try implementing the forwards case for Predicate and see what goes wrong |
| 2021-09-21 10:04:19 +0200 | <ldlework> | what would I be implementing? |
| 2021-09-21 10:04:39 +0200 | <awpr> | `instance Functor Predicate` for example |
| 2021-09-21 10:04:41 +0200 | <ldlework> | just a function like Predicate a -> T Bool -> T a |
| 2021-09-21 10:04:50 +0200 | <ldlework> | oh so fmap |
| 2021-09-21 10:04:57 +0200 | benin036932301 | (~benin@183.82.205.89) |
| 2021-09-21 10:05:06 +0200 | <Cale> | Guest372: Of course it will still be withFile, but that will happen at the end after pretty much the rest of the action you're runContT'ing executes, and things start to unravel. Basically, when you write do v <- withFoo; ... in the ContT monad, it's like withFoo (\v -> ...) |
| 2021-09-21 10:05:55 +0200 | hendursa1 | (~weechat@user/hendursaga) |
| 2021-09-21 10:06:05 +0200 | phma | (~phma@host-67-44-208-198.hnremote.net) (Read error: Connection reset by peer) |
| 2021-09-21 10:06:47 +0200 | <Cale> | Stuff like sequence in the Cont monad can be really useful if you want to get hold of an entire list of resources all at once |
| 2021-09-21 10:06:54 +0200 | <Cale> | :t runCont . sequence . map cont |
| 2021-09-21 10:06:55 +0200 | <lambdabot> | [(a -> r) -> r] -> ([a] -> r) -> r |
| 2021-09-21 10:07:00 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 10:07:01 +0200 | phma | (~phma@host-67-44-208-5.hnremote.net) |
| 2021-09-21 10:07:43 +0200 | <Cale> | ^^ take a list of withFoo-style functions, and a function which will get a list of their results, ... and basically nest them in the obvious way |
| 2021-09-21 10:08:57 +0200 | hendursaga | (~weechat@user/hendursaga) (Ping timeout: 276 seconds) |
| 2021-09-21 10:09:15 +0200 | <Cale> | Of course, you could write this function by hand, but it'll be way harder to think about whether you got it right than this :) |
| 2021-09-21 10:09:17 +0200 | <Guest372> | you mean when runCotT is done, withFile close the file? |
| 2021-09-21 10:09:34 +0200 | <ldlework> | awpr: c_wraith: couldn't match type 'a' with 'b' in `instance Functor Pred where fmap f (P p) = P (f . p)` |
| 2021-09-21 10:10:16 +0200 | <Cale> | Guest372: Pretty much, once the action is done, all the with-style stuff you ran along the way will start to unravel in the same way as if you'd nested it all by hand. |
| 2021-09-21 10:10:34 +0200 | <ldlework> | I guess that's the problem you alluded to? |
| 2021-09-21 10:10:48 +0200 | <awpr> | my brain hurts trying to see how that error corresponds to that code; is it actually `p . f`? |
| 2021-09-21 10:10:55 +0200 | <Cale> | The Cont/ContT monad just takes care of the nesting for you, and makes it appear like it's flattened out |
| 2021-09-21 10:11:34 +0200 | <awpr> | oh, nvm, I can see where that error came from |
| 2021-09-21 10:11:42 +0200 | <Guest372> | Cale just like sugar syntax? nothing more? |
| 2021-09-21 10:11:44 +0200 | <awpr> | so, not exactly the error I was alluding to |
| 2021-09-21 10:11:55 +0200 | <ldlework> | awpr: http://logos.ldlework.com/caps/2021-09-21-08-11-52.png |
| 2021-09-21 10:12:13 +0200 | <Cale> | Guest372: Well, as I demonstrated there with sequence, it buys you a little more than syntax sugar, because you get to use all the stuff that works in any monad |
| 2021-09-21 10:12:26 +0200 | <ldlework> | awpr: where did i go wrong? |
| 2021-09-21 10:12:35 +0200 | nschoe | (~quassel@178.251.84.79) |
| 2021-09-21 10:12:50 +0200 | <awpr> | so you've got an `a` in the type that you want to end up being a `b`; the `a` is the input to the `p` function |
| 2021-09-21 10:12:56 +0200 | __monty__ | (~toonn@user/toonn) |
| 2021-09-21 10:13:28 +0200 | <awpr> | and you've got a function to apply, that you want to use to transform the `a` values, which are inputs to `p` |
| 2021-09-21 10:13:53 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 264 seconds) |
| 2021-09-21 10:15:50 +0200 | <ldlework> | awpr: so the inputs should go into ... `f`, which are then piped into `p`? |
| 2021-09-21 10:15:56 +0200 | <awpr> | yep |
| 2021-09-21 10:15:56 +0200 | <ldlework> | isn't that just function composition? |
| 2021-09-21 10:16:09 +0200 | <awpr> | also yes, it's just the other order of function composition |
| 2021-09-21 10:16:23 +0200 | <ldlework> | awpr: http://logos.ldlework.com/caps/2021-09-21-08-16-21.png |
| 2021-09-21 10:17:10 +0200 | <awpr> | yeah, there's what I was expecting to see: in `fmap`, the `f` function is _backwards_ from what it'd need to be to be able to transform the `a` type |
| 2021-09-21 10:17:25 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-09-21 10:17:46 +0200 | <awpr> | you have an `a -> b` and an `a -> Bool`, and they just don't fit together |
| 2021-09-21 10:17:50 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-09-21 10:17:51 +0200 | <ldlework> | awpr: oh, so this is why we need Profunctor and not just Functor? |
| 2021-09-21 10:18:09 +0200 | <awpr> | well, in this particular case, Contravariant instead of Functor |
| 2021-09-21 10:18:22 +0200 | <ldlework> | I see. |
| 2021-09-21 10:18:42 +0200 | <awpr> | now try `contramap :: (b -> a) -> Pred a -> Pred b`, with the same definition, and it should work |
| 2021-09-21 10:18:47 +0200 | <ldlework> | awpr: one day when you're not busy, want to collaborate on a draw.io diagram (or something) of the typeclass family tree? |
| 2021-09-21 10:19:01 +0200 | <ldlework> | i haven't been able to find a substantial one |
| 2021-09-21 10:19:12 +0200 | <awpr> | hmm, I thought there were a few of those scattered around |
| 2021-09-21 10:19:25 +0200 | <ldlework> | i found a couple, but they are only a handful of typeclasses |
| 2021-09-21 10:19:29 +0200 | <awpr> | https://wiki.haskell.org/Typeclassopedia |
| 2021-09-21 10:19:36 +0200 | <awpr> | that has a pretty substantial one |
| 2021-09-21 10:20:00 +0200 | <awpr> | hmm, no profunctor or contravariant, though |
| 2021-09-21 10:20:08 +0200 | <ldlework> | I was just gonna say that :P |
| 2021-09-21 10:20:30 +0200 | <ldlework> | awpr: would it be possible to generate this list from the haskell source code? |
| 2021-09-21 10:20:39 +0200 | <ldlework> | using some dumb grep/python or whatever |
| 2021-09-21 10:21:00 +0200 | <ldlework> | s/list/graph |
| 2021-09-21 10:21:14 +0200 | <awpr> | maybe, but there can be cases where something is sort of a superclass but doesn't actually say so in code |
| 2021-09-21 10:21:25 +0200 | <ldlework> | Oh rip |
| 2021-09-21 10:21:25 +0200 | <awpr> | like Applicative => Monad used to be that way a long time ago |
| 2021-09-21 10:21:30 +0200 | <ldlework> | Right |
| 2021-09-21 10:21:38 +0200 | <ldlework> | And monoid => Semigroup? |
| 2021-09-21 10:21:54 +0200 | <awpr> | yeah, in the other direction |
| 2021-09-21 10:21:56 +0200 | <ldlework> | awpr: maybe it would get 80% there |
| 2021-09-21 10:22:36 +0200 | <ldlework> | It'd also be kind of a map of what relations are left implicit today |
| 2021-09-21 10:22:51 +0200 | <awpr> | I'm also not sure how to represent the relationship between e.g. Functor, Contravariant, Bifunctor, Profunctor, Functor10, etc. visually. they're all very closely connected, but not by any superclass relationships |
| 2021-09-21 10:23:12 +0200 | <ldlework> | awpr: we can use different line types |
| 2021-09-21 10:23:30 +0200 | <ldlework> | awpr: are you saying there'd be no way to automatically associate Functor and Contravariant (for example)? |
| 2021-09-21 10:23:45 +0200 | <awpr> | yeah, not that I know of |
| 2021-09-21 10:23:55 +0200 | <ldlework> | aww, dreams dying over here |
| 2021-09-21 10:25:23 +0200 | <ldlework> | this idea of collaborating to make a full typeclass diagram has made me think of another idea, a realtime collaborative web-based PlantUML editor |
| 2021-09-21 10:25:35 +0200 | <ldlework> | man that'd be dope |
| 2021-09-21 10:26:26 +0200 | ubert | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2021-09-21 10:26:28 +0200 | michalz | (~michalz@185.246.204.33) |
| 2021-09-21 10:27:09 +0200 | hnOsmium0001 | (uid453710@id-453710.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-09-21 10:27:51 +0200 | <ldlework> | awpr: now i'm annoyed lol |
| 2021-09-21 10:28:25 +0200 | <merijn> | contravariant functors and functors are kinda opposites |
| 2021-09-21 10:28:42 +0200 | [exa] | feels category diagrams incoming |
| 2021-09-21 10:28:45 +0200 | <merijn> | So you could have a mirror in the middle to "opposite world" and do that :p |
| 2021-09-21 10:29:14 +0200 | <merijn> | ldlework: See also comonad (does coapplicative exist? Presumably, but I don't think I've seen it...) |
| 2021-09-21 10:29:17 +0200 | <awpr> | yeah, we'd have to have product world and parametric world too though |
| 2021-09-21 10:29:41 +0200 | <ldlework> | let's do it |
| 2021-09-21 10:30:12 +0200 | Guest372 | (~xxx@47.245.54.240) () |
| 2021-09-21 10:30:18 +0200 | <[exa]> | ldlework: uml kinda sucks for this stuff honestly, the major things are usually transformations and arrows, not objects |
| 2021-09-21 10:30:23 +0200 | benin036932301 | (~benin@183.82.205.89) (Ping timeout: 246 seconds) |
| 2021-09-21 10:30:45 +0200 | <awpr> | yeah I think that kind of sums up my lack of optimism |
| 2021-09-21 10:31:07 +0200 | <ldlework> | [exa]: It's just that PlanUML is convienent because of it's text-based format |
| 2021-09-21 10:31:22 +0200 | <ldlework> | rather than dragging and clicking, i'm pretty sure it'd be sufficient to express some relationships |
| 2021-09-21 10:31:27 +0200 | <[exa]> | ldlework: I can argue that ascii art is a better text based format :] |
| 2021-09-21 10:31:35 +0200 | <awpr> | it'd be possible to throw things into a planar graph, but the useful relationships wouldn't be very visible |
| 2021-09-21 10:31:49 +0200 | <[exa]> | ldlework: anyway there's a TeX package for drawing this already |
| 2021-09-21 10:32:01 +0200 | <awpr> | a giant category theory diagram would do the trick, but it'd also be rather cluttered |
| 2021-09-21 10:32:05 +0200 | <ldlework> | Yeah I definitely want to go setup TeX right now :P |
| 2021-09-21 10:32:15 +0200 | <ldlework> | awpr: that's why there's zoom |
| 2021-09-21 10:32:26 +0200 | <[exa]> | zoom doesn't work for brains |
| 2021-09-21 10:32:47 +0200 | <[exa]> | you either get the idea at one level, or it's cluttered |
| 2021-09-21 10:32:58 +0200 | ubert | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) |
| 2021-09-21 10:32:59 +0200 | <ldlework> | mindmaps are pretty successful |
| 2021-09-21 10:33:11 +0200 | <ldlework> | we're making really generalized claims about tools that are clearly helpful to many people |
| 2021-09-21 10:33:18 +0200 | <[exa]> | yep. :] |
| 2021-09-21 10:33:28 +0200 | <[exa]> | mindmaps are about not missing the relations, useful for sure |
| 2021-09-21 10:33:46 +0200 | <[exa]> | still you don't remember "the shape of the mindmap" as something to guide your math/programming intuition right? |
| 2021-09-21 10:33:59 +0200 | <ldlework> | if we had a big planar map of the typeclass relations with different arrow types, or whatever |
| 2021-09-21 10:34:02 +0200 | <awpr> | if it could actually all fit into a pannable/zoomable map that labels category theory stuff with Haskell names, that'd be really cool. will have to think about whether it can be made to work |
| 2021-09-21 10:34:12 +0200 | <ldlework> | it'd be clearly useful/valuable in getting a vista |
| 2021-09-21 10:34:21 +0200 | <[exa]> | ldlework: did you see the one for number hierarchy? |
| 2021-09-21 10:34:24 +0200 | <ldlework> | especially if they linked out to typeopedia resources, etc |
| 2021-09-21 10:34:54 +0200 | <[exa]> | actually some dynamic graph drawing could be really cool |
| 2021-09-21 10:35:04 +0200 | <awpr> | things get _really_ stratified though when you start trying to be honest about category theory concepts in Haskell, though |
| 2021-09-21 10:35:04 +0200 | <ldlework> | awpr: if you'd be willing to help with the formal knowledge, I wouldn't be against exploring some custom options using React Flow |
| 2021-09-21 10:35:19 +0200 | <ldlework> | I've built such things before |
| 2021-09-21 10:35:39 +0200 | <ldlework> | Maybe we could do layers, where you could have controls on the right to toggle things on and off, etc |
| 2021-09-21 10:36:05 +0200 | <awpr> | like a profunctor is a Hask-enriched functor from the product category OpHaskxHask to Hask, and then there are ProfunctorFunctors which treat those as objects of their own category |
| 2021-09-21 10:36:15 +0200 | <ldlework> | awpr: in the end, i also have built things with threejs so if we needed to go three dimensional, it's a possibility :P |
| 2021-09-21 10:37:32 +0200 | <awpr> | I do find myself trying to visually build this stuff up in my head all the time... could be really cool to have it all there in one place |
| 2021-09-21 10:37:42 +0200 | <ldlework> | it really would be |
| 2021-09-21 10:38:07 +0200 | benin036932301 | (~benin@183.82.205.89) |
| 2021-09-21 10:38:27 +0200 | <awpr> | need to let the idea braise for a while / find time to be able to work on it |
| 2021-09-21 10:38:45 +0200 | <ldlework> | awpr: with plantuml, we could embed the lawful functions inside the objects too |
| 2021-09-21 10:38:59 +0200 | <ldlework> | I'm gonna recreate the typopedia diagram in plantuml just as a salespitch |
| 2021-09-21 10:40:04 +0200 | <[exa]> | ldlework: actually a nice opportunity to learn some haskell webbing, FRP or miso :D |
| 2021-09-21 10:40:59 +0200 | <ldlework> | [exa]: if i was gonna build a custom explorer i'd love to go the haskell route, but with work, i'd just need to snap it out using the tech i'm really comfortable with |
| 2021-09-21 10:41:04 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2021-09-21 10:41:33 +0200 | <ldlework> | I'd love to learn Reflex |
| 2021-09-21 10:42:35 +0200 | <Cale> | ldlework: Nice! Let me know how it goes. |
| 2021-09-21 10:44:49 +0200 | <Cale> | (I'm working for Obsidian Systems, and while Reflex is much more Ryan's doing than mine, it's definitely inspired by the work we did together on earlier FRP systems.) |
| 2021-09-21 10:47:07 +0200 | <[exa]> | ldlework: it would be interesting to also have the instances around (they make the classes work, right?). I was always kinda wondering how (or if) to correctly draw stuff like `instance Monoid a => Monoid (r -> a)` in this scheme, which I'd find pretty useful |
| 2021-09-21 10:49:49 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-21 10:50:50 +0200 | xiongxin | (~quassel@119.123.103.94) (Ping timeout: 265 seconds) |
| 2021-09-21 10:50:54 +0200 | xiongxin_ | (~quassel@113.116.32.178) |
| 2021-09-21 10:54:41 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 264 seconds) |
| 2021-09-21 10:57:13 +0200 | <ldlework> | http://logos.ldlework.com/caps/2021-09-21-08-57-09.png |
| 2021-09-21 10:57:19 +0200 | <ldlework> | Cale: [exa] awpr |
| 2021-09-21 10:58:06 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 10:58:19 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 11:00:16 +0200 | <[exa]> | ldlework: perhaps there would be a github CI renderer for this so it can be shared reasonably |
| 2021-09-21 11:00:38 +0200 | xiongxin_ | (~quassel@113.116.32.178) (Ping timeout: 260 seconds) |
| 2021-09-21 11:00:39 +0200 | <awpr> | looks pretty good for the Hask->Hask subset of the world |
| 2021-09-21 11:00:57 +0200 | <ldlework> | there are a lot of options for styling, arrows, etc too |
| 2021-09-21 11:01:00 +0200 | <ldlework> | labels, and so on |
| 2021-09-21 11:01:35 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:283f:384b:ba74:f15c) (Remote host closed the connection) |
| 2021-09-21 11:01:57 +0200 | <awpr> | things do start to go downhill slightly with all the dotted lines meaning different things, though -- e.g. Monoid -> Category is oidification, Applicative -> Traversal is like "this uses that", Monoid -> Applicative is "this is the tensor product used in constructing that", etc. |
| 2021-09-21 11:03:27 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-21 11:03:27 +0200 | <merijn> | You do realise what happened the last time someone tried to make a single comprehensive document containing all math, yeah? :p |
| 2021-09-21 11:03:45 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-21 11:03:53 +0200 | <awpr> | somebody invented more math? |
| 2021-09-21 11:03:53 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-09-21 11:04:05 +0200 | <ldlework> | merijn: I just want a useful resource to give a vista for new haskell programmers that's all :P |
| 2021-09-21 11:04:07 +0200 | <ldlework> | (like me) |
| 2021-09-21 11:04:25 +0200 | <ldlework> | awpr: we can have specifically styled lines to mean specific things |
| 2021-09-21 11:06:07 +0200 | <awpr> | I've kinda gone off on a tangent into category theory land now. the UML-style diagram seems like it could be useful to a lot of people, but the thing I'm kinda excited about is a browseable category theory thing that points at some concrete thing and says e.g. "this is Functor" |
| 2021-09-21 11:06:52 +0200 | <awpr> | the planar graph version is much more tractable, at least |
| 2021-09-21 11:08:07 +0200 | awpr | just used the word "concrete" in a sentence about category theory... |
| 2021-09-21 11:08:09 +0200 | <sshine> | awpr, someone invented a meta-proof-system. this is only natural. I suppose Gödel was the first one to show that any cool enough concept devolves into meta-programming. |
| 2021-09-21 11:09:05 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Ping timeout: 264 seconds) |
| 2021-09-21 11:11:32 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-09-21 11:13:13 +0200 | <awpr> | for now though I've got to get some sleep -- I'll keep thinking about whether the whole world can fit into a diagram |
| 2021-09-21 11:14:47 +0200 | <ldlework> | http://logos.ldlework.com/caps/2021-09-21-09-14-43.png |
| 2021-09-21 11:16:35 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 11:18:42 +0200 | <ldlework> | I can't find anything on "Apply" |
| 2021-09-21 11:21:19 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-21 11:22:19 +0200 | <Taneb> | https://hackage.haskell.org/package/semigroupoids-5.3.2/docs/Data-Functor-Apply.html#g:2 ? |
| 2021-09-21 11:26:22 +0200 | <merijn> | ldlework: Because Apply is mostly lawless nonsense >.> |
| 2021-09-21 11:34:34 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-21 11:37:16 +0200 | <ldlework> | WIP https://i.imgur.com/oc17eZE.png |
| 2021-09-21 11:38:59 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 246 seconds) |
| 2021-09-21 11:39:28 +0200 | Brumaire | (~quassel@37.165.26.197) |
| 2021-09-21 11:41:32 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.2.1) |
| 2021-09-21 11:42:54 +0200 | bastelfreak | (~bastelfre@basteles-bastelknecht.bastelfreak.org) (Quit: WeeChat 3.2) |
| 2021-09-21 11:44:44 +0200 | jacks2 | (~bc8165b6@217.29.117.252) |
| 2021-09-21 11:45:03 +0200 | <ldlework> | [exa]: Cale thoughts? |
| 2021-09-21 11:45:32 +0200 | <jacks2> | hi. I want to put some haskell code in settings file that will be evaluated by haskell program. basically, I need to ship my program with ghci interpreter. what's the best way of achieving this? |
| 2021-09-21 11:46:11 +0200 | <ldlework> | jacks2: have you considered dhall instead? |
| 2021-09-21 11:46:17 +0200 | <jacks2> | (I don't care about security, this is a personal project used only by me) |
| 2021-09-21 11:46:19 +0200 | bastelfreak | (~bastelfre@basteles-bastelknecht.bastelfreak.org) |
| 2021-09-21 11:46:39 +0200 | <ldlework> | jacks2: there is https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html |
| 2021-09-21 11:46:54 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2021-09-21 11:47:13 +0200 | <jacks2> | ldlework, it looks interesting, but I already have a working settings file in a different format, I just need a way to interpret strings as haskell code |
| 2021-09-21 11:47:23 +0200 | <ldlework> | jacks2: look at the link I just sent :) |
| 2021-09-21 11:47:52 +0200 | <jacks2> | oh this is part of ghc now? nice |
| 2021-09-21 11:47:59 +0200 | <jacks2> | I recall using some third party library many years ago |
| 2021-09-21 11:48:37 +0200 | <ldlework> | jacks2: tell me you're making an Ansible alternative, but with Haskell |
| 2021-09-21 11:49:19 +0200 | <jacks2> | no :). just a quick and dirty program for my own use |
| 2021-09-21 11:54:41 +0200 | kayprish | (~kayprish@46.240.130.158) |
| 2021-09-21 11:54:49 +0200 | <[exa]> | ldlework: I'm doing something else now sorry :D looks good but I guess it's gonna get really cluttered when you start completing it |
| 2021-09-21 11:55:14 +0200 | <ldlework> | will just take massaging |
| 2021-09-21 11:59:14 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2021-09-21 12:00:06 +0200 | on^ | (~on@12.203.127.82) |
| 2021-09-21 12:00:56 +0200 | maroloccio | (~marolocci@93-142-92-177.adsl.net.t-com.hr) (Quit: WeeChat 3.0) |
| 2021-09-21 12:02:31 +0200 | <maerwald> | ldlework: you mean propellor? |
| 2021-09-21 12:02:46 +0200 | <maerwald> | (I don't recommend it) |
| 2021-09-21 12:03:28 +0200 | <maerwald> | @hackage propellor |
| 2021-09-21 12:03:29 +0200 | <lambdabot> | https://hackage.haskell.org/package/propellor |
| 2021-09-21 12:03:49 +0200 | Brumaire | (~quassel@37.165.26.197) (Ping timeout: 265 seconds) |
| 2021-09-21 12:03:57 +0200 | <ldlework> | maerwald: https://github.com/dhall-lang/dhall-haskell |
| 2021-09-21 12:04:20 +0200 | <maerwald> | ldlework: ? |
| 2021-09-21 12:04:22 +0200 | <Cale> | ldlework: Nice, what are you using to draw the stuff? |
| 2021-09-21 12:04:48 +0200 | <ldlework> | maerwald: I don't know what you meant by "you mean propeller?" |
| 2021-09-21 12:04:53 +0200 | <ldlework> | maerwald: oh ansible alternative |
| 2021-09-21 12:04:58 +0200 | <ldlework> | makes sense now :P |
| 2021-09-21 12:05:04 +0200 | <ldlework> | Cale: plantuml |
| 2021-09-21 12:05:59 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-21 12:06:34 +0200 | <dminuoso> | You're shipping 1GiB of a compiler just to be able to read a settings file? |
| 2021-09-21 12:06:35 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 12:06:37 +0200 | <dminuoso> | Mmm. |
| 2021-09-21 12:06:58 +0200 | <dminuoso> | Dhall would seem easier.. |
| 2021-09-21 12:07:08 +0200 | kayprish | (~kayprish@46.240.130.158) (Remote host closed the connection) |
| 2021-09-21 12:07:17 +0200 | <ldlework> | :D |
| 2021-09-21 12:11:53 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
| 2021-09-21 12:12:05 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 12:17:29 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-21 12:17:41 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 12:22:44 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
| 2021-09-21 12:23:17 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 12:25:03 +0200 | xiongxin | (~quassel@119.123.102.205) |
| 2021-09-21 12:30:05 +0200 | oxide | (~lambda@user/oxide) |
| 2021-09-21 12:33:41 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-21 12:34:48 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 12:34:49 +0200 | totbwf__ | (sid402332@id-402332.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-09-21 12:38:06 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2021-09-21 12:38:26 +0200 | bastelfreak | (~bastelfre@basteles-bastelknecht.bastelfreak.org) (Quit: WeeChat 3.3) |
| 2021-09-21 12:38:42 +0200 | bastelfreak | (~bastelfre@basteles-bastelknecht.bastelfreak.org) |
| 2021-09-21 12:39:10 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2021-09-21 12:40:17 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-21 12:40:27 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 12:50:29 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-21 12:52:04 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 12:53:11 +0200 | neo1 | (~neo3@cpe-292712.ip.primehome.com) (Ping timeout: 246 seconds) |
| 2021-09-21 12:54:39 +0200 | <ldlework> | Is Monoid a (logical) superclass of Foldable? |
| 2021-09-21 12:55:33 +0200 | <Las[m]> | No |
| 2021-09-21 12:55:45 +0200 | <dminuoso> | They have different kinds, in fact. |
| 2021-09-21 12:55:47 +0200 | <dminuoso> | % :k Foldable |
| 2021-09-21 12:55:47 +0200 | <yahb> | dminuoso: (* -> *) -> Constraint |
| 2021-09-21 12:55:47 +0200 | <Las[m]> | They don't have the same kind first of all |
| 2021-09-21 12:55:49 +0200 | <dminuoso> | % :k Monoid |
| 2021-09-21 12:55:49 +0200 | <yahb> | dminuoso: * -> Constraint |
| 2021-09-21 12:56:19 +0200 | <dminuoso> | Though there is a sort of relationship. |
| 2021-09-21 12:56:40 +0200 | <ldlework> | in https://wiki.haskell.org/wikiupload/d/df/Typeclassopedia-diagram.png what are the dashed lines indicating |
| 2021-09-21 12:56:45 +0200 | <dminuoso> | % :t toList |
| 2021-09-21 12:56:45 +0200 | <yahb> | dminuoso: Foldable t => t a -> [a] |
| 2021-09-21 12:56:52 +0200 | <ldlework> | is it that functions of the typeclass use the other typeclass? |
| 2021-09-21 12:57:00 +0200 | <dminuoso> | We can think this function as the spiritual embodiment of Foldable |
| 2021-09-21 12:57:09 +0200 | <dminuoso> | And with some squinting we can think of lists as free monoids. |
| 2021-09-21 12:57:18 +0200 | <dminuoso> | Is that perhaps the relationship you're after? |
| 2021-09-21 12:57:38 +0200 | <ldlework> | dminuoso: I was just observing that some of Foldable's functions take Monoids |
| 2021-09-21 12:57:44 +0200 | <dminuoso> | Yes, it's a good observation. |
| 2021-09-21 12:57:56 +0200 | <ldlework> | fold :: Monoid m => t m -> m |
| 2021-09-21 12:58:04 +0200 | <ldlework> | So I was thinking of including a relation in my graph for that |
| 2021-09-21 12:58:29 +0200 | <dminuoso> | There's no straight relationship like that. |
| 2021-09-21 12:58:51 +0200 | <ldlework> | straight relationship? |
| 2021-09-21 12:59:27 +0200 | <dminuoso> | The best I can see is what I outlined earlier, thinking of `toList` as the (conceptual) characteristic method of Foldable, and thinking of a list as the free monoid. |
| 2021-09-21 12:59:33 +0200 | <ldlework> | I wonder if I should include each typeclasses' kind in the graph |
| 2021-09-21 12:59:53 +0200 | <ldlework> | dminuoso: what do you mean by "free" in "free monoid" |
| 2021-09-21 13:00:10 +0200 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2021-09-21 13:00:22 +0200 | <dminuoso> | "free" as in "without any extra luggage" |
| 2021-09-21 13:00:32 +0200 | <dminuoso> | unrestricted/free |
| 2021-09-21 13:00:38 +0200 | <dminuoso> | It's a term originating from math |
| 2021-09-21 13:00:40 +0200 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) |
| 2021-09-21 13:00:58 +0200 | alx741 | (~alx741@186.178.109.159) |
| 2021-09-21 13:02:29 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-21 13:02:29 +0200 | <ldlework> | dminuoso: would extra luggage be in the Semigroup direction, or the opposite direction of some other hypothetical typeclass that's a subclass of Monoid |
| 2021-09-21 13:02:40 +0200 | <ldlework> | The latter right? |
| 2021-09-21 13:02:54 +0200 | <dminuoso> | If you really want to know the gory details we'd have to dive a bit into category theory. |
| 2021-09-21 13:03:06 +0200 | <dminuoso> | Let me try and think of a handwaving way to explain this |
| 2021-09-21 13:03:39 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 13:03:57 +0200 | <ldlework> | dminuoso: I have a category theory friend, and he can explain how a car works by simplifying it down and using metaphors, but he cannot explain category theory without using jargon / using metaphors ^_^ |
| 2021-09-21 13:04:00 +0200 | <dminuoso> | A `free something` is the bare essential `something` that satisfies its laws, but nothing extra. |
| 2021-09-21 13:04:34 +0200 | <dminuoso> | A handwaving, perhaps suggestive way, is to think of a list as representing the mere monoidal structure |
| 2021-09-21 13:04:54 +0200 | <ldlework> | dminuoso: so a Semigroup would be a `degenerate monoid`, a monoid would be a `free monoid` and something who's superclass was Monoid would be a `restricted monoid` ? |
| 2021-09-21 13:05:02 +0200 | <dminuoso> | No rather |
| 2021-09-21 13:05:13 +0200 | <dminuoso> | Take the monoid of natural numbers under addition |
| 2021-09-21 13:05:18 +0200 | <ldlework> | Right |
| 2021-09-21 13:05:36 +0200 | <ldlework> | Semigroup of natural numbers + 0 for identity |
| 2021-09-21 13:05:43 +0200 | <dminuoso> | The monoid encompasses not just the operation (+) and its identity (0), but also the entirety of all elements. |
| 2021-09-21 13:05:55 +0200 | <ldlework> | the "domain" |
| 2021-09-21 13:06:01 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-21 13:06:07 +0200 | <dminuoso> | In category theory there's a lot of structure simply because we cant just ignore those numbers. |
| 2021-09-21 13:06:28 +0200 | jespada | (~jespada@2803:9800:9842:7a62:edd5:5e74:3ec2:1b19) |
| 2021-09-21 13:06:55 +0200 | <dminuoso> | So we have these constructions in category theory that allow us to "forget structure", so if we forget as much about this monoid as possible, while still satisfying the monoidal laws |
| 2021-09-21 13:07:25 +0200 | <dminuoso> | Sorry no that is wrong |
| 2021-09-21 13:07:27 +0200 | <dminuoso> | So |
| 2021-09-21 13:07:47 +0200 | <dminuoso> | ldlework: imagine a transformation from the naturals under addition to just the set of naturals. |
| 2021-09-21 13:08:00 +0200 | <dminuoso> | ldlework: Notice how such a transformation would essentially "forget" about all the monoidal structure? |
| 2021-09-21 13:08:13 +0200 | <ldlework> | dminuoso: It's like how a Monoid is a "restricted semigroup" since it is the "Semigroup with extra baggage" (identity), no? |
| 2021-09-21 13:08:32 +0200 | <dminuoso> | Yes, absolutely. |
| 2021-09-21 13:08:42 +0200 | <dminuoso> | But for this purpose, we intend to forget the entirety of the monoidal structure |
| 2021-09-21 13:08:44 +0200 | <dminuoso> | not just the identity |
| 2021-09-21 13:08:59 +0200 | <ldlework> | so the semigroup bits too |
| 2021-09-21 13:09:02 +0200 | <dminuoso> | Yes. |
| 2021-09-21 13:09:05 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-21 13:09:08 +0200 | <dminuoso> | Everything but the carrier set |
| 2021-09-21 13:09:11 +0200 | <ldlework> | why are we forgetting structure? I lost the thread. |
| 2021-09-21 13:09:18 +0200 | <dminuoso> | Dont worry about the details of why we do this. |
| 2021-09-21 13:09:24 +0200 | <ldlework> | XD |
| 2021-09-21 13:09:40 +0200 | <dminuoso> | We can make a construction, called a functor, that does this with any monoid |
| 2021-09-21 13:09:42 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 13:09:54 +0200 | <dminuoso> | So given a particular monoid, it just strips away the monoidal structure and gives you back the carrier set |
| 2021-09-21 13:10:11 +0200 | <ldlework> | well if you fmap'd id into the monoid |
| 2021-09-21 13:10:13 +0200 | <ldlework> | right |
| 2021-09-21 13:10:22 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Ping timeout: 260 seconds) |
| 2021-09-21 13:10:41 +0200 | <dminuoso> | Note that the "functor" is a different functor from our Haskell thing. A functor is just a way to transform one category into another. In our case, the category of monoids to the category of sets. |
| 2021-09-21 13:10:44 +0200 | <ldlework> | that would extract whatever is inside the structure |
| 2021-09-21 13:10:52 +0200 | <ldlework> | mm |
| 2021-09-21 13:10:57 +0200 | <dminuoso> | And we can also construct another functor in the other direction |
| 2021-09-21 13:11:08 +0200 | <dminuoso> | That is intrinsically related |
| 2021-09-21 13:11:17 +0200 | <dminuoso> | To the former functor (called the forgetful functor) |
| 2021-09-21 13:11:18 +0200 | <ldlework> | Now you have a Groupoid right |
| 2021-09-21 13:11:25 +0200 | <ldlework> | Since each morphism is an isomorphism |
| 2021-09-21 13:11:26 +0200 | <dminuoso> | Well the question is what does that functor even do |
| 2021-09-21 13:11:31 +0200 | <dminuoso> | So what we do is this: |
| 2021-09-21 13:11:42 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 13:11:57 +0200 | <dminuoso> | That functor maps a given set to the monoid [a], under which the unit is [] and the binary operation is ++ |
| 2021-09-21 13:12:00 +0200 | <dminuoso> | It can map *every* set this way |
| 2021-09-21 13:12:17 +0200 | <dminuoso> | It turns out that these two functors have a deep relationship |
| 2021-09-21 13:12:45 +0200 | <ldlework> | you're basically just saying |
| 2021-09-21 13:12:49 +0200 | <ldlework> | you can put things into a list |
| 2021-09-21 13:12:51 +0200 | <dminuoso> | The former is called a forgetful functor (forgetting monoidal structure), the latter is called a free functor (adding the *bare* monoidal structure back, with no extra baggage) |
| 2021-09-21 13:12:55 +0200 | <ldlework> | and we can do list concatenation |
| 2021-09-21 13:13:08 +0200 | <dminuoso> | We still have monoidal shape in list concatenation |
| 2021-09-21 13:13:12 +0200 | <dminuoso> | but no meaning of that |
| 2021-09-21 13:13:59 +0200 | <ldlework> | OK, so you're outlining that with regards to structure, we have a way of taking a set and putting it into structure or taking it out of structure |
| 2021-09-21 13:14:27 +0200 | <ldlework> | where a set is some domain of values of a given type, like natural numbers |
| 2021-09-21 13:14:31 +0200 | <dminuoso> | Well, we have a way of forgetting concrete monoidal structure back to a set, and a way of adding *bare/essential* monoidal structure to a set. |
| 2021-09-21 13:14:39 +0200 | <dminuoso> | Sure, it could be any |
| 2021-09-21 13:15:05 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-21 13:15:25 +0200 | <ldlework> | by emphasizing bare essential structure, you just mean, we're just putting the values back into the list (monoid), but no additional structure |
| 2021-09-21 13:15:33 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 13:15:34 +0200 | <dminuoso> | This relationship between "free" and "forgetful" can be observed in Haskell, even. |
| 2021-09-21 13:16:10 +0200 | <dminuoso> | If we call the forgetful functor `U` that strips away the monoidal structure, and `F` that free functor, we express that relationship as: |
| 2021-09-21 13:16:19 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 265 seconds) |
| 2021-09-21 13:16:23 +0200 | <dminuoso> | `F a -> b` is isomorphic to `a -> U b` |
| 2021-09-21 13:17:15 +0200 | <dminuoso> | Now, again ignoring gory details: |
| 2021-09-21 13:17:41 +0200 | Everything | (~Everythin@37.115.210.35) |
| 2021-09-21 13:17:51 +0200 | <dminuoso> | This eventually turns into Haskell by showing that `[a] -> b` being expressible by a function `a -> b` |
| 2021-09-21 13:17:54 +0200 | <dminuoso> | % :t foldMap |
| 2021-09-21 13:17:54 +0200 | <yahb> | dminuoso: (Foldable t, Monoid m) => (a -> m) -> t a -> m |
| 2021-09-21 13:18:05 +0200 | <dminuoso> | If you set `t ~ []` |
| 2021-09-21 13:18:18 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-09-21 13:18:35 +0200 | wei2912 | (~wei2912@112.199.250.21) (Quit: Lost terminal) |
| 2021-09-21 13:18:57 +0200 | Brumaire | (~quassel@37.165.2.61) |
| 2021-09-21 13:19:23 +0200 | <Cajun> | so if you composed those functions ( `F a -> b` and `a -> U b` ) and assumed `a ~ b` you could get the "bare monoidal structure" from the forgetful functor? |
| 2021-09-21 13:19:42 +0200 | <dminuoso> | Those are not regular functions. |
| 2021-09-21 13:20:11 +0200 | <dminuoso> | Perhaps this was a bit misleading |
| 2021-09-21 13:20:30 +0200 | <Cajun> | ah category theory functors where its just some type to another, not a function? |
| 2021-09-21 13:20:50 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 246 seconds) |
| 2021-09-21 13:25:16 +0200 | <dminuoso> | The thing is, `F` is implicitly there in Haskell |
| 2021-09-21 13:25:54 +0200 | <dminuoso> | So we could roughly do this: |
| 2021-09-21 13:25:59 +0200 | Brumaire | (~quassel@37.165.2.61) (Ping timeout: 265 seconds) |
| 2021-09-21 13:26:36 +0200 | <dminuoso> | % newtype Mon a = Mon [a]; instance Semigroup (Mon a) where Mon a <> Mon b = Mon (a ++ b); instance Monoid (Mon a) where mempty = Mon []; |
| 2021-09-21 13:26:36 +0200 | <yahb> | dminuoso: ; <interactive>:53:90: error: parse error on input `instance' |
| 2021-09-21 13:26:45 +0200 | <dminuoso> | % newtype Mon a = Mon [a] |
| 2021-09-21 13:26:45 +0200 | <yahb> | dminuoso: |
| 2021-09-21 13:26:49 +0200 | <dminuoso> | % nstance Semigroup (Mon a) where Mon a <> Mon b = Mon (a ++ b) |
| 2021-09-21 13:26:50 +0200 | <yahb> | dminuoso: ; <interactive>:55:27: error: parse error on input `where' |
| 2021-09-21 13:26:54 +0200 | <dminuoso> | % instance Semigroup (Mon a) where Mon a <> Mon b = Mon (a ++ b) |
| 2021-09-21 13:26:54 +0200 | <yahb> | dminuoso: |
| 2021-09-21 13:27:00 +0200 | <dminuoso> | % instance Monoid (Mon a) where mempty = Mon []; |
| 2021-09-21 13:27:00 +0200 | <yahb> | dminuoso: |
| 2021-09-21 13:27:30 +0200 | <dminuoso> | Mmm not quite |
| 2021-09-21 13:29:29 +0200 | <dminuoso> | ldlework: Anyway, at the end the key observation is: You can simply take a list of anything and make a minimal monoid with that. It adds monoidal structure, and nothing else. |
| 2021-09-21 13:29:54 +0200 | <dminuoso> | We dont even specify what `a ++ b` even means |
| 2021-09-21 13:32:37 +0200 | <hpc> | "We dont even specify what `a ++ b` even means" - leading with this would help a lot with future explanations |
| 2021-09-21 13:34:03 +0200 | cheater | (~Username@user/cheater) |
| 2021-09-21 13:36:07 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-09-21 13:38:32 +0200 | <carbolymer> | are async exceptions masked in "last" computation in `Control.Exception.bracket` ? |
| 2021-09-21 13:40:38 +0200 | <dminuoso> | carbolymer: Look at the implementation |
| 2021-09-21 13:41:40 +0200 | <carbolymer> | dminuoso: I'm looking and I feel a bit sick today and I'm not sure if it is: |
| 2021-09-21 13:41:40 +0200 | <carbolymer> | >restore ((thing a) `onException` after a) |
| 2021-09-21 13:41:40 +0200 | <carbolymer> | or |
| 2021-09-21 13:41:40 +0200 | <carbolymer> | >(restore (thing a)) `onException` after a |
| 2021-09-21 13:42:10 +0200 | <dminuoso> | https://hackage.haskell.org/package/base-4.15.0.0/docs/src/Control-Exception-Base.html#bracket |
| 2021-09-21 13:42:15 +0200 | <dminuoso> | r <- restore (thing a) `onException` after a |
| 2021-09-21 13:42:28 +0200 | <carbolymer> | what's the priority of operations? |
| 2021-09-21 13:42:48 +0200 | <carbolymer> | restore then onException? |
| 2021-09-21 13:43:05 +0200 | <dminuoso> | Not sure what you mean by priority |
| 2021-09-21 13:43:28 +0200 | <carbolymer> | which function is invoked last |
| 2021-09-21 13:43:47 +0200 | <dminuoso> | Why is the "order" relevant here? |
| 2021-09-21 13:43:57 +0200 | <hpc> | you mean fixity? |
| 2021-09-21 13:44:00 +0200 | <carbolymer> | yes |
| 2021-09-21 13:44:16 +0200 | <carbolymer> | dminuoso: because it answers the question if exceptions are masked in `after` |
| 2021-09-21 13:44:27 +0200 | <dminuoso> | Ah you're looking for how this is parsed. |
| 2021-09-21 13:44:29 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-09-21 13:44:39 +0200 | <dminuoso> | (restore (thing a)) `onException` after a |
| 2021-09-21 13:44:40 +0200 | <hpc> | prefix binds tighter than infix, so f x `op` g y is always (f x) `op` (g y) |
| 2021-09-21 13:44:45 +0200 | <carbolymer> | dminuoso: thank you |
| 2021-09-21 13:44:52 +0200 | <carbolymer> | hpc: thx |
| 2021-09-21 13:44:57 +0200 | <carbolymer> | coffee does not work today |
| 2021-09-21 13:45:01 +0200 | <shapr> | not YET |
| 2021-09-21 13:45:08 +0200 | shapr | drinks much more coffee |
| 2021-09-21 13:45:24 +0200 | <shapr> | violence is like coffee |
| 2021-09-21 13:45:31 +0200 | <shapr> | neither of them type check |
| 2021-09-21 13:45:38 +0200 | <hpc> | english breakfast tea is the superior wakeup juice :D |
| 2021-09-21 13:46:06 +0200 | <shapr> | I choose four cups of death wish cold brew. |
| 2021-09-21 13:46:23 +0200 | <dminuoso> | carbolymer: Note, that `restore` does not unmask exceptions, it just restores the previous exception mask before `mask` |
| 2021-09-21 13:46:31 +0200 | <dminuoso> | Just adding that side note, in case you're using `bracket` in strange places |
| 2021-09-21 13:47:21 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 276 seconds) |
| 2021-09-21 13:48:44 +0200 | <ldlework> | check this out https://i.imgur.com/HkcUQo3.png |
| 2021-09-21 13:48:50 +0200 | <carbolymer> | dminuoso: my team is balls deep in a strange issue, "/dev/random: hClose: does not exist (No such file or directory)" - comes from warp-tls, and it freezes processing threads (some resource contention?), and we have no idea why, also we're using ancient linux kernel 3.10 |
| 2021-09-21 13:49:11 +0200 | <carbolymer> | dminuoso: also profiling makes this bug irreproducible... |
| 2021-09-21 13:49:26 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2021-09-21 13:49:28 +0200 | <carbolymer> | dminuoso: so yeah, we're probably onto some masking weirdness |
| 2021-09-21 13:50:01 +0200 | __monty__ | (~toonn@user/toonn) (Quit: Kernel woes : s) |
| 2021-09-21 13:50:10 +0200 | <carbolymer> | ldlework: plantuml? |
| 2021-09-21 13:51:03 +0200 | <Cajun> | Idlework: seeing UML diagrams for haskell is weeeeird, ive only seen those for lenses! really cool though, it would be interesting to have a really big one of these automatically generated for a given project |
| 2021-09-21 13:51:40 +0200 | <ldlework> | carbolymer: yep |
| 2021-09-21 13:51:50 +0200 | <carbolymer> | ldlework: written by hand or generated? |
| 2021-09-21 13:52:00 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-09-21 13:52:06 +0200 | <ldlework> | carbolymer: written by hand because many typeclasses don't have the proper relationships in code |
| 2021-09-21 13:52:44 +0200 | <ldlework> | awpr is going to help flesh it out, I'm just working out the plantuml conventions |
| 2021-09-21 13:52:49 +0200 | <ldlework> | i mean, anyone can help |
| 2021-09-21 13:52:59 +0200 | <Cajun> | although some parts are inconsistent with the parenthesis and tuples. Foldable as the tuple as `(,) a` and Monad as `((,) a)` |
| 2021-09-21 13:53:04 +0200 | <ldlework> | I just fixed that |
| 2021-09-21 13:53:08 +0200 | <Cajun> | :) |
| 2021-09-21 13:53:19 +0200 | <ldlework> | https://i.imgur.com/eplRSKd.png |
| 2021-09-21 13:53:48 +0200 | viluon | (uid453725@id-453725.helmsley.irccloud.com) |
| 2021-09-21 13:53:54 +0200 | <Cajun> | far right of Functor has a weird > on it |
| 2021-09-21 13:54:50 +0200 | <ldlework> | nice |
| 2021-09-21 13:55:27 +0200 | <ldlework> | https://i.imgur.com/Ce1zOGK.png |
| 2021-09-21 13:55:58 +0200 | <ldlework> | oop missing a comma, guh |
| 2021-09-21 13:56:18 +0200 | <ldlework> | Anyway, I eventually want to see how Reader and other typeclasses fit in here |
| 2021-09-21 13:58:26 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 13:58:39 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 14:00:47 +0200 | jonathanx | (~jonathan@dyn-8-sc.cdg.chalmers.se) (Remote host closed the connection) |
| 2021-09-21 14:01:03 +0200 | jonathanx | (~jonathan@dyn-8-sc.cdg.chalmers.se) |
| 2021-09-21 14:06:31 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-21 14:10:07 +0200 | <ldlework> | If anyone wants to help add more typeclasses: https://github.com/dustinlacewell/haskell-typeclass-atlas |
| 2021-09-21 14:10:50 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-09-21 14:11:27 +0200 | <ldlework> | Cajun, [exa], Cale ^ |
| 2021-09-21 14:19:45 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-09-21 14:20:49 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2021-09-21 14:21:17 +0200 | dminuoso | is absolutely unsure what the relationship between Foldable and Ord is supposed to be |
| 2021-09-21 14:22:41 +0200 | <ldlework> | dminuoso: One of Foldable's methods depends on Ord |
| 2021-09-21 14:22:44 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-09-21 14:22:48 +0200 | <dminuoso> | Ermm.. |
| 2021-09-21 14:22:49 +0200 | <ldlework> | maximum/minimum |
| 2021-09-21 14:23:06 +0200 | <ldlework> | I'm new to haskell/category theory, so feel free to just chime in |
| 2021-09-21 14:23:08 +0200 | <dminuoso> | So?> |
| 2021-09-21 14:23:23 +0200 | <ldlework> | dminuoso: it's just meant to demonstrate such a relation |
| 2021-09-21 14:23:25 +0200 | <dminuoso> | That doesnt give any relationship between Foldable and Ord, really |
| 2021-09-21 14:23:31 +0200 | <dminuoso> | Any meaningful one, anyway |
| 2021-09-21 14:24:03 +0200 | <dminuoso> | But Im not sure what this diagram is trying to convey or help with |
| 2021-09-21 14:24:05 +0200 | <ldlework> | Like in another case you can easily see that you can use Foldable on Monoid objects |
| 2021-09-21 14:24:33 +0200 | <ldlework> | dminuoso: that's fine, others have expressed it could be useful, and personally I'm just looking for a nice reference |
| 2021-09-21 14:24:41 +0200 | <dminuoso> | What does "use Foldable on Monoid objects" even mean? |
| 2021-09-21 14:25:06 +0200 | <ldlework> | If you have a Monoid you can call `fold` on it |
| 2021-09-21 14:25:13 +0200 | <dminuoso> | No, you cant. |
| 2021-09-21 14:25:22 +0200 | <dminuoso> | % :t fold |
| 2021-09-21 14:25:22 +0200 | shriekingnoise | (~shrieking@186.137.144.80) |
| 2021-09-21 14:25:22 +0200 | <yahb> | dminuoso: (Foldable t, Monoid m) => t m -> m |
| 2021-09-21 14:25:31 +0200 | <ldlework> | Well rather, if you have a Foldable holding a Monad |
| 2021-09-21 14:25:38 +0200 | <ldlework> | Monoid* |
| 2021-09-21 14:25:41 +0200 | <dminuoso> | `t m` is not "a monoid" |
| 2021-09-21 14:25:53 +0200 | <dminuoso> | It's rather the foldable of a monoid can be mappended together. |
| 2021-09-21 14:25:54 +0200 | <ldlework> | it's a foldable structuring a monoid |
| 2021-09-21 14:25:57 +0200 | <dminuoso> | Sure. |
| 2021-09-21 14:26:05 +0200 | <ldlework> | spoke too soon :) |
| 2021-09-21 14:26:33 +0200 | <dminuoso> | Like I said, that relationship seems overly arbitrary |
| 2021-09-21 14:26:49 +0200 | <dminuoso> | As Monoid is not part of Foldable's description |
| 2021-09-21 14:26:56 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2021-09-21 14:27:00 +0200 | <ldlework> | Sure, that's a different arrow :P |
| 2021-09-21 14:27:05 +0200 | MQ-17J | (~MQ-17J@8.21.10.6) |
| 2021-09-21 14:27:09 +0200 | <dminuoso> | It's rather that `an arbitrary Monoid` is used in some methods. |
| 2021-09-21 14:27:24 +0200 | <ldlework> | Foldable has a relation with Monoid that it doesn't have with, say, Applicative |
| 2021-09-21 14:27:29 +0200 | <ldlework> | dminuoso: yes |
| 2021-09-21 14:27:41 +0200 | benin036932301 | (~benin@183.82.205.89) (Ping timeout: 264 seconds) |
| 2021-09-21 14:28:35 +0200 | <dminuoso> | Thing is, it's not really part of Foldable's identity |
| 2021-09-21 14:28:45 +0200 | <ldlework> | dminuoso: for context, awpr mentioned that there are some other relationships between typeclasses he wants to show, but as an ignorant neophyte, I don't know what they are - so in trying to accomplish my side of the goal of establishing some plantuml conventions, I just picked this arbitrary thing to test out alternative arrow styles on |
| 2021-09-21 14:28:48 +0200 | <dminuoso> | Foldable could be stripped to just `foldr` or `foldl`, or maybe `toListOf` |
| 2021-09-21 14:29:01 +0200 | <dminuoso> | So if you look at the *bare* minimum of a class, that's when you begin to realize its characteristics |
| 2021-09-21 14:29:16 +0200 | <ldlework> | dminuoso: I tried to think of a good place / good way to show the "minimal" functions but didn't think of anything good yet |
| 2021-09-21 14:29:28 +0200 | <dminuoso> | ldlework: you could perhaps make them bold? |
| 2021-09-21 14:29:31 +0200 | <dminuoso> | If that works |
| 2021-09-21 14:29:45 +0200 | <ldlework> | Yeah, I tried that, but it weakens the bolding in the title |
| 2021-09-21 14:29:56 +0200 | <ldlework> | I could make the titles a bigger fontsize |
| 2021-09-21 14:30:09 +0200 | <ldlework> | i wonder how underline looks |
| 2021-09-21 14:30:20 +0200 | <dminuoso> | ldlework: Anyway. The thing is, the relationship to Monoid is sort of accidental - in the sense that there's a bunch of people that frequently use Monoid to fold something together. |
| 2021-09-21 14:30:34 +0200 | <dminuoso> | but Foldable without `fold` and `foldMap` would be just as legit |
| 2021-09-21 14:30:41 +0200 | <ldlework> | dminuoso: sure, we're not trying to show the minimal possible amount of information |
| 2021-09-21 14:31:00 +0200 | <ldlework> | just trying to demonstrate some useful information among the major typeclasses |
| 2021-09-21 14:31:02 +0200 | <ldlework> | btw |
| 2021-09-21 14:31:04 +0200 | <dminuoso> | Well, what if there was a *function* using both Foldable and Comonad. Would that mean there had to be an arrow too? |
| 2021-09-21 14:31:06 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 14:31:12 +0200 | <ldlework> | if you have any recommendations for other typeclasses you'd like to see on an atlas like this |
| 2021-09-21 14:31:20 +0200 | <ldlework> | i'd be very happy to take those |
| 2021-09-21 14:31:34 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-09-21 14:31:37 +0200 | <dminuoso> | ldlework: The key thing is, fold/foldMap being actual methods is rather a mechanism allowing for people to provide type specialized optimized versions. |
| 2021-09-21 14:31:48 +0200 | <dminuoso> | But its in no way some demonstration of a relationship |
| 2021-09-21 14:31:55 +0200 | <dminuoso> | Imagine if `fold` and `foldMap` were just top level functions |
| 2021-09-21 14:32:00 +0200 | <dminuoso> | Would you still draw that arrow? |
| 2021-09-21 14:32:05 +0200 | <ldlework> | dminuoso: it's just showing "there are some functions on this type, you can use with that type" |
| 2021-09-21 14:32:07 +0200 | <ldlework> | nothing more |
| 2021-09-21 14:32:17 +0200 | <ldlework> | so you can look at a glance, without inspecting all the functions first |
| 2021-09-21 14:32:27 +0200 | <dminuoso> | Sure. Would you draw the arrows if `fold/foldMap` were regular functions? |
| 2021-09-21 14:32:37 +0200 | <ldlework> | maybe? |
| 2021-09-21 14:32:47 +0200 | <ldlework> | it's not meant to reflect the platonic definition of the thing |
| 2021-09-21 14:32:51 +0200 | <dminuoso> | So do you intend to scrape the entirety of hackage to build that model? |
| 2021-09-21 14:33:02 +0200 | <ldlework> | no, as it says "subset" |
| 2021-09-21 14:33:23 +0200 | pbrisbin | (~patrick@pool-173-49-147-250.phlapa.fios.verizon.net) |
| 2021-09-21 14:33:46 +0200 | <ldlework> | a difficulty with communicating the minimal function set, is that some of them are defined as OR operators |
| 2021-09-21 14:33:59 +0200 | <ldlework> | like for Eq, {-# MINIMAL (==) | (/=) #-} |
| 2021-09-21 14:35:57 +0200 | <ldlework> | Could just have a section above the example instances I guess |
| 2021-09-21 14:36:05 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 264 seconds) |
| 2021-09-21 14:37:11 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-09-21 14:37:40 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 14:37:43 +0200 | slowButPresent | (~slowButPr@user/slowbutpresent) |
| 2021-09-21 14:46:27 +0200 | ub | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) |
| 2021-09-21 14:47:31 +0200 | doyougnu | (~user@c-73-25-202-122.hsd1.or.comcast.net) |
| 2021-09-21 14:49:23 +0200 | <ldlework> | Added the required functions https://raw.githubusercontent.com/dustinlacewell/haskell-typeclass-atlas/master/atlas.png |
| 2021-09-21 14:50:03 +0200 | wonko | (~wjc@62.115.229.50) |
| 2021-09-21 14:51:05 +0200 | ub | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) (Ping timeout: 264 seconds) |
| 2021-09-21 14:52:15 +0200 | jonathanx | (~jonathan@dyn-8-sc.cdg.chalmers.se) (Remote host closed the connection) |
| 2021-09-21 14:52:32 +0200 | jonathanx | (~jonathan@dyn-8-sc.cdg.chalmers.se) |
| 2021-09-21 14:53:03 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-09-21 14:53:46 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 14:53:59 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 14:56:47 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-09-21 15:04:06 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 15:04:22 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 15:04:44 +0200 | MQ-17J | (~MQ-17J@8.21.10.6) (Ping timeout: 252 seconds) |
| 2021-09-21 15:04:55 +0200 | <DigitalKiwi> | ldlework: are you using haskell out of anger or joy (glad to see you here anyway) |
| 2021-09-21 15:05:03 +0200 | MQ-17J | (~MQ-17J@8.21.10.6) |
| 2021-09-21 15:05:09 +0200 | <ldlework> | joy |
| 2021-09-21 15:05:16 +0200 | <ldlework> | i'm pretty confused overall, but i like MLs |
| 2021-09-21 15:05:23 +0200 | <DigitalKiwi> | \o/ |
| 2021-09-21 15:06:07 +0200 | <ldlework> | it's going to take me a really long to meaningfully absorb the principled mathematical stuff behind the typeclasses, but i am working at it |
| 2021-09-21 15:07:13 +0200 | <ldlework> | long time* |
| 2021-09-21 15:07:39 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-21 15:07:41 +0200 | <DigitalKiwi> | have you https://github.com/hmemcpy/milewski-ctfp-pdf |
| 2021-09-21 15:08:04 +0200 | <ldlework> | no, still working through HFFP |
| 2021-09-21 15:08:58 +0200 | spruit11 | (~quassel@2a02:a467:ccd6:1:40b2:87e8:dd1:e5c1) |
| 2021-09-21 15:09:21 +0200 | <ldlework> | thanks for the link though |
| 2021-09-21 15:09:27 +0200 | <DigitalKiwi> | do you mean HPFP or a different one i don't know |
| 2021-09-21 15:09:35 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-21 15:09:48 +0200 | <DigitalKiwi> | oh a different one |
| 2021-09-21 15:10:11 +0200 | <DigitalKiwi> | or nvrm i have no idea lol |
| 2021-09-21 15:10:47 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 15:10:47 +0200 | <ldlework> | DigitalKiwi: Haskell From First Principles |
| 2021-09-21 15:10:51 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-21 15:11:47 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Ping timeout: 246 seconds) |
| 2021-09-21 15:12:08 +0200 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-09-21 15:14:18 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 15:14:29 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 15:14:37 +0200 | <DigitalKiwi> | lol i think we're talking about the same book but i read it as Haskell Programming from First Principles |
| 2021-09-21 15:14:42 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 15:15:38 +0200 | <viluon> | hi, a couple minutes ago I sent an email to haskell-cafe titled "Optimising ReadP," if anyone wants to discuss it here, I'd be happy to |
| 2021-09-21 15:15:49 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-09-21 15:17:38 +0200 | <kuribas> | can't wait for merijn to comment :) |
| 2021-09-21 15:19:28 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-21 15:19:48 +0200 | <merijn> | My main comment would be "don't bother, just nuke it from orbit" >.> |
| 2021-09-21 15:20:03 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 15:22:19 +0200 | chris | (~chris@81.96.113.213) |
| 2021-09-21 15:22:24 +0200 | chris | Guest3409 |
| 2021-09-21 15:22:53 +0200 | spruit11 | (~quassel@2a02:a467:ccd6:1:40b2:87e8:dd1:e5c1) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2021-09-21 15:25:05 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-21 15:29:49 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 15:30:04 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 15:35:10 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 15:35:20 +0200 | <merijn> | viluon: Basically, ReadP having garbage performance is well known and it's less effort to just port your parser to another parser combinator library then it is to optimise ReadP |
| 2021-09-21 15:35:24 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 15:36:06 +0200 | <viluon> | merijn: thanks, would you happen to know why is the performance so poor? |
| 2021-09-21 15:36:09 +0200 | <geekosaur> | ReadP's only saving grace is that it can easily be implemented using only features from base, so it can be used to implement Read instances |
| 2021-09-21 15:36:17 +0200 | <merijn> | viluon: Because ReadP supports ambiguous grammars |
| 2021-09-21 15:36:30 +0200 | <merijn> | viluon: So it it keeps all possible parse traces around |
| 2021-09-21 15:36:36 +0200 | <viluon> | ah |
| 2021-09-21 15:36:43 +0200 | <merijn> | viluon: It also operates on String which is a terrible datatype for parsing |
| 2021-09-21 15:36:54 +0200 | <viluon> | yes, `String` is awful |
| 2021-09-21 15:36:58 +0200 | <viluon> | could you recommend an alternative? |
| 2021-09-21 15:37:22 +0200 | <merijn> | viluon: megaparsec is the most feature complete one. Attoparsec is more minimal in case you don't care about error message quality. |
| 2021-09-21 15:37:36 +0200 | <merijn> | viluon: Parsec if you need to support ridiculously old code |
| 2021-09-21 15:37:42 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 15:37:48 +0200 | <viluon> | is there something even smaller than attoparsec? |
| 2021-09-21 15:37:51 +0200 | <merijn> | But in general megaparsec is the safe bet. Which also lets you parse Text directly |
| 2021-09-21 15:37:56 +0200 | <merijn> | viluon: Not really |
| 2021-09-21 15:38:00 +0200 | <dminuoso> | attoparsec already is fairly small |
| 2021-09-21 15:38:17 +0200 | <dminuoso> | It's dependency footprint is as limited as it can reasonably get |
| 2021-09-21 15:38:57 +0200 | <merijn> | But yeah, ReadP is mostly around for stuff like Read (which also has garbage performance >.>) |
| 2021-09-21 15:40:44 +0200 | <merijn> | viluon: Compare your numbers with stuff like: https://markkarpov.com/post/megaparsec-more-speed-more-power.html |
| 2021-09-21 15:42:03 +0200 | <[itchyjunk]> | wait, i confused myself. haskell functions can only ever take one argument. but i thought we said integers a functions that take no parameters? |
| 2021-09-21 15:42:20 +0200 | <dminuoso> | No, we never did. |
| 2021-09-21 15:42:25 +0200 | <[itchyjunk]> | oh.. |
| 2021-09-21 15:42:31 +0200 | <[itchyjunk]> | weren't integers functions? |
| 2021-09-21 15:42:32 +0200 | <dminuoso> | And that statement is silly and nonsense. |
| 2021-09-21 15:42:34 +0200 | <dminuoso> | No. |
| 2021-09-21 15:42:46 +0200 | <dminuoso> | First, what do you mean by "integers" exactly? |
| 2021-09-21 15:42:50 +0200 | <[itchyjunk]> | 1 |
| 2021-09-21 15:42:55 +0200 | <dminuoso> | The expression 1? |
| 2021-09-21 15:43:05 +0200 | <dminuoso> | So the expression 1 is a polymorphic value, it's not a function. |
| 2021-09-21 15:43:10 +0200 | <dminuoso> | It's type is `Num a => a` |
| 2021-09-21 15:43:37 +0200 | <[itchyjunk]> | hmmm |
| 2021-09-21 15:44:10 +0200 | <dminuoso> | A function is one that maps values of its domain onto values onto its codomain. For instance, a function `f :: Int -> Char` maps every value of type Int to some value of type Char. |
| 2021-09-21 15:44:16 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-21 15:44:16 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-21 15:44:16 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-21 15:44:21 +0200 | <dminuoso> | So you see, the phrase "function that takes no parameters" is nonsensical |
| 2021-09-21 15:44:41 +0200 | <shapr> | has anyone used dataflower at all? |
| 2021-09-21 15:45:07 +0200 | <shapr> | I see many opportunities for timely dataflow in my daily work, but probably would only try such a framework in Haskell |
| 2021-09-21 15:45:22 +0200 | <merijn> | [itchyjunk]: See also: http://conal.net/blog/posts/everything-is-a-function-in-haskell |
| 2021-09-21 15:46:15 +0200 | <dminuoso> | merijn is a manually driven car, just without any of the metal or plastic stuff. |
| 2021-09-21 15:46:32 +0200 | nvmd | (~nvmd@user/nvmd) (Ping timeout: 252 seconds) |
| 2021-09-21 15:46:37 +0200 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2021-09-21 15:48:12 +0200 | nvmd | (~nvmd@user/nvmd) |
| 2021-09-21 15:49:12 +0200 | jokleinn | (~jokleinn@user/jokleinn) |
| 2021-09-21 15:49:27 +0200 | <[itchyjunk]> | merijn, the "7" being sugar notation for ()->7 being mentioned in that post, isn't that functional notation? |
| 2021-09-21 15:49:43 +0200 | zaquest | (~notzaques@5.128.210.178) (Remote host closed the connection) |
| 2021-09-21 15:50:46 +0200 | <[itchyjunk]> | i'll read through this first |
| 2021-09-21 15:51:25 +0200 | <merijn> | [itchyjunk]: The post mentions that's nonsense too :p |
| 2021-09-21 15:51:32 +0200 | <shapr> | I have complaints about haddock, but hoogle still one of the most amazing things in Haskell |
| 2021-09-21 15:52:53 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 264 seconds) |
| 2021-09-21 15:52:53 +0200 | <[itchyjunk]> | I'll have to remembe who i discussed it with.. |
| 2021-09-21 15:53:02 +0200 | <[itchyjunk]> | i thought for sure i talked to someone about this .. |
| 2021-09-21 15:53:33 +0200 | zaquest | (~notzaques@5.128.210.178) |
| 2021-09-21 15:55:34 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-09-21 15:56:29 +0200 | jstolarek | (~jstolarek@erx128.neoplus.adsl.tpnet.pl) (Ping timeout: 264 seconds) |
| 2021-09-21 15:59:11 +0200 | MQ-17J | (~MQ-17J@8.21.10.6) (Ping timeout: 252 seconds) |
| 2021-09-21 15:59:42 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 16:01:38 +0200 | <[itchyjunk]> | This reminds me of something else i was thinking off and getting really confused about |
| 2021-09-21 16:02:33 +0200 | <[itchyjunk]> | someone had told me scalars are just 1 dimentional matrices like [1] and it kinda made snese. but matrix multiplication and scalar multiplication are different beasts.. |
| 2021-09-21 16:02:40 +0200 | <[itchyjunk]> | maybe i got bamboozeled there too |
| 2021-09-21 16:04:31 +0200 | nfd | (~nfd@user/nfd) (Ping timeout: 265 seconds) |
| 2021-09-21 16:04:49 +0200 | <opqdonut> | but matrix multiplication for matrices of size 1x1 works exactly like scalar multiplication? |
| 2021-09-21 16:05:20 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) |
| 2021-09-21 16:06:13 +0200 | alx741 | (~alx741@186.178.109.159) (Ping timeout: 252 seconds) |
| 2021-09-21 16:06:23 +0200 | <opqdonut> | even though matrix multiplication isn't commutative _in general_ there are classes of matrices where it is commutative. 1x1 matrices are one example. diagonal matrices are another |
| 2021-09-21 16:06:33 +0200 | <[itchyjunk]> | yes but i can take a scalar and multiply it to any sized matrix |
| 2021-09-21 16:06:41 +0200 | <[itchyjunk]> | but if 1 is [1], this stops working |
| 2021-09-21 16:06:56 +0200 | <opqdonut> | yeah scaling is different |
| 2021-09-21 16:07:24 +0200 | <opqdonut> | scaling shouldn't use the same symbol as multiplication, it doesn't even have the same type! |
| 2021-09-21 16:07:59 +0200 | <opqdonut> | and e.g. vector spaces have scaling but might not have multiplication |
| 2021-09-21 16:10:08 +0200 | nshepperd2 | (~nshepperd@li364-218.members.linode.com) (Quit: Ping timeout (120 seconds)) |
| 2021-09-21 16:10:22 +0200 | nshepperd2 | (~nshepperd@li364-218.members.linode.com) |
| 2021-09-21 16:10:53 +0200 | Guest3409 | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-09-21 16:11:11 +0200 | SquidDev1 | (~SquidDev@autoclave.squiddev.cc) |
| 2021-09-21 16:11:49 +0200 | Nahra` | (~user@static.161.95.99.88.clients.your-server.de) |
| 2021-09-21 16:12:16 +0200 | ouroboros | (~ouroboros@user/ouroboros) (Ping timeout: 252 seconds) |
| 2021-09-21 16:12:18 +0200 | Philonous_ | (~Philonous@user/philonous) |
| 2021-09-21 16:12:19 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-21 16:12:49 +0200 | Nahra | (~user@static.161.95.99.88.clients.your-server.de) (Ping timeout: 252 seconds) |
| 2021-09-21 16:12:49 +0200 | Philonous | (~Philonous@user/philonous) (Ping timeout: 252 seconds) |
| 2021-09-21 16:12:49 +0200 | sweater | (~sweater@206.81.18.26) (Ping timeout: 252 seconds) |
| 2021-09-21 16:13:20 +0200 | joeyh_ | (~joeyh@kitenet.net) |
| 2021-09-21 16:13:22 +0200 | jlamothe | (~jlamothe@104.158.48.100) (Ping timeout: 252 seconds) |
| 2021-09-21 16:13:22 +0200 | jonatan | (~nate@h85-8-60-194.cust.a3fiber.se) (Ping timeout: 252 seconds) |
| 2021-09-21 16:13:22 +0200 | clever | (~clever@99.192.114.98) (Ping timeout: 252 seconds) |
| 2021-09-21 16:13:22 +0200 | SquidDev | (~SquidDev@autoclave.squiddev.cc) (Ping timeout: 252 seconds) |
| 2021-09-21 16:13:22 +0200 | joeyh | (~joeyh@kitenet.net) (Ping timeout: 252 seconds) |
| 2021-09-21 16:13:22 +0200 | SquidDev1 | SquidDev |
| 2021-09-21 16:13:54 +0200 | jonatan | (~nate@h85-8-60-194.cust.a3fiber.se) |
| 2021-09-21 16:14:14 +0200 | jlamothe | (~jlamothe@104.158.48.100) |
| 2021-09-21 16:14:30 +0200 | sweater | (~sweater@206.81.18.26) |
| 2021-09-21 16:14:46 +0200 | hendursa1 | (~weechat@user/hendursaga) (Quit: hendursa1) |
| 2021-09-21 16:15:10 +0200 | hendursaga | (~weechat@user/hendursaga) |
| 2021-09-21 16:17:59 +0200 | chris | (~chris@81.96.113.213) |
| 2021-09-21 16:18:03 +0200 | chris | Guest250 |
| 2021-09-21 16:18:27 +0200 | ouroboros | (~ouroboros@user/ouroboros) |
| 2021-09-21 16:18:48 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 16:19:07 +0200 | alx741 | (~alx741@186.178.109.225) |
| 2021-09-21 16:19:40 +0200 | clever | (~clever@99.192.114.98) |
| 2021-09-21 16:20:22 +0200 | <viluon> | merijn: I switched to attoparsec, getting the total runtime from 100 ms to 80. 21% of allocations happen in `decimal.step` (from `Data.Attoparsec.Text`), again a generic definition I cannot specialise as it lacks an `INLINE(ABLE)` pragma |
| 2021-09-21 16:20:51 +0200 | <merijn> | Which optimisation level? |
| 2021-09-21 16:21:05 +0200 | acidjnk | (~acidjnk@p200300d0c703cb44319f4c33bc64626e.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2021-09-21 16:21:26 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-09-21 16:21:34 +0200 | <merijn> | And why do you think 1) inlining will avoid allocations and 2) the allocations need to be avoided to speed things up? |
| 2021-09-21 16:22:53 +0200 | Guest250 | (~chris@81.96.113.213) (Ping timeout: 264 seconds) |
| 2021-09-21 16:23:24 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 16:24:56 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 246 seconds) |
| 2021-09-21 16:24:59 +0200 | Vajb | (~Vajb@2001:999:63:cb56:7735:f6b9:cd89:d4c7) |
| 2021-09-21 16:26:07 +0200 | chris | (~chris@81.96.113.213) |
| 2021-09-21 16:26:11 +0200 | chris | Guest9962 |
| 2021-09-21 16:27:09 +0200 | waleee | (~waleee@h-98-128-228-119.NA.cust.bahnhof.se) |
| 2021-09-21 16:27:21 +0200 | maroloccio | (~marolocci@93-142-92-177.adsl.net.t-com.hr) |
| 2021-09-21 16:27:52 +0200 | <lortabac> | merijn: inlining in GHC includes beta reduction, so it can save allocations in some cases |
| 2021-09-21 16:28:18 +0200 | n3t | (n3t@s45.mydevil.net) (Read error: Connection reset by peer) |
| 2021-09-21 16:28:26 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Ping timeout: 246 seconds) |
| 2021-09-21 16:28:35 +0200 | <viluon> | merijn: oxygen (`-O2`). With `ReadP` (or rather the `Lex` utilities), specialising them to `Int` helped. Granted, `decimal.step` is only 8.9% of total time, bigger cost-centres are `>>=.\.succ'` (35.9% time, 30.5% alloc), `>>=.\` (16% time, 17.5% alloc), `fmap.\` (11.0% time, 9.6% alloc), and `fmap.\.succ'` (9.3% time, 11.1% alloc). These are all from `Data.Attoparsec.Internal.Types`. |
| 2021-09-21 16:28:36 +0200 | <viluon> | I don't have a good model of what optimisations could help here, getting one is part of the motivation for this experiment. I'm surprised that the potentially very powerful specialisation and inlining directives are so limited in practical uses. |
| 2021-09-21 16:29:23 +0200 | n3t | (n3t@s45.mydevil.net) |
| 2021-09-21 16:30:22 +0200 | <viluon> | in any case, I still think the parser creates a lot of garbage. I'd at least like to find out what that garbage is; I'll try heap profiling next. |
| 2021-09-21 16:30:41 +0200 | lbseale | (~lbseale@user/ep1ctetus) (Ping timeout: 264 seconds) |
| 2021-09-21 16:31:08 +0200 | <merijn> | What's the problem with lots of garbage, though? |
| 2021-09-21 16:31:11 +0200 | <merijn> | Garbage is cheap |
| 2021-09-21 16:31:29 +0200 | <merijn> | So is allocation |
| 2021-09-21 16:31:34 +0200 | <merijn> | It's non-garbage you gotta worry about |
| 2021-09-21 16:31:41 +0200 | rond_ | (~rond_@2a02:a31a:a23c:f480:2fd7:e087:5546:a438) (Quit: Client closed) |
| 2021-09-21 16:32:35 +0200 | <viluon> | I use `IntMap (Set Int)` to represent a directed graph |
| 2021-09-21 16:33:24 +0200 | <merijn> | Also, on what sorta input? You mention 80ms parse, why is that a problem? |
| 2021-09-21 16:33:35 +0200 | <viluon> | if the parser first builds the entirety of it as a `[(Int, Int)]` and then converts to the map with a `foldl'`, I wasted a lot of time allocating garbage and then traversing a cache-unfriendly data structure |
| 2021-09-21 16:33:49 +0200 | <merijn> | Like, there's a lot of missing information about what you're trying to optimise, with what goal |
| 2021-09-21 16:34:16 +0200 | <merijn> | viluon: Allocating garbage is cheap, though |
| 2021-09-21 16:34:34 +0200 | <viluon> | no it's not |
| 2021-09-21 16:34:39 +0200 | <merijn> | viluon: You gotta abandon any notion about cost of allocation you have from C/Rust |
| 2021-09-21 16:34:44 +0200 | <viluon> | the Rust implementation finishes this test case under 10ms |
| 2021-09-21 16:34:51 +0200 | <merijn> | GHC's alloation is *really* cheap |
| 2021-09-21 16:35:17 +0200 | <merijn> | The fact that the attoparsec parser is slower doesn't necessarily mean it's the allocation that's causing that |
| 2021-09-21 16:35:35 +0200 | <merijn> | Boxing alone will cost you a bunch of performance compared to Rust |
| 2021-09-21 16:35:53 +0200 | <viluon> | i don't really mind if it's allocation or some other thing, I just want to speed it up |
| 2021-09-21 16:36:02 +0200 | <viluon> | although I am interested in laziness pitfalls |
| 2021-09-21 16:36:21 +0200 | <merijn> | viluon: Well, you haven't pasted any code nor profiling output, so that's gonna limit how much useful feedback you get |
| 2021-09-21 16:36:58 +0200 | <viluon> | it's a topological sorting implementation that spends 80+% of the time loading input |
| 2021-09-21 16:37:02 +0200 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-09-21 16:37:40 +0200 | <merijn> | That's nice. But that's entirely useless information for getting feedback on how you might speed things up |
| 2021-09-21 16:37:52 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2021-09-21 16:38:12 +0200 | <viluon> | alright, I'll share the code |
| 2021-09-21 16:38:29 +0200 | <merijn> | All I've seen is some random function names and allocation/time percentages. I mean, what do you expect people to comment on that? |
| 2021-09-21 16:38:51 +0200 | flouflou | (~flouflou@modemcable032.110-177-173.mc.videotron.ca) |
| 2021-09-21 16:38:57 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-21 16:39:12 +0200 | <merijn> | If you wanna be fast, you probably wanna use a Vector based datatype that's filled incrementally from attoparsec, rather than IntMap (Set Int) |
| 2021-09-21 16:39:15 +0200 | <viluon> | not random: they come from a supposedly widely used library |
| 2021-09-21 16:39:48 +0200 | <viluon> | "These are all from `Data.Attoparsec.Internal.Types`" |
| 2021-09-21 16:39:50 +0200 | <merijn> | viluon: Allocation percentage of "fmap" is meaningless without code |
| 2021-09-21 16:40:04 +0200 | lbseale | (~lbseale@user/ep1ctetus) (Remote host closed the connection) |
| 2021-09-21 16:40:29 +0200 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-09-21 16:40:42 +0200 | <viluon> | here's the code: https://paste.tomsmeding.com/4G0bpLx7 |
| 2021-09-21 16:41:23 +0200 | <viluon> | I don't want to sound ungrateful, I really appreciate you taking the time to answer my questions! |
| 2021-09-21 16:42:50 +0200 | <merijn> | viluon: Inst has boxed ints, which you probably don't want, that build in parse' also seems a candidate for a lot of blow up |
| 2021-09-21 16:43:14 +0200 | <merijn> | viluon: Can't you replace the Set with an (optionally) sorted unboxed Vector? |
| 2021-09-21 16:43:44 +0200 | <viluon> | it is inlined and uses a strict fold, `parse'` doesn't show up in top cost centres |
| 2021-09-21 16:44:33 +0200 | <merijn> | viluon: My point is that IntMap + Set is gonna be pretty horrible for accessing a static graph |
| 2021-09-21 16:44:49 +0200 | <merijn> | I'm pretty sure the Rust version doesn't do that and uses an array based representation like CSR |
| 2021-09-21 16:45:21 +0200 | <merijn> | And there's no real reason you couldn't use the same thing in Haskell |
| 2021-09-21 16:45:28 +0200 | <viluon> | sure, but does that matter? |
| 2021-09-21 16:45:45 +0200 | <viluon> | these are the top cost centres https://paste.tomsmeding.com/26S86CNo |
| 2021-09-21 16:46:57 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-21 16:47:02 +0200 | <merijn> | viluon: btw, note that your use of strict state is mostly useless as all the elements in the tuple are still lazy |
| 2021-09-21 16:47:52 +0200 | <viluon> | tbf, the test case I'm running this on may be one where the interesting portion of the digraph lies in a small connected component, so time is spent when processing input but most of it is ignored by the DFS |
| 2021-09-21 16:48:55 +0200 | favonia | (~favonia@user/favonia) |
| 2021-09-21 16:48:56 +0200 | Vajb | (~Vajb@2001:999:63:cb56:7735:f6b9:cd89:d4c7) (Read error: Connection reset by peer) |
| 2021-09-21 16:49:27 +0200 | <merijn> | viluon: What's the output of running with: +RTS -sstderr |
| 2021-09-21 16:49:47 +0200 | jacks2 | (~bc8165b6@217.29.117.252) (Quit: http://www.okay.uz/ (Session timeout)) |
| 2021-09-21 16:49:48 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2021-09-21 16:50:00 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 16:50:49 +0200 | Guest9962 | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-09-21 16:52:51 +0200 | <viluon> | here's the profiling result for a more comprehensive test case: https://paste.tomsmeding.com/RTMOuOID Rust 26.6 ms ± 1.7 ms, Haskell 1.058 s ± 0.054 s. Of course it's far from a fair comparison as both implementations use different approaches, but as the cost centres show, the majority of time is again spent in the parser |
| 2021-09-21 16:53:12 +0200 | <viluon> | I should profile the Rust implementation too I think |
| 2021-09-21 16:54:08 +0200 | <merijn> | Also, are you comparing apples-to-apples? Attoparsec Text does full unicode |
| 2021-09-21 16:54:24 +0200 | <viluon> | apples-to-apples? Definitely not |
| 2021-09-21 16:54:26 +0200 | <merijn> | If the Rust one is only doing ascii, you might wanna compare with the ByteString one |
| 2021-09-21 16:54:47 +0200 | <merijn> | Because a full unicode parser is obviously gonna be slower than a narrow ascii only one |
| 2021-09-21 16:55:26 +0200 | <viluon> | I don't care too much really, the Rust implementation isn't mine. A friend wrote it, then I wrote the Haskell one, and I'm embarrassed that mine is orders of magnitude slower |
| 2021-09-21 16:56:00 +0200 | <viluon> | but I also want to take this opportunity to investigate how often does laziness get in the way of productivity and get an idea of where could GHC improve its optimisation efforts |
| 2021-09-21 16:57:05 +0200 | <viluon> | here's the RTS report as you requested. Again, thanks for all your feedback, questions and suggestions! https://paste.tomsmeding.com/sie584Ts |
| 2021-09-21 16:57:32 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) (Quit: Izem) |
| 2021-09-21 16:57:37 +0200 | <merijn> | Who says the problem here is laziness, though? Or allocation, or inlining as you implied at the start |
| 2021-09-21 16:57:40 +0200 | <merijn> | ok |
| 2021-09-21 16:57:44 +0200 | <merijn> | So, that is a clear sign |
| 2021-09-21 16:57:48 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) |
| 2021-09-21 16:57:55 +0200 | <merijn> | Productivity 57% <- this is garbage |
| 2021-09-21 16:58:07 +0200 | Guest6237 | (~chris@81.96.113.213) |
| 2021-09-21 16:58:11 +0200 | hnOsmium0001 | (uid453710@id-453710.hampstead.irccloud.com) |
| 2021-09-21 16:58:17 +0200 | ysh | (sid6017@id-6017.ilkley.irccloud.com) |
| 2021-09-21 16:58:21 +0200 | <merijn> | Productivity should be 80-90%. So that means you're keeping data alive too long |
| 2021-09-21 16:59:08 +0200 | <viluon> | > Who says the problem here is laziness, though? Or allocation, or inlining as you implied at the start |
| 2021-09-21 16:59:08 +0200 | <viluon> | I didn't, I'm trying to find out |
| 2021-09-21 16:59:10 +0200 | <lambdabot> | <hint>:1:38: error: parse error on input ‘,’ |
| 2021-09-21 16:59:17 +0200 | <viluon> | whoops, sorry lambdabot |
| 2021-09-21 17:00:04 +0200 | <merijn> | viluon: anyway, so currently you're parsing the entire input into a list of Inst, then traversing the list with your solver |
| 2021-09-21 17:00:34 +0200 | <merijn> | That's a lot of data to be live, which would explain the garbage productivity |
| 2021-09-21 17:01:11 +0200 | <merijn> | So I would see what happens if you run the solver immediately when you finish parsing one Inst, so you only have 1 Inst at a time |
| 2021-09-21 17:01:22 +0200 | <viluon> | the list of problem instances (hence `Inst`) isn't longer than 100 elements |
| 2021-09-21 17:01:24 +0200 | <merijn> | i.e. parse Inst, solve, continue |
| 2021-09-21 17:01:27 +0200 | jonathanx | (~jonathan@dyn-8-sc.cdg.chalmers.se) (Remote host closed the connection) |
| 2021-09-21 17:01:47 +0200 | <merijn> | viluon: But each of those elements has an "IntMap (Set Int)" they keep alive |
| 2021-09-21 17:01:53 +0200 | <viluon> | yes |
| 2021-09-21 17:02:14 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2021-09-21 17:02:23 +0200 | Guest6237 | (~chris@81.96.113.213) (Ping timeout: 246 seconds) |
| 2021-09-21 17:02:26 +0200 | <merijn> | viluon: In GHC GC cost is proportional to amount of live data |
| 2021-09-21 17:02:54 +0200 | ikex1 | (~ash@user/ikex) |
| 2021-09-21 17:02:57 +0200 | <merijn> | So keeping those alive a long time increases the GC cost. If you can turn them into garbage asap (by solving immediately) GC cost goes down and productivity goes up |
| 2021-09-21 17:03:42 +0200 | <merijn> | Currently 40% of your runtime is running the GC |
| 2021-09-21 17:03:58 +0200 | ikex | (ash@user/ikex) (Ping timeout: 252 seconds) |
| 2021-09-21 17:03:58 +0200 | ikex1 | ikex |
| 2021-09-21 17:04:08 +0200 | <merijn> | So you wanna improve the rate at which you turn things into garbage |
| 2021-09-21 17:04:17 +0200 | <viluon> | hmm, concerning |
| 2021-09-21 17:04:34 +0200 | <viluon> | "So I would see what happens if you run the solver immediately when you finish parsing one Inst, so you only have 1 Inst at a time" <- is there a way to do that without modifying the code? |
| 2021-09-21 17:05:21 +0200 | <viluon> | is there anything in my implementation that requires GHC to produce code that first parses everything and then processes one-by-one? |
| 2021-09-21 17:05:24 +0200 | <merijn> | viluon: On line 38, instead of returning the Inst, just call your solve function there? |
| 2021-09-21 17:05:35 +0200 | <merijn> | viluon: Yes |
| 2021-09-21 17:06:13 +0200 | <merijn> | viluon: Your "parse" has to consume the entire input and turn it into a list to know if the parse succeeds |
| 2021-09-21 17:06:57 +0200 | <merijn> | viluon: Alternatively you'd want one of the streaming libraries to interleave parsing Inst instance and solving them, which would also enforce the "1 element at a time" |
| 2021-09-21 17:07:15 +0200 | x28girl | (~x28girl@user/x28girl) |
| 2021-09-21 17:08:02 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-09-21 17:08:03 +0200 | <merijn> | viluon: For cases like this where you're mostly parsing a stream of inputs and processing them, streaming libraries like conduit/pipes/etc. help interleave the IO/parsing and processing |
| 2021-09-21 17:08:09 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 17:08:51 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-21 17:09:17 +0200 | <merijn> | (of course, that's a bit more boilerplate to set up) |
| 2021-09-21 17:09:31 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-21 17:09:38 +0200 | <viluon> | I changed the definition of `solve` to `solve = fromMaybe [] . maybeResult . Attoparsec.parse (fmap solve' <$> parse) <$> Text.getContents` |
| 2021-09-21 17:10:15 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-21 17:10:19 +0200 | <merijn> | Not sure that's gonna help with the double fmap, but it might |
| 2021-09-21 17:10:49 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 17:11:38 +0200 | <viluon> | it did not |
| 2021-09-21 17:12:02 +0200 | <viluon> | but now there's no reason to parse everything at once, is there? |
| 2021-09-21 17:12:13 +0200 | <monochrom> | Absolutely no reason. |
| 2021-09-21 17:14:29 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Ping timeout: 264 seconds) |
| 2021-09-21 17:15:00 +0200 | <monochrom> | Lately I wrote my own "parser" monad that restores laziness by sacrificing error checking. The use case is that there won't be parse errors anyway. |
| 2021-09-21 17:15:17 +0200 | maroloccio | (~marolocci@93-142-92-177.adsl.net.t-com.hr) (Quit: WeeChat 3.0) |
| 2021-09-21 17:15:21 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 17:15:55 +0200 | <monochrom> | Therefore one point is that "String -> []/Maybe (String, a)" is reduced to "String -> (String, a)". (This is not compulsory.) |
| 2021-09-21 17:16:00 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-21 17:16:03 +0200 | oxide | (~lambda@user/oxide) (Ping timeout: 265 seconds) |
| 2021-09-21 17:17:12 +0200 | ub | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) |
| 2021-09-21 17:17:42 +0200 | oxide | (~lambda@user/oxide) |
| 2021-09-21 17:18:04 +0200 | <monochrom> | The second point is I define "later (P f) = P (\s -> case f s of ~(s2, a) -> (s2, a))" |
| 2021-09-21 17:18:33 +0200 | <monochrom> | Note how it increases laziness at the right place. |
| 2021-09-21 17:19:01 +0200 | Guest70 | (~Guest70@p200300f7770a55e9b9601923eb36d679.dip0.t-ipconnect.de) |
| 2021-09-21 17:19:09 +0200 | <monochrom> | And it is analogous to unsafeInterleaveIO. |
| 2021-09-21 17:19:25 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-21 17:20:27 +0200 | <monochrom> | So now I can have my own lazier version of replicateM. rep n p = do { x <- p; xs <- later (rep (n-1) p); pure (x:xs) } |
| 2021-09-21 17:20:49 +0200 | <ldlework> | nerd |
| 2021-09-21 17:21:08 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2021-09-21 17:21:16 +0200 | <monochrom> | This will run x<-p, jump ahead to "pure (x:xs)", and delay running rep (n-1) p until you force xs. |
| 2021-09-21 17:22:14 +0200 | ub | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2021-09-21 17:22:17 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-21 17:22:26 +0200 | <monochrom> | Alternatively, you can decide to make this pervasive, and build the ~(s2, a) lazy pattern right in the definition of >>=. This is what Control.Monad.Trans.State.Lazy does. |
| 2021-09-21 17:22:56 +0200 | <monochrom> | So every m>>=cb is effectively m>>=\a->later(cb a) |
| 2021-09-21 17:23:15 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 17:24:13 +0200 | <viluon> | merijn: any other suggestions? I don't want to introduce a streaming library for something that should not have these performance issues in the first place and I don't like the idea of changing my input parser into a solver – I want reusable code, and I'd like it to perform well when I compose it with other code. Sadly the optimiser is a black box and its decisions are unknowable to me |
| 2021-09-21 17:24:45 +0200 | chris | (~chris@81.96.113.213) |
| 2021-09-21 17:24:49 +0200 | chris | Guest8849 |
| 2021-09-21 17:26:13 +0200 | <viluon> | oh wait, merijn is gone |
| 2021-09-21 17:28:21 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 17:30:14 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:4252:bf51:4908:8ea0) (Quit: WeeChat 2.8) |
| 2021-09-21 17:30:19 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) |
| 2021-09-21 17:34:12 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Ping timeout: 276 seconds) |
| 2021-09-21 17:35:18 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-09-21 17:35:33 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-09-21 17:35:51 +0200 | <Izem> | How do you say `reads :: (Read a) => ReadS a` in English? reads has type ... |
| 2021-09-21 17:35:53 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-09-21 17:36:39 +0200 | <monochrom> | ReadS a, but a has to be an instance of Read |
| 2021-09-21 17:36:39 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-09-21 17:36:54 +0200 | <monochrom> | Frankly I wouldn't translate to English. |
| 2021-09-21 17:36:59 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-09-21 17:37:03 +0200 | Guest70 | (~Guest70@p200300f7770a55e9b9601923eb36d679.dip0.t-ipconnect.de) (Quit: Client closed) |
| 2021-09-21 17:37:08 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.2.1) |
| 2021-09-21 17:37:26 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-09-21 17:37:34 +0200 | <monochrom> | It is fair to ask how to work with that type, and how to write your own. |
| 2021-09-21 17:37:46 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-09-21 17:37:51 +0200 | <monochrom> | "how to translate to English" is an XY problem. |
| 2021-09-21 17:37:59 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-09-21 17:38:04 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-21 17:38:04 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-21 17:38:04 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-21 17:38:18 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-09-21 17:38:18 +0200 | <monochrom> | If programming were better off in English, we would all be in a #cobol channel already. |
| 2021-09-21 17:38:27 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-09-21 17:39:05 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-09-21 17:39:21 +0200 | <monochrom> | This is why I wrote http://www.vex.net/~trebla/haskell/prerequisite.xhtml |
| 2021-09-21 17:40:01 +0200 | <monochrom> | Use your algebra skills, so you are free of the clumsiness of English when code gets real. |
| 2021-09-21 17:41:12 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-09-21 17:41:30 +0200 | <monochrom> | English is not compositional. Programming languages are. This is not just Haskell. You can also have "daunting" types and terms in Java and C. |
| 2021-09-21 17:41:32 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-09-21 17:42:03 +0200 | x28girl | (~x28girl@user/x28girl) (Remote host closed the connection) |
| 2021-09-21 17:42:47 +0200 | x28girl | (~x28girl@user/x28girl) |
| 2021-09-21 17:43:01 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2021-09-21 17:43:05 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-09-21 17:43:25 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-09-21 17:43:33 +0200 | x28girl | (~x28girl@user/x28girl) (Remote host closed the connection) |
| 2021-09-21 17:44:05 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2021-09-21 17:45:27 +0200 | chronon | (~chronon@user/chronon) |
| 2021-09-21 17:45:33 +0200 | doyougnu | (~user@c-73-25-202-122.hsd1.or.comcast.net) (Remote host closed the connection) |
| 2021-09-21 17:45:50 +0200 | doyougnu | (~user@c-73-25-202-122.hsd1.or.comcast.net) |
| 2021-09-21 17:49:46 +0200 | <viluon> | is there a way to get a more detailed heap profile? the cost centres in the default `-hc` report just end with `...` |
| 2021-09-21 17:49:56 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 17:50:10 +0200 | <viluon> | wb merijn |
| 2021-09-21 17:50:50 +0200 | jokleinn | (~jokleinn@user/jokleinn) (Ping timeout: 252 seconds) |
| 2021-09-21 17:50:54 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-09-21 17:51:13 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-09-21 17:51:27 +0200 | jokleinn | (~jokleinn@user/jokleinn) |
| 2021-09-21 17:51:47 +0200 | xiongxin | (~quassel@119.123.102.205) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2021-09-21 17:51:48 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-09-21 17:52:35 +0200 | qbt | (~edun@user/edun) (Quit: Leaving) |
| 2021-09-21 17:53:09 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 17:53:18 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2021-09-21 17:53:28 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-09-21 17:54:32 +0200 | yinghua | (~yinghua@2800:2121:1400:1db:705e:acf0:71e7:8a79) |
| 2021-09-21 17:54:41 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-21 17:55:40 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) (Ping timeout: 252 seconds) |
| 2021-09-21 17:56:14 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) |
| 2021-09-21 17:56:45 +0200 | __monty__ | (~toonn@user/toonn) |
| 2021-09-21 17:58:32 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-21 18:03:50 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 18:04:29 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2021-09-21 18:05:14 +0200 | Guest8849 | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-09-21 18:06:00 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2021-09-21 18:08:17 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-21 18:12:42 +0200 | chris | (~chris@81.96.113.213) |
| 2021-09-21 18:12:46 +0200 | chris | Guest2529 |
| 2021-09-21 18:12:50 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-09-21 18:14:30 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 18:17:14 +0200 | Guest2529 | (~chris@81.96.113.213) (Ping timeout: 252 seconds) |
| 2021-09-21 18:17:19 +0200 | zebrag | (~chris@user/zebrag) |
| 2021-09-21 18:17:28 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2021-09-21 18:19:07 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 18:28:42 +0200 | tommd | (~tommd@75-164-130-101.ptld.qwest.net) |
| 2021-09-21 18:31:02 +0200 | nfd | (~nfd@user/nfd) |
| 2021-09-21 18:31:15 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2021-09-21 18:34:50 +0200 | nschoe | (~quassel@178.251.84.79) (Ping timeout: 265 seconds) |
| 2021-09-21 18:35:14 +0200 | nschoe | (~quassel@178.251.84.79) |
| 2021-09-21 18:36:42 +0200 | jokleinn | (~jokleinn@user/jokleinn) (Quit: WeeChat 3.2) |
| 2021-09-21 18:45:06 +0200 | rond_ | (~rond_@2a02:a31a:a23c:f480:2fd7:e087:5546:a438) |
| 2021-09-21 18:50:16 +0200 | bonizzi | (~bonizzi@2804:14c:65d3:4689:d52e:1289:d36a:ed19) |
| 2021-09-21 18:50:30 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 18:50:43 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 18:51:00 +0200 | on^ | (~on@12.203.127.82) (Remote host closed the connection) |
| 2021-09-21 18:52:53 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) |
| 2021-09-21 18:57:04 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 265 seconds) |
| 2021-09-21 18:57:45 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-09-21 18:57:52 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) (Quit: Izem) |
| 2021-09-21 18:58:08 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) |
| 2021-09-21 19:00:41 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-21 19:01:47 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 252 seconds) |
| 2021-09-21 19:02:12 +0200 | nschoe | (~quassel@178.251.84.79) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2021-09-21 19:02:18 +0200 | dsrt^ | (~dsrt@12.203.127.82) |
| 2021-09-21 19:07:49 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-09-21 19:10:01 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-09-21 19:16:41 +0200 | <dminuoso> | monochrom: In English you can compose almost any two sentences, irrespective of whether it's sensible. There's also a man in the shadows with a gun in his eye. |
| 2021-09-21 19:17:54 +0200 | <dminuoso> | Izem: I would read that as: forall a, where Read a, reads has type ReadS a. |
| 2021-09-21 19:19:16 +0200 | <dminuoso> | monochrom: Im not sure how you teach Haskell, but I think having some uniform way to read out types can be useful at the beginning. It makes answering the question "what is the type of `xyz`" more sensible in a teaching scenario. |
| 2021-09-21 19:19:54 +0200 | <monochrom> | I teach how to break it up. |
| 2021-09-21 19:20:14 +0200 | <dminuoso> | I dont think of that above type signature as complicated enough to warrant breaking it up.. |
| 2021-09-21 19:20:39 +0200 | <monochrom> | And the role of each part. |
| 2021-09-21 19:20:42 +0200 | <Izem> | dminuoso: Is a an instance of Read? |
| 2021-09-21 19:20:53 +0200 | <dminuoso> | Izem: It's *required* to have one. |
| 2021-09-21 19:21:01 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Remote host closed the connection) |
| 2021-09-21 19:21:21 +0200 | <dminuoso> | Izem: The thing with type variables is, the caller/user picks them. They are free to pick *any* type they want for them, as long as the specified constraints are satisfied. |
| 2021-09-21 19:21:58 +0200 | <dminuoso> | So the user of `reads` can/has to pick any type they want, but their choice is limited to any type for which an `instance Read` exists. |
| 2021-09-21 19:22:20 +0200 | <Izem> | ok |
| 2021-09-21 19:22:24 +0200 | <dminuoso> | And its polymorphic. Hence my way of phrasing it "forall a, where Read a, reads has type ReadS a" |
| 2021-09-21 19:22:32 +0200 | <dminuoso> | similarly: |
| 2021-09-21 19:22:34 +0200 | <dminuoso> | % :t id |
| 2021-09-21 19:22:34 +0200 | <yahb> | dminuoso: a -> a |
| 2021-09-21 19:23:05 +0200 | <dminuoso> | Id say `id :: a -> a` as "forall a, id has type a to a" |
| 2021-09-21 19:23:07 +0200 | <Izem> | id is in the environment already? |
| 2021-09-21 19:23:21 +0200 | <Izem> | what does it do? |
| 2021-09-21 19:23:27 +0200 | <monochrom> | I teach =>-less types first. That already is a long story on its own. There is parametric polymorphism. There is X->Y and X1->X2->Y, and I spend time showing that it means X1->(X2->Y), how it plays well with (f x1) x2, why it is useful. |
| 2021-09-21 19:24:08 +0200 | <dminuoso> | Izem: `id` is a function that is made available in Prelude. It's one of the most simplistic functions you can think of, it just returns its argument. |
| 2021-09-21 19:24:20 +0200 | <Izem> | ok |
| 2021-09-21 19:24:25 +0200 | <monochrom> | After that, one is ready for classes and instances. After knowing classes and instances, "Read a =>" is not a mystery. |
| 2021-09-21 19:24:51 +0200 | <awpr> | personally I pronounce the typeclass constraint arrow and the function arrow both as just "arrow". they're almost the same thing anyway, just that => takes Constraints on the lhs, is invisible/auto-solved in expressions, and is very enthusiastic to specialize |
| 2021-09-21 19:24:56 +0200 | <dminuoso> | monochrom: Makes perfect sense. Perhaps I missed something, I had not conversed with Izem before. |
| 2021-09-21 19:25:00 +0200 | <monochrom> | My view is that a plea for "what is it in English" stems from having none of the above preparation at all. |
| 2021-09-21 19:25:05 +0200 | <dminuoso> | Judging by just that question, it seemed fair to ask. |
| 2021-09-21 19:25:26 +0200 | <awpr> | but admittedly for learning it's probably easier to think of constraints as restrictions on allowable types |
| 2021-09-21 19:25:27 +0200 | <dminuoso> | But if you have had prior interaction and knew their level of expertise (which perhaps is lower than I assumed).. |
| 2021-09-21 19:25:50 +0200 | <monochrom> | As I said, the real question behind is fair to ask. The translation quesiton is an XY problem. Lots of students do it. |
| 2021-09-21 19:27:03 +0200 | asivitz | (uid178348@id-178348.tinside.irccloud.com) |
| 2021-09-21 19:27:27 +0200 | <dminuoso> | awpr: Mmm, I dont think of the constraint arrow and function arrows as the same thing simply because they happen in different places. |
| 2021-09-21 19:27:36 +0200 | <dminuoso> | One is a type checker level thing, the other is a runtime thing. |
| 2021-09-21 19:27:47 +0200 | <dminuoso> | To equate them seems dangerously confusing. |
| 2021-09-21 19:27:56 +0200 | <awpr> | they're both a runtime thing, unless GHC optimizes the constraint away |
| 2021-09-21 19:28:21 +0200 | <awpr> | but GHC could equally well optimize away a function arrow, e.g. in spec-constr optimization |
| 2021-09-21 19:28:28 +0200 | <dminuoso> | No it's still a type checking thing. |
| 2021-09-21 19:28:34 +0200 | econo | (uid147250@user/econo) |
| 2021-09-21 19:28:40 +0200 | <awpr> | deciding what value to pass is a type-checker thing |
| 2021-09-21 19:29:08 +0200 | <monochrom> | At any rate, I had already provided a translation before I explained why I objected. |
| 2021-09-21 19:29:16 +0200 | <awpr> | actually receiving the instance dictionary is a runtime thing |
| 2021-09-21 19:29:23 +0200 | <dminuoso> | monochrom: oh, I think I missed that singular line when I scrolled. |
| 2021-09-21 19:29:29 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) (Quit: Izem) |
| 2021-09-21 19:29:29 +0200 | <monochrom> | But here is the thing. |
| 2021-09-21 19:29:55 +0200 | <dminuoso> | awpr: instance dictionary is an implementation detail. |
| 2021-09-21 19:30:06 +0200 | <awpr> | heap object is an implementation detail |
| 2021-09-21 19:30:08 +0200 | <monochrom> | If you don't have the prerequisite, the translation adds no predictive power. It is "helpful" only in the sense that it makes you feel good. |
| 2021-09-21 19:30:13 +0200 | <dminuoso> | Yes, and I dont talk about heap objects. Your point being? |
| 2021-09-21 19:30:33 +0200 | <monochrom> | If you have the prerequisite, you won't be asking in the first place. My students certainly don't. |
| 2021-09-21 19:30:34 +0200 | <awpr> | they're still exactly the same construct at runtime, modulo optimizations |
| 2021-09-21 19:31:09 +0200 | <awpr> | the only difference is in how it's determined at a given callsite what argument is actually passed |
| 2021-09-21 19:31:37 +0200 | <awpr> | for (->) it's a visible argument, and for (=>) it's solved by constraint resolution |
| 2021-09-21 19:31:38 +0200 | <monochrom> | Even when they're lost, my students ask more to-the-point questions, such as "what does the 'Read a =>' thing mean" or "where can I find out more about Read". |
| 2021-09-21 19:31:38 +0200 | Izem | (~Srain@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) |
| 2021-09-21 19:31:59 +0200 | Izem | (~Srain@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) () |
| 2021-09-21 19:32:33 +0200 | <dminuoso> | awpr: It starts being wrong already because of MMR. |
| 2021-09-21 19:32:55 +0200 | <dminuoso> | Which is not just some "modulo optimization", its a builtin language feature with defined semantics |
| 2021-09-21 19:32:55 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-21 19:33:56 +0200 | <awpr> | monomorphism restriction just constrains inferred types, no? |
| 2021-09-21 19:34:25 +0200 | <awpr> | if the monomorphism restriction affects an expression, then its type doesn't involve a constraint anyway |
| 2021-09-21 19:34:28 +0200 | <dminuoso> | It's to faciliate sharing |
| 2021-09-21 19:34:40 +0200 | <dminuoso> | hold on |
| 2021-09-21 19:34:52 +0200 | <dminuoso> | why doesnt it involve a constraint anyway? |
| 2021-09-21 19:35:01 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2021-09-21 19:35:02 +0200 | <awpr> | because it's been monomorphized |
| 2021-09-21 19:35:06 +0200 | <dminuoso> | So? |
| 2021-09-21 19:35:19 +0200 | <dminuoso> | Num Int is a valid constraint to write, if you want. |
| 2021-09-21 19:35:22 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2021-09-21 19:35:37 +0200 | <awpr> | yes, but that constraint isn't part of the inferred type, it's solved immediately |
| 2021-09-21 19:36:14 +0200 | <dminuoso> | So MMR makes this imaginary function go away? |
| 2021-09-21 19:36:15 +0200 | ub | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) |
| 2021-09-21 19:36:24 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 19:36:31 +0200 | <dminuoso> | So `Num Int => ...` is not a "function" but `Num a => ...` is? |
| 2021-09-21 19:36:54 +0200 | <awpr> | there are two expressions that are relevant: the thing that causes the Num constraint, and the larger expression affected by MMR |
| 2021-09-21 19:37:00 +0200 | <dminuoso> | I dont know, not sure what valuable insights you can gain from thinking of => as a function arrow. |
| 2021-09-21 19:37:26 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-21 19:38:48 +0200 | jstolarek | (~jstolarek@erx128.neoplus.adsl.tpnet.pl) |
| 2021-09-21 19:39:40 +0200 | <awpr> | the effect of MMR is just that the inferred type is monomorphized, which usually results in the constraint solver being able to solve and immediately apply the inner term's constraint, so that it doesn't get propagated as a constraint on the inferred type |
| 2021-09-21 19:39:59 +0200 | <monochrom> | There was a GHC bug. It was an accidental abstraction leak. It lets you write one of "Read a => String => a" or "Read a -> String -> a", I forgot which, but it was funny. |
| 2021-09-21 19:40:35 +0200 | ub | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) (Ping timeout: 246 seconds) |
| 2021-09-21 19:41:12 +0200 | <awpr> | I guess that happened around the time GHC was changed to have Constraint be literally the same thing as Type internally? |
| 2021-09-21 19:41:59 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 19:43:00 +0200 | <monochrom> | Yeah something like that. |
| 2021-09-21 19:43:15 +0200 | <monochrom> | ConstraintKind |
| 2021-09-21 19:43:45 +0200 | <monochrom> | along with "kind is type too" etc |
| 2021-09-21 19:43:45 +0200 | <awpr> | as for what insights: to me it seems to make parametricity clearer. having a constraint doesn't reduce the strength of parametricity by "magic" because it "makes fewer types legal arguments", it just adds a record argument containing the instance methods to the polytype |
| 2021-09-21 19:46:37 +0200 | <awpr> | anyway I definitely think it's valuable to have the other view (constraints as limitations on polymorphism) as another angle, possibly even as the default way of looking at things, I just like to have both available |
| 2021-09-21 19:47:04 +0200 | kuribas | (~user@ptr-25vy0i747grimuk7ofw.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2021-09-21 19:50:22 +0200 | <awpr> | oh, I missed a key part of one message: `Num Int => ...` is also (using the term loosely) a function. it's just that GHC won't ever infer that type and make that function, instead it'll immediately solve `Num Int` and apply it to the subexpression that needed it. if you spell out that constraint, I'm not sure whether GHC will actually do what you said or just optimize it out of existence; I should check |
| 2021-09-21 19:50:46 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 19:50:50 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 19:51:04 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 19:52:51 +0200 | <monochrom> | I unify "static" and "dynamic" with hugs and ghci |
| 2021-09-21 19:53:13 +0200 | <awpr> | yes, it will let you make that into an actual function: paste.tomsmeding.com/9DPBxuwa |
| 2021-09-21 19:53:22 +0200 | <monochrom> | @quote lambdabot runghc |
| 2021-09-21 19:53:22 +0200 | <lambdabot> | No quotes match. Listen, broccoli brains, I don't have time to listen to this trash. |
| 2021-09-21 19:53:34 +0200 | <monochrom> | @quote monochrom runghc |
| 2021-09-21 19:53:34 +0200 | <lambdabot> | monochrom says: just add #! /usr/bin/runghc to your haskell file. then type errors occur at runtime only. |
| 2021-09-21 19:53:56 +0200 | <tomsmeding> | or -fdefer-type-errors |
| 2021-09-21 19:54:06 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 265 seconds) |
| 2021-09-21 19:54:16 +0200 | <monochrom> | Oh, it was a long time ago, -fdefer-type-errors did not exist. |
| 2021-09-21 19:54:59 +0200 | <monochrom> | Also, probably s/with/by/ |
| 2021-09-21 19:55:05 +0200 | <monochrom> | This is why I hate English. |
| 2021-09-21 19:55:53 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 19:55:55 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2021-09-21 19:56:08 +0200 | <monochrom> | awpr, did you need to turn on an extension, maybe FlexibleContext, to legalize Num Int? |
| 2021-09-21 19:56:16 +0200 | <awpr> | yep, exactly that |
| 2021-09-21 19:56:29 +0200 | <awpr> | ++'s' |
| 2021-09-21 19:56:58 +0200 | <monochrom> | This is why I hate meaningful names cast in English. |
| 2021-09-21 19:57:26 +0200 | <awpr> | GHC proposal: rename all language extensions into Lojban |
| 2021-09-21 19:57:39 +0200 | <monochrom> | Chinese is a bit better in this regard, free of that kind of hair splitting. |
| 2021-09-21 19:58:09 +0200 | <awpr> | no singular/plural distinction on the basic forms of nouns? |
| 2021-09-21 19:58:18 +0200 | <monochrom> | None. |
| 2021-09-21 19:58:26 +0200 | <monochrom> | And no preposition madness either. |
| 2021-09-21 19:58:27 +0200 | <awpr> | cool, same reason I reached for Lojban |
| 2021-09-21 19:59:14 +0200 | <awpr> | but I think Chinese might just slightly take the edge w.r.t. number of fluent speakers |
| 2021-09-21 20:00:41 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 264 seconds) |
| 2021-09-21 20:00:47 +0200 | <c_wraith> | I've heard that Chinese has an issue with reading and writing not being symmetric. A lot more native speakers can read than can write. (It's much easier to recognize characters than to remember them without a visual prompt) |
| 2021-09-21 20:01:22 +0200 | <gehmehgeh> | Those Lojban language examples on Wikipedia look like something Cthulu would say :D |
| 2021-09-21 20:01:35 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) |
| 2021-09-21 20:01:39 +0200 | <gehmehgeh> | (I hadn't heard about Lojban und thought I look it up) |
| 2021-09-21 20:01:58 +0200 | <monochrom> | I doubt it. I mean I doubt that it is more than other languages. |
| 2021-09-21 20:02:57 +0200 | <geekosaur> | it used to be called logban, iirc |
| 2021-09-21 20:03:04 +0200 | <geekosaur> | er, loglan |
| 2021-09-21 20:03:22 +0200 | <monochrom> | Any of you claim you have the same fluency in writing "zygomorphism" as you are fluent in reading it? |
| 2021-09-21 20:03:33 +0200 | <c_wraith> | synthetic words like that are easy to write |
| 2021-09-21 20:03:53 +0200 | geekosaur | has less problem reading or writing it than understanding it |
| 2021-09-21 20:03:55 +0200 | <c_wraith> | the difficulty in writing in English is when you *don't* know where the loan words originate |
| 2021-09-21 20:05:46 +0200 | <geekosaur> | yoğurt |
| 2021-09-21 20:06:17 +0200 | <monochrom> | OK, people mix up "effect" and "affect". |
| 2021-09-21 20:06:55 +0200 | <gehmehgeh> | inapt and inept :D |
| 2021-09-21 20:06:56 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-09-21 20:07:27 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-21 20:07:28 +0200 | <gehmehgeh> | (Tought, inapt and inept at least sound different) |
| 2021-09-21 20:08:04 +0200 | <monochrom> | You know, to someone like me with ESL background, they sound too similar. |
| 2021-09-21 20:08:21 +0200 | favonia | (~favonia@user/favonia) |
| 2021-09-21 20:09:08 +0200 | <monochrom> | Generally we have difficulty distinguishing, or reproducing the difference of, "at" and "et". |
| 2021-09-21 20:09:30 +0200 | <monochrom> | Some of us can't even draw a line between "name" and "nam". |
| 2021-09-21 20:09:57 +0200 | <monochrom> | You will hear some of us saying "my nam is monochrom, I like to play gams". |
| 2021-09-21 20:11:05 +0200 | <Rembane> | manachram! |
| 2021-09-21 20:11:06 +0200 | Rembane | nods |
| 2021-09-21 20:12:46 +0200 | <geekosaur> | I find that interesting because, so far as English has reliable rules, that's one of them |
| 2021-09-21 20:14:09 +0200 | <monochrom> | But there is something about, it takes several years, and a very young and plastic brain, to train to recognize that there is a difference. |
| 2021-09-21 20:14:16 +0200 | <monochrom> | any difference. |
| 2021-09-21 20:14:53 +0200 | <monochrom> | I have trouble telling apart red hair and blonde hair. This is why I didn't see enough examples when I was a child. |
| 2021-09-21 20:15:03 +0200 | <gehmehgeh> | monochrom: what dialect/variant of the English language are you speaking? |
| 2021-09-21 20:15:27 +0200 | <monochrom> | s/why/because/ |
| 2021-09-21 20:16:29 +0200 | <monochrom> | You will have trouble telling apart, say, Chinese faces from Japanese faces from Korean faces. This is because you didn't see enough examples when you were a child. East Asian people like me can tell them apart, we saw enough examples. |
| 2021-09-21 20:16:42 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 20:16:50 +0200 | <gehmehgeh> | monochrom: I think I can tell them apart, too. |
| 2021-09-21 20:16:53 +0200 | <gehmehgeh> | monochrom: I'm from Germany |
| 2021-09-21 20:17:19 +0200 | <gehmehgeh> | That is, generally. Some people have faces that could come from anywhere |
| 2021-09-21 20:17:19 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-09-21 20:17:19 +0200 | <monochrom> | I don't know. I started in Hong Kong. I am in Canada. I have heard British, American, Canadian, perhaps also Singapore and Polish. |
| 2021-09-21 20:17:42 +0200 | <ldlework> | awpr: did you see the latest graph |
| 2021-09-21 20:17:45 +0200 | <geekosaur> | "American" has plenty of dialects all by itself |
| 2021-09-21 20:18:00 +0200 | <gehmehgeh> | Canadian being one of them ;) |
| 2021-09-21 20:18:31 +0200 | <awpr> | ldlework: I think so, with 14 classes and full method listings for them? |
| 2021-09-21 20:18:37 +0200 | <monochrom> | I had a prof from Singapore who pronouced "library" by putting the accent on the "y". |
| 2021-09-21 20:18:45 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-21 20:18:46 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-21 20:18:56 +0200 | <ldlework> | yeah this one https://github.com/dustinlacewell/haskell-typeclass-atlas/blob/master/atlas.png?raw=true |
| 2021-09-21 20:19:05 +0200 | <awpr> | y |
| 2021-09-21 20:19:15 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 20:20:07 +0200 | <monochrom> | So imagine "comprehend" applied to "library" |
| 2021-09-21 20:24:18 +0200 | <monochrom> | Nice class atlas. |
| 2021-09-21 20:24:43 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-21 20:25:28 +0200 | <monochrom> | Ugh where are Bounded, Enum, Show, Read? :) |
| 2021-09-21 20:26:26 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2021-09-21 20:27:41 +0200 | <zzz> | what's a good resource to learn about kind signatures? |
| 2021-09-21 20:31:11 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) |
| 2021-09-21 20:31:59 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Ping timeout: 252 seconds) |
| 2021-09-21 20:33:06 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-09-21 20:34:53 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 264 seconds) |
| 2021-09-21 20:36:19 +0200 | <Franciman> | is there a way to make cabal output Core code of the files in the project? |
| 2021-09-21 20:37:02 +0200 | <awpr> | does `ghc-options: -ddump-simpl` work? |
| 2021-09-21 20:37:19 +0200 | neurocyte013 | (~neurocyte@212.232.95.106) |
| 2021-09-21 20:37:19 +0200 | neurocyte013 | (~neurocyte@212.232.95.106) (Changing host) |
| 2021-09-21 20:37:19 +0200 | neurocyte013 | (~neurocyte@user/neurocyte) |
| 2021-09-21 20:37:56 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-21 20:41:48 +0200 | neurocyte013 | (~neurocyte@user/neurocyte) (Client Quit) |
| 2021-09-21 20:43:09 +0200 | neurocyte013 | (~neurocyte@212.232.95.106) |
| 2021-09-21 20:43:09 +0200 | neurocyte013 | (~neurocyte@212.232.95.106) (Changing host) |
| 2021-09-21 20:43:09 +0200 | neurocyte013 | (~neurocyte@user/neurocyte) |
| 2021-09-21 20:43:34 +0200 | viluon | (uid453725@id-453725.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-09-21 20:49:53 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-09-21 20:49:56 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) (Quit: mikoto-chan) |
| 2021-09-21 20:50:14 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-21 20:53:01 +0200 | ubert | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2021-09-21 20:56:21 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 20:56:44 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 252 seconds) |
| 2021-09-21 20:57:20 +0200 | ubert | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) |
| 2021-09-21 21:00:04 +0200 | oxide | (~lambda@user/oxide) (Quit: oxide) |
| 2021-09-21 21:03:00 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 21:04:12 +0200 | Cajun | (~Cajun@user/cajun) (Quit: Client closed) |
| 2021-09-21 21:07:39 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Remote host closed the connection) |
| 2021-09-21 21:09:21 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 21:12:14 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-21 21:12:14 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-21 21:12:14 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-21 21:16:25 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-09-21 21:26:35 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 21:32:06 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 21:32:15 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-21 21:33:29 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-09-21 21:39:38 +0200 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) (Quit: WeeChat 3.2) |
| 2021-09-21 21:41:50 +0200 | favonia | (~favonia@user/favonia) |
| 2021-09-21 21:45:06 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-09-21 21:46:10 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2021-09-21 21:46:11 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 21:46:24 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 21:46:44 +0200 | Izem | (~user@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) |
| 2021-09-21 21:47:16 +0200 | TranquilEcho | (~grom@user/tranquilecho) |
| 2021-09-21 21:51:07 +0200 | bonizzi | (~bonizzi@2804:14c:65d3:4689:d52e:1289:d36a:ed19) (Quit: Leaving) |
| 2021-09-21 21:51:31 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 21:51:44 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 21:53:05 +0200 | ubert | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) (Quit: ubert) |
| 2021-09-21 21:53:17 +0200 | ubert | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) |
| 2021-09-21 21:53:49 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-09-21 21:54:09 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-09-21 21:55:04 +0200 | ubert | (~Thunderbi@77.119.204.226.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2021-09-21 21:55:53 +0200 | <maerwald> | monochrom: lol, senglish is awesome |
| 2021-09-21 21:56:00 +0200 | <maerwald> | can |
| 2021-09-21 21:57:20 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 21:59:53 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 22:00:03 +0200 | <ixlun> | Is there a 'standard' way of representing 0 with Rational? |
| 2021-09-21 22:00:17 +0200 | <ixlun> | I'm using `0 % 1`, but is there a standard? |
| 2021-09-21 22:01:41 +0200 | <geekosaur> | 0 % 1, or just write 0 and let Num literal magic do its thing |
| 2021-09-21 22:02:11 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-21 22:03:18 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-21 22:04:20 +0200 | <ixlun> | Ah, didn't know I could do `0 :: Rational` and that woeks. Neat! |
| 2021-09-21 22:04:24 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
| 2021-09-21 22:05:22 +0200 | juhp | (~juhp@128.106.188.220) (Ping timeout: 252 seconds) |
| 2021-09-21 22:05:29 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2021-09-21 22:06:17 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) (Quit: Leaving) |
| 2021-09-21 22:06:53 +0200 | TDANG | (~TDANG@inet-177-7.ets.org) |
| 2021-09-21 22:07:05 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 22:07:10 +0200 | acidjnk | (~acidjnk@p200300d0c703cb44319f4c33bc64626e.dip0.t-ipconnect.de) |
| 2021-09-21 22:07:17 +0200 | xff0x | (~xff0x@2001:1a81:53a2:cb00:c07c:d089:8b2f:814c) (Ping timeout: 264 seconds) |
| 2021-09-21 22:07:39 +0200 | xff0x | (~xff0x@2001:1a81:53a2:cb00:fe64:bcbc:d8a9:c1f9) |
| 2021-09-21 22:07:41 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-21 22:10:49 +0200 | pavonia | (~user@user/siracusa) |
| 2021-09-21 22:12:17 +0200 | <TDANG> | hi everybody |
| 2021-09-21 22:12:37 +0200 | <TDANG> | I don't understand the : symbol |
| 2021-09-21 22:12:44 +0200 | <TDANG> | (single colon) |
| 2021-09-21 22:12:54 +0200 | <c_wraith> | What resources have you used for learning the language? |
| 2021-09-21 22:13:21 +0200 | <TDANG> | http://learnyouahaskell.com/ |
| 2021-09-21 22:14:58 +0200 | <c_wraith> | It's covered in the "intro to lists" section. Did you get to that part? |
| 2021-09-21 22:16:54 +0200 | <TDANG> | great, I found it. |
| 2021-09-21 22:17:08 +0200 | <c_wraith> | (If you did and things don't make sense, that's fine. I'm just trying to get a baseline of what you're looking for) |
| 2021-09-21 22:17:13 +0200 | <TDANG> | I'll go with it. Thanks ;-) |
| 2021-09-21 22:17:35 +0200 | jstolarek | (~jstolarek@erx128.neoplus.adsl.tpnet.pl) (Ping timeout: 252 seconds) |
| 2021-09-21 22:19:45 +0200 | TDANG_ | (~TDANG@cpe-107-15-144-45.nc.res.rr.com) |
| 2021-09-21 22:21:21 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 22:21:41 +0200 | TDANG | (~TDANG@inet-177-7.ets.org) (Ping timeout: 264 seconds) |
| 2021-09-21 22:21:58 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-21 22:21:59 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-21 22:21:59 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-21 22:25:17 +0200 | michalz | (~michalz@185.246.204.33) (Remote host closed the connection) |
| 2021-09-21 22:26:50 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 265 seconds) |
| 2021-09-21 22:27:59 +0200 | Pickchea | (~private@user/pickchea) |
| 2021-09-21 22:33:41 +0200 | Izem | (~user@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) (Ping timeout: 264 seconds) |
| 2021-09-21 22:33:51 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-21 22:34:16 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-50.elisa-laajakaista.fi) |
| 2021-09-21 22:39:10 +0200 | Cajun | (~Cajun@user/cajun) |
| 2021-09-21 22:39:37 +0200 | nschoe | (~quassel@2a01:e0a:8e:a190:1aae:e766:24c4:a2ba) |
| 2021-09-21 22:40:52 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-21 22:41:05 +0200 | ystael | (~ystael@user/ystael) (Read error: Connection reset by peer) |
| 2021-09-21 22:43:43 +0200 | rond_ | (~rond_@2a02:a31a:a23c:f480:2fd7:e087:5546:a438) (Quit: Client closed) |
| 2021-09-21 22:47:11 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 22:47:24 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 22:48:08 +0200 | ystael | (~ystael@user/ystael) |
| 2021-09-21 22:48:31 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2021-09-21 22:50:54 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 260 seconds) |
| 2021-09-21 22:52:37 +0200 | <monochrom> | Oh hey, "newtype P m a = MkP{unP :: String -> m (String, a)}". If m is an instance of MonadPlus and Alternative, then P m is a parser monad! Typically m = [] or Maybe or Either X. |
| 2021-09-21 22:53:21 +0200 | <awpr> | > :i ST |
| 2021-09-21 22:53:23 +0200 | <lambdabot> | <hint>:1:1: error: parse error on input ‘:’ |
| 2021-09-21 22:53:47 +0200 | <monochrom> | Sacrilegeous idea: Let me inflict this much generality on my students next time >:) |
| 2021-09-21 22:53:55 +0200 | <awpr> | ah, not MonadPlus |
| 2021-09-21 22:54:19 +0200 | <monochrom> | Heh, IO actually has a chance >:) |
| 2021-09-21 22:54:26 +0200 | <awpr> | oh duh, I meant STM, but that's also not MonadPlus |
| 2021-09-21 22:54:35 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Read error: Connection reset by peer) |
| 2021-09-21 22:55:01 +0200 | <awpr> | or... it is, but my ghci doesn't know it |
| 2021-09-21 22:55:25 +0200 | <monochrom> | I suppose I don't need MonadPlus. I just need Monad and Alternative. |
| 2021-09-21 22:55:31 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2021-09-21 22:55:32 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-21 22:55:42 +0200 | <awpr> | so that would retry a transaction until the parse succeeded? :D |
| 2021-09-21 22:55:43 +0200 | <monochrom> | Oh heh yeah you need to import more modules, or use :info! |
| 2021-09-21 22:56:05 +0200 | <awpr> | oh, no, it would avoid retrying |
| 2021-09-21 22:56:08 +0200 | <monochrom> | Haha questionable use cases, but the math works out! |
| 2021-09-21 22:57:31 +0200 | juhp | (~juhp@128.106.188.220) (Quit: juhp) |
| 2021-09-21 22:57:45 +0200 | juhp | (~juhp@128.106.188.220) |
| 2021-09-21 22:58:54 +0200 | <awpr> | now I'm picturing a compiler that just deadlocks until you update the file with correct input |
| 2021-09-21 22:59:57 +0200 | <monochrom> | Heh |
| 2021-09-21 23:02:47 +0200 | hiepph[m] | (~hiepphmat@2001:470:69fc:105::e3a8) (Ping timeout: 240 seconds) |
| 2021-09-21 23:03:34 +0200 | Jon | (jon@dow.land) (Quit: ZNC - http://znc.in) |
| 2021-09-21 23:03:46 +0200 | hiepph[m] | (~hiepphmat@2001:470:69fc:105::e3a8) |
| 2021-09-21 23:04:10 +0200 | Jon | (jon@dow.land) |
| 2021-09-21 23:04:20 +0200 | wonko | (~wjc@62.115.229.50) (Ping timeout: 252 seconds) |
| 2021-09-21 23:05:03 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-21 23:06:00 +0200 | Izem | (~user@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) |
| 2021-09-21 23:06:21 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-21 23:06:50 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2021-09-21 23:06:51 +0200 | Izem | (~user@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) () |
| 2021-09-21 23:07:47 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2021-09-21 23:08:06 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2021-09-21 23:08:11 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) (Ping timeout: 252 seconds) |
| 2021-09-21 23:08:40 +0200 | azeem | (~azeem@2a00:801:3c7:f4f5:1ae6:c0ab:f962:792a) |
| 2021-09-21 23:09:57 +0200 | Nosrep | (~archbox@user/nosrep) |
| 2021-09-21 23:10:43 +0200 | favonia | (~favonia@user/favonia) |
| 2021-09-21 23:12:50 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-21 23:13:42 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-09-21 23:14:06 +0200 | MQ-17J | (~MQ-17J@8.21.10.6) |
| 2021-09-21 23:19:01 +0200 | Everything | (~Everythin@37.115.210.35) (Quit: leaving) |
| 2021-09-21 23:20:42 +0200 | maroloccio | (~marolocci@93-142-92-177.adsl.net.t-com.hr) |
| 2021-09-21 23:23:24 +0200 | <monochrom> | > let a \~ b = a-b in 5 \~ 3 |
| 2021-09-21 23:23:25 +0200 | <lambdabot> | 2 |
| 2021-09-21 23:24:10 +0200 | <monochrom> | This means "\~(a,b) -> (b,a)" is a parse error, the computer doesn't see it as "lambda, lazy pattern". |
| 2021-09-21 23:24:23 +0200 | jespada | (~jespada@2803:9800:9842:7a62:edd5:5e74:3ec2:1b19) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-09-21 23:24:28 +0200 | <monochrom> | Hrm does Haskell accept zero-width space? >:) |
| 2021-09-21 23:24:44 +0200 | <geekosaur> | I thought someone tried that the other day and it didn't? |
| 2021-09-21 23:25:10 +0200 | <hpc> | > (\(~(a,b)) -> a) (1, 2) |
| 2021-09-21 23:25:12 +0200 | <lambdabot> | 1 |
| 2021-09-21 23:25:29 +0200 | <hpc> | the lisp solution |
| 2021-09-21 23:25:32 +0200 | <hpc> | when in doubt, add parens |
| 2021-09-21 23:26:26 +0200 | jespada | (~jespada@2803:9800:9842:7a62:4d47:2975:7b31:a447) |
| 2021-09-21 23:26:26 +0200 | <monochrom> | Oh I guess "U+FEFF ZERO WIDTH NO-BREAK SPACE" is aka byte-order marker. |
| 2021-09-21 23:26:49 +0200 | <awpr> | ohhh that's clever, I hate it |
| 2021-09-21 23:27:15 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 265 seconds) |
| 2021-09-21 23:27:25 +0200 | <awpr> | if some software isn't aware of BOMs, it harmlessly decays into a zero-width invisible character at the start of the document |
| 2021-09-21 23:27:56 +0200 | <monochrom> | Unless it's cassava, which is totally thrown off by that. |
| 2021-09-21 23:29:30 +0200 | <monochrom> | The tension here is that a lot of CSV-producing software honours the Windows convention of: 1. UTF-8 (that's good), 2. CRLF (that's fine, the CSV standard prescribe it anyway), 3. BOM (ugh). |
| 2021-09-21 23:29:31 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-09-21 23:29:46 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2021-09-21 23:29:55 +0200 | <geekosaur> | the problem with BOM is it's not UTF8 |
| 2021-09-21 23:30:22 +0200 | <geekosaur> | (as windows uses it, at least) |
| 2021-09-21 23:30:29 +0200 | <awpr> | wait do they not use the UTF-8 encoding of that character? |
| 2021-09-21 23:30:35 +0200 | flouflou | (~flouflou@modemcable032.110-177-173.mc.videotron.ca) (Quit: WeeChat 3.2) |
| 2021-09-21 23:30:40 +0200 | <geekosaur> | nope |
| 2021-09-21 23:30:48 +0200 | <geekosaur> | it's UTF16 |
| 2021-09-21 23:30:55 +0200 | <awpr> | just throw a singular completely irrelevant UCS-2 thing at the start of a UTF-8 file? |
| 2021-09-21 23:31:18 +0200 | <geekosaur> | windows was at the time trying to be sorta kinda utf16 |
| 2021-09-21 23:31:39 +0200 | <geekosaur> | then went utf8 later but kept the same BONM it had been using |
| 2021-09-21 23:31:53 +0200 | <awpr> | I can't even fathom |
| 2021-09-21 23:32:13 +0200 | <hpc> | the codepoint is still valid, it's just not useful because there aren't multiple ways to write utf8 |
| 2021-09-21 23:32:21 +0200 | <hpc> | so in that sense they're technically fine |
| 2021-09-21 23:32:21 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-21 23:32:25 +0200 | <monochrom> | They use the UTF-8 encoding of that character for UTF-8 files. Yes. |
| 2021-09-21 23:32:26 +0200 | <cdsmith> | Is there a way for a Haskell process to find the RTS args that were passed to it? They are removed from the normal System.Environment.getArgs. |
| 2021-09-21 23:32:36 +0200 | <awpr> | monochrom: oh, okay. seems alright then |
| 2021-09-21 23:32:40 +0200 | <awpr> | if unnecessary |
| 2021-09-21 23:32:47 +0200 | <glguy> | cdsmith: they are removed from getArgs |
| 2021-09-21 23:32:53 +0200 | <monochrom> | They then use the UTF-16?E of the character for UTF-16?E files, correspondinging. |
| 2021-09-21 23:32:53 +0200 | <geekosaur> | oh, they do now? |
| 2021-09-21 23:33:05 +0200 | pbrisbin | (~patrick@pool-173-49-147-250.phlapa.fios.verizon.net) (Ping timeout: 264 seconds) |
| 2021-09-21 23:33:06 +0200 | <geekosaur> | at one point they weren't |
| 2021-09-21 23:33:13 +0200 | <geekosaur> | which was really annoying |
| 2021-09-21 23:33:33 +0200 | <monochrom> | They have always done, as far as I have worked with CSV files I have received since several years ago. |
| 2021-09-21 23:34:20 +0200 | <monochrom> | My own code does a BL.stripPrefix (BL.pack "\xef\xbb\xbf") bytes, I have never need to strip "\xfe\xff" or something. |
| 2021-09-21 23:34:47 +0200 | <monochrom> | Ah OK must be way before my time. |
| 2021-09-21 23:34:48 +0200 | <cdsmith> | glguy: Yes, I know. Was hoping there's some way to get them anyway. |
| 2021-09-21 23:34:53 +0200 | Gurkenglas | (~Gurkengla@dslb-002-207-014-195.002.207.pools.vodafone-ip.de) (Ping timeout: 264 seconds) |
| 2021-09-21 23:35:21 +0200 | chomwitt | (~chomwitt@2a02:587:dc15:500:12c3:7bff:fe6d:d374) (Read error: Connection reset by peer) |
| 2021-09-21 23:35:29 +0200 | aliosablack | (~chomwitt@2a02:587:dc15:500:12c3:7bff:fe6d:d374) |
| 2021-09-21 23:35:36 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-21 23:35:54 +0200 | <monochrom> | Does GHC.Environment.getFullArgs help? |
| 2021-09-21 23:36:25 +0200 | <glguy> | cdsmith: I think you'll need to start digging in something like this: https://hackage.haskell.org/package/base-4.15.0.0/docs/src/GHC-RTS-Flags.html#getRTSFlags |
| 2021-09-21 23:38:28 +0200 | nschoe | (~quassel@2a01:e0a:8e:a190:1aae:e766:24c4:a2ba) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2021-09-21 23:39:01 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-21 23:41:45 +0200 | shachaf | (~shachaf@user/shachaf) (Ping timeout: 265 seconds) |
| 2021-09-21 23:42:22 +0200 | shachaf | (~shachaf@user/shachaf) |
| 2021-09-21 23:42:26 +0200 | aliosablack | (~chomwitt@2a02:587:dc15:500:12c3:7bff:fe6d:d374) (Ping timeout: 246 seconds) |
| 2021-09-21 23:42:39 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-21 23:43:12 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2021-09-21 23:43:53 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-21 23:46:36 +0200 | Lycurgus | (~juan@98.4.112.204) |
| 2021-09-21 23:46:44 +0200 | <cdsmith> | glguy: Hmm, getting that back into String form looks challenging. C FFI might be a better bet at that point. :( |
| 2021-09-21 23:48:05 +0200 | <cdsmith> | Well, that's what I needed to know. Thank you. I think I need to find a different way. |
| 2021-09-21 23:48:09 +0200 | <geekosaur> | did you see monochrom's suggestion |
| 2021-09-21 23:48:11 +0200 | <geekosaur> | ? |
| 2021-09-21 23:48:31 +0200 | <cdsmith> | Oh, no! |
| 2021-09-21 23:48:31 +0200 | <cdsmith> | I'll look |
| 2021-09-21 23:49:00 +0200 | <cdsmith> | Perfect. Thanks monochrom |
| 2021-09-21 23:53:53 +0200 | <glguy> | To get just the RTS arguments: https://gist.github.com/glguy/7a5ae553f463aa7d2c7e786180b9d085 <_< |
| 2021-09-21 23:54:44 +0200 | <monochrom> | could be worse :) |
| 2021-09-21 23:54:46 +0200 | <ldlework> | glguy: do you use opengl with haskell |
| 2021-09-21 23:55:30 +0200 | <geekosaur> | actually, strictly speaking both of those only get RTS options from the command line, not $GHCRTS or compiled-in rtsopts |
| 2021-09-21 23:56:00 +0200 | <ldlework> | oh "good luck, guy" maybe, nm |
| 2021-09-21 23:56:31 +0200 | <glguy> | I think I have done some OpenGL from Haskell, but very little. |
| 2021-09-21 23:56:39 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Remote host closed the connection) |
| 2021-09-21 23:58:34 +0200 | mousey | (~sky@gateway/tor-sasl/mousey) (Remote host closed the connection) |
| 2021-09-21 23:58:55 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-21 23:59:05 +0200 | Arathorn | (~arathorn@2001:470:69fc:105::1f) |
| 2021-09-21 23:59:29 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 264 seconds) |
