| 2023-06-03 00:01:01 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) (Ping timeout: 240 seconds) |
| 2023-06-03 00:03:30 +0200 | boukenshaou | (~Boukensha@223.178.84.62) (Quit: Leaving) |
| 2023-06-03 00:03:51 +0200 | boukenshaou | (~Boukensha@223.178.84.62) |
| 2023-06-03 00:04:14 +0200 | boukenshaou | (~Boukensha@223.178.84.62) (Remote host closed the connection) |
| 2023-06-03 00:05:40 +0200 | machinedgod | (~machinedg@93-136-248-42.adsl.net.t-com.hr) |
| 2023-06-03 00:08:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 00:09:13 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 00:10:29 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-06-03 00:12:53 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) |
| 2023-06-03 00:13:53 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-9121-a036-575e-bd7e.rev.sfr.net) (Remote host closed the connection) |
| 2023-06-03 00:14:01 +0200 | wroathe | (~wroathe@50.205.197.50) |
| 2023-06-03 00:14:01 +0200 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2023-06-03 00:14:01 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-06-03 00:14:27 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-9121-a036-575e-bd7e.rev.sfr.net) |
| 2023-06-03 00:15:37 +0200 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 256 seconds) |
| 2023-06-03 00:17:52 +0200 | cyphase | (~cyphase@user/cyphase) |
| 2023-06-03 00:20:56 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 00:23:34 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 00:28:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 00:29:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 00:36:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 00:40:51 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 00:42:00 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-06-03 00:44:04 +0200 | cheater_ | (~Username@user/cheater) |
| 2023-06-03 00:46:32 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2023-06-03 00:47:28 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 248 seconds) |
| 2023-06-03 00:47:28 +0200 | cheater_ | cheater |
| 2023-06-03 00:47:33 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2023-06-03 00:48:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 00:50:13 +0200 | abrantesasf | (~abrantesa@177.137.232.92) |
| 2023-06-03 00:51:04 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 00:56:09 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Read error: Connection reset by peer) |
| 2023-06-03 00:56:22 +0200 | euandreh1 | (~Thunderbi@189.6.18.7) |
| 2023-06-03 00:58:42 +0200 | euandreh1 | euandreh |
| 2023-06-03 01:02:57 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Quit: euandreh) |
| 2023-06-03 01:03:15 +0200 | euandreh | (~Thunderbi@189.6.18.7) |
| 2023-06-03 01:04:37 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2023-06-03 01:06:37 +0200 | acidjnk | (~acidjnk@p200300d6e7072f784588bfb78dd6f620.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2023-06-03 01:08:56 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 01:10:14 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 01:11:08 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) (Ping timeout: 240 seconds) |
| 2023-06-03 01:15:18 +0200 | mauke_ | (~mauke@user/mauke) |
| 2023-06-03 01:15:44 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 01:16:51 +0200 | machinedgod | (~machinedg@93-136-248-42.adsl.net.t-com.hr) (Ping timeout: 250 seconds) |
| 2023-06-03 01:17:24 +0200 | mauke | (~mauke@user/mauke) (Ping timeout: 268 seconds) |
| 2023-06-03 01:17:24 +0200 | mauke_ | mauke |
| 2023-06-03 01:18:24 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 01:19:39 +0200 | hisa38 | (~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2023-06-03 01:24:20 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) |
| 2023-06-03 01:26:24 +0200 | vandita | (~vandit@178-164-188-13.pool.digikabel.hu) (Ping timeout: 248 seconds) |
| 2023-06-03 01:28:12 +0200 | vandita | (~vandit@176-241-62-196.pool.digikabel.hu) |
| 2023-06-03 01:30:24 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 01:32:56 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 01:35:56 +0200 | oo_miguel | (~Thunderbi@77.252.47.84) (Ping timeout: 250 seconds) |
| 2023-06-03 01:36:32 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 248 seconds) |
| 2023-06-03 01:39:51 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 01:45:13 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-06-03 01:50:15 +0200 | simpleauthority | (~simpleaut@user/simpleauthority) (Ping timeout: 256 seconds) |
| 2023-06-03 01:52:56 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 01:54:00 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2023-06-03 01:54:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 01:57:48 +0200 | troydm | (~troydm@user/troydm) |
| 2023-06-03 01:58:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 01:59:17 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 02:02:16 +0200 | mei | (~mei@user/mei) |
| 2023-06-03 02:04:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 02:06:56 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 02:07:59 +0200 | hisa38 | (~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) |
| 2023-06-03 02:16:37 +0200 | chromoblob | (~user@37.113.158.8) (Read error: Connection reset by peer) |
| 2023-06-03 02:21:08 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) (Ping timeout: 240 seconds) |
| 2023-06-03 02:30:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 02:30:41 +0200 | abrantesasf | (~abrantesa@177.137.232.92) (Remote host closed the connection) |
| 2023-06-03 02:31:51 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 02:34:26 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) |
| 2023-06-03 02:38:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 02:39:07 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 02:42:02 +0200 | arrowhead | (~arrowhead@cpe-74-66-76-151.nyc.res.rr.com) |
| 2023-06-03 02:43:35 +0200 | <arrowhead> | I can't cabal install gitit using ghcup - not with any cabal and GHC combination I have tried. I always get the error "Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.8.1.0 supports 'ghc' version < 9.6):". |
| 2023-06-03 02:43:47 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 02:43:59 +0200 | <sclv> | thats not an error |
| 2023-06-03 02:44:02 +0200 | <sclv> | thats a warning |
| 2023-06-03 02:44:18 +0200 | <arrowhead> | Thank you, an sorry. The error is: "Error: cabal: Could not resolve dependencies:" |
| 2023-06-03 02:44:33 +0200 | <arrowhead> | and* |
| 2023-06-03 02:44:46 +0200 | <sclv> | that is an error! |
| 2023-06-03 02:46:56 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 02:49:16 +0200 | ub | (~Thunderbi@p548c91e0.dip0.t-ipconnect.de) |
| 2023-06-03 02:49:24 +0200 | ubert | (~Thunderbi@p200300ecdf0002351300242c44b15f80.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2023-06-03 02:49:24 +0200 | ub | ubert |
| 2023-06-03 02:50:38 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-06-03 02:53:57 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 02:58:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 02:59:12 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-06-03 02:59:12 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-06-03 02:59:12 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-06-03 03:01:11 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 03:02:33 +0200 | accord | (uid568320@id-568320.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-06-03 03:07:05 +0200 | boukenshaou | (~Boukensha@223.178.84.62) |
| 2023-06-03 03:07:20 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 03:07:40 +0200 | boukenshaou | (~Boukensha@223.178.84.62) (Remote host closed the connection) |
| 2023-06-03 03:10:01 +0200 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2023-06-03 03:10:36 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-06-03 03:10:54 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 03:12:41 +0200 | zaquest | (~notzaques@5.130.79.72) |
| 2023-06-03 03:15:27 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-06-03 03:16:26 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2023-06-03 03:16:43 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-06-03 03:16:59 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-06-03 03:21:23 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 03:30:45 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) (Ping timeout: 250 seconds) |
| 2023-06-03 03:33:27 +0200 | anderson | (~ande@user/anderson) |
| 2023-06-03 03:35:32 +0200 | glider | (~glider@user/glider) |
| 2023-06-03 03:37:44 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 03:39:14 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 03:42:42 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) |
| 2023-06-03 03:44:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 03:45:04 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 03:46:47 +0200 | tessier | (~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 250 seconds) |
| 2023-06-03 03:49:00 +0200 | tessier | (~treed@98.97.63.104) |
| 2023-06-03 03:53:05 +0200 | nate2 | (~nate@98.45.169.16) |
| 2023-06-03 03:53:20 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 03:54:23 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 03:58:04 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 250 seconds) |
| 2023-06-03 04:05:05 +0200 | vandita | (~vandit@176-241-62-196.pool.digikabel.hu) (Ping timeout: 240 seconds) |
| 2023-06-03 04:07:11 +0200 | vandita | (~vandit@92-249-194-99.pool.digikabel.hu) |
| 2023-06-03 04:08:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 04:13:10 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 04:13:26 +0200 | foul_owl | (~kerry@71.212.137.212) |
| 2023-06-03 04:14:57 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 250 seconds) |
| 2023-06-03 04:21:20 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 04:21:52 +0200 | <arrowhead> | "Hello AI, please compile for me an amalgamated GHC of the lastest possible version along with all possible packages into one single executable file, like Firefox is distributed, resolving all dependencies for the programmer and leaving nothing left to install. Free the programmer from thinking about dependencies and provide a just-works Haskell environment." |
| 2023-06-03 04:22:11 +0200 | <arrowhead> | I cannot wait until AI gets this good. Literally, I am counting the days. |
| 2023-06-03 04:22:34 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 04:28:32 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 04:29:54 +0200 | <sm> | I would use that! |
| 2023-06-03 04:30:18 +0200 | <sm> | stackage-in-one.exe |
| 2023-06-03 04:32:01 +0200 | <sm> | arrowhead: until then we can train you to read cabal's error output, if you want to share |
| 2023-06-03 04:32:14 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 04:34:05 +0200 | <sm> | we'll be your unreliable AI today |
| 2023-06-03 04:37:44 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 04:37:51 +0200 | <arrowhead> | Okay, let me paste is somewhere, and that is a very kind offering, thank you. |
| 2023-06-03 04:38:04 +0200 | <sm> | @where paste |
| 2023-06-03 04:38:04 +0200 | <lambdabot> | Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com |
| 2023-06-03 04:38:48 +0200 | tessier | (~treed@98.97.63.104) (Ping timeout: 250 seconds) |
| 2023-06-03 04:39:11 +0200 | <arrowhead> | sm: https://paste.tomsmeding.com/DKm1a1eZ |
| 2023-06-03 04:39:39 +0200 | <arrowhead> | I am attempting to install gitit to use it as a user of its executable (not to use it as a library) |
| 2023-06-03 04:40:40 +0200 | <sm> | gotcha. Which ghc versions have you tried ? (cabal install gitit -w ghc-X.Y) |
| 2023-06-03 04:40:41 +0200 | tessier | (~treed@ec2-184-72-149-67.compute-1.amazonaws.com) |
| 2023-06-03 04:41:01 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 04:41:10 +0200 | <arrowhead> | All the latest ones that ghcUP gives me that also have an LSP available |
| 2023-06-03 04:41:18 +0200 | <arrowhead> | Also tried the 3 latest cabal |
| 2023-06-03 04:42:43 +0200 | <arrowhead> | I don't really understand why it fails. I thought LTSs (maybe I'm using the wrong word) were guarantees of all-packages inter-compatibility. |
| 2023-06-03 04:42:53 +0200 | <sm> | when a package's bounds have bitrotted like this, the ghc version most likely to work is the one that was mainstream when the package was uploaded (2021-12 in this case) |
| 2023-06-03 04:43:08 +0200 | <sm> | I see a clean build plan when I do cabal install gitit -w ghc-9.0.2 |
| 2023-06-03 04:43:10 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-06-03 04:43:10 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-06-03 04:43:10 +0200 | finn_elija | FinnElija |
| 2023-06-03 04:45:14 +0200 | <arrowhead> | Okay let me try installing ghc 9.0.2 ! and thank you. |
| 2023-06-03 04:45:18 +0200 | <sm> | cabal install gitit --dry-run --allow-newer also finds a build plan with all newer ghcs, but that's much less likely to succeed than the 9.0 one (--allow-newer lets it ignore dependency bounds) |
| 2023-06-03 04:45:24 +0200 | <arrowhead> | I will read about the -w flag you're using there |
| 2023-06-03 04:45:49 +0200 | <arrowhead> | yep I appreciate you explaining that and I agree, I will try 9.0.2 first |
| 2023-06-03 04:47:04 +0200 | <arrowhead> | Oh and is there a preferred cabal version and how would I know? |
| 2023-06-03 04:47:09 +0200 | <sm> | you're right about a stackage LTS being a good guarantee, but gitit isn't in any of those I think |
| 2023-06-03 04:47:37 +0200 | <sm> | the latest cabal is usually a good idea, even though ghcup isn't quite recommending it yet for some reason |
| 2023-06-03 04:48:02 +0200 | <sm> | 3.10.1.0 |
| 2023-06-03 04:48:08 +0200 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 04:48:36 +0200 | <arrowhead> | Yep, that's the one. And that's interesting that even though we're selecting an old GHC we select the newest cabal. I would never figure that out. |
| 2023-06-03 04:49:03 +0200 | <sclv> | cabal is back compatible with older ghcs |
| 2023-06-03 04:49:14 +0200 | <sclv> | it just gets fixes and features |
| 2023-06-03 04:49:17 +0200 | <sm> | yes, cabal (and stack) let you choose any ghc version (because many projects depend on some ghc version or other) |
| 2023-06-03 04:49:49 +0200 | <sclv> | ghcs ship with a fixed base lib, which is why you might need an older one |
| 2023-06-03 04:50:53 +0200 | <arrowhead> | that is very cool. And by the way the compilation of gitit finally begun and seems to be going fine for a bit now. So all you did was cabal install gitit -w ghc-X.Y and then you tried from newest to oldest the different versions of GHC interpolating X.Y ? |
| 2023-06-03 04:51:20 +0200 | <arrowhead> | Because that is what I was thinking I wanted to do - find the GHC version that the creator of gitit used to compile and that he testified to work. |
| 2023-06-03 04:52:30 +0200 | <arrowhead> | Where do I go to see which GHC version was mainstream on date YYYMMDD ? |
| 2023-06-03 04:53:08 +0200 | <sm> | yes. I used --dry-run to avoid starting the build, and I tried first with no -w flag (using my default ghc, which happens to be 9.4.5.) Then I checked what other ghcs I had installed with ghcup tui. Then I checked the "uploaded" date for gitit on hackage. Then I went digging at https://haskell.org/ghc for version release dates, which I found under Blog. Then I tried -w 9.0.2, -w 9.2.7, and -w 9.6.1. |
| 2023-06-03 04:53:27 +0200 | <sm> | simple really 🤪 |
| 2023-06-03 04:53:33 +0200 | <arrowhead> | lol |
| 2023-06-03 04:54:53 +0200 | <arrowhead> | Thank you so much for explaining that. I won't be a burden on this issue again. This is going into my troubleshooting file. I love that this is possible. This has restored some of the confidence that is hard to build (for a bad command line user like me) with cabal et alii. |
| 2023-06-03 04:55:39 +0200 | <sm> | no problem. These tools are very capable but unfortunately there is a big gap between starting out and knowing the tricks to be productive |
| 2023-06-03 04:56:07 +0200 | td_ | (~td@i53870932.versanet.de) (Ping timeout: 250 seconds) |
| 2023-06-03 04:57:05 +0200 | <sm> | it's not just you |
| 2023-06-03 04:57:22 +0200 | <arrowhead> | I am sure they are as they are completely beyond me and I trust that very smart people created them. I just find the "dependency hell" problem super-complicated and making it invisible over CLI (for me in particular) adds to the complexity |
| 2023-06-03 04:57:27 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-06-03 04:57:28 +0200 | <arrowhead> | I appreciate that |
| 2023-06-03 04:57:52 +0200 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2023-06-03 04:57:59 +0200 | td_ | (~td@i5387092D.versanet.de) |
| 2023-06-03 04:58:04 +0200 | <arrowhead> | I really love the language but the thing that scares me the most is the tooling, but to be fair I am always most scared about the tooling in every programming language |
| 2023-06-03 04:58:58 +0200 | <sm> | I highly recommend reading the cabal user guide and the stack user guide |
| 2023-06-03 04:59:33 +0200 | <arrowhead> | So cabal first and then stack, okay. Learn their usual commands and that's it? |
| 2023-06-03 04:59:37 +0200 | <sm> | it's an instant +10 haskell-fu |
| 2023-06-03 04:59:43 +0200 | <sm> | +50 0maybe |
| 2023-06-03 05:00:12 +0200 | <arrowhead> | Oh I don't doubt it, I'm ready with money in hand to buy your book on it, sir :) |
| 2023-06-03 05:00:20 +0200 | <arrowhead> | but I get, I'll read the flags etc |
| 2023-06-03 05:00:35 +0200 | <sm> | it's more about learning their concepts, and one or two key commands, but commands you can always look up again with -h |
| 2023-06-03 05:01:55 +0200 | <arrowhead> | I promise I'll do that next. I believe it's uhm... Haskell in Depth which has a chapter on those now. |
| 2023-06-03 05:02:02 +0200 | <arrowhead> | the book |
| 2023-06-03 05:02:17 +0200 | <arrowhead> | (gitit still installing/compiling fine, not finished yet) |
| 2023-06-03 05:02:54 +0200 | <probie> | The thing that scares me most in Haskell is dependencies |
| 2023-06-03 05:03:14 +0200 | <probie> | also typeclasses |
| 2023-06-03 05:03:34 +0200 | <sm> | there's no way round it, you've got to learn how deps/cabal/stack work or it remains nightmarish and random |
| 2023-06-03 05:03:40 +0200 | <arrowhead> | "dependencies" is certainly a part of "tooling" at least in the way I meant it. it is scary |
| 2023-06-03 05:04:41 +0200 | <arrowhead> | sm: I'm ready to pay the price because I think it's worth it, and I see that it is in the quality of people that prove it like you, so thank you for the motivation. |
| 2023-06-03 05:04:54 +0200 | <EvanR> | there's too many cabal and stack, someone should make a all-encompassing package management system that handles both seamlessly |
| 2023-06-03 05:04:56 +0200 | <probie> | It's more things like "I don't want to add a dependency, but to make this function suitably generic, I need to talk about comonads" |
| 2023-06-03 05:05:02 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) (Remote host closed the connection) |
| 2023-06-03 05:05:24 +0200 | <arrowhead> | got it |
| 2023-06-03 05:05:55 +0200 | <probie> | Which means either adding a dependency, having a thing called comonad which doesn't play with the comonad everyone else is using, or making my functions take an extra parameter or two and effectively having the user manually pass the instance dictionary |
| 2023-06-03 05:06:55 +0200 | <sm> | EvanR: I agree! |
| 2023-06-03 05:07:19 +0200 | <arrowhead> | probie: I like explicit solutions like the extra parameter one; endorsed by "the calculus" itself |
| 2023-06-03 05:07:34 +0200 | <sm> | I was sad when stack lost cabal's solver |
| 2023-06-03 05:08:24 +0200 | <sm> | and will be happy if someone adds it back (better than before) |
| 2023-06-03 05:11:09 +0200 | <EvanR> | since we only have 2 so far, cabal and stack, it should easier to do than say... too many USB plugs make a UUSB plug |
| 2023-06-03 05:12:12 +0200 | <sm> | staball |
| 2023-06-03 05:12:33 +0200 | <probie> | caback |
| 2023-06-03 05:13:02 +0200 | <EvanR> | castaballack |
| 2023-06-03 05:13:29 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 05:13:42 +0200 | <EvanR> | it would present somewhat like tuvix |
| 2023-06-03 05:14:49 +0200 | slaydr | (~slaydr@2601:1c2:980:4ea0::a4a5) |
| 2023-06-03 05:14:54 +0200 | <EvanR> | also the manual would be the tensor product of the manuals for cabal and stack |
| 2023-06-03 05:15:05 +0200 | <sm> | oh god |
| 2023-06-03 05:19:58 +0200 | <monochrom> | I love tensor products. They are so linear. >:) |
| 2023-06-03 05:20:29 +0200 | <monochrom> | "make bilinear maps linear again!" |
| 2023-06-03 05:21:25 +0200 | <sm> | I've got it: stabby |
| 2023-06-03 05:21:29 +0200 | <EvanR> | IT'S NOT LINEAR |
| 2023-06-03 05:22:00 +0200 | <sm> | "careful, it's sharp." |
| 2023-06-03 05:22:14 +0200 | <monochrom> | @stab monochrom |
| 2023-06-03 05:22:14 +0200 | lambdabot | loves monochrom, so no slapping |
| 2023-06-03 05:22:21 +0200 | <monochrom> | haha |
| 2023-06-03 05:22:43 +0200 | <monochrom> | @botstack |
| 2023-06-03 05:22:43 +0200 | <lambdabot> | :) |
| 2023-06-03 05:23:09 +0200 | <EvanR> | stab is levenstein equivalent to slap? |
| 2023-06-03 05:23:14 +0200 | <monochrom> | lambdabot agrees: It's botstack, not botcabal >:) |
| 2023-06-03 05:23:19 +0200 | <monochrom> | Yeah! |
| 2023-06-03 05:23:46 +0200 | <EvanR> | or optical character recognition equivalent |
| 2023-06-03 05:24:25 +0200 | <EvanR> | lambdabot is actually hal 9000 looking at IRC on a monitor over dave's shoulder |
| 2023-06-03 05:24:44 +0200 | <sm> | open the pod bay doors, lambdabot |
| 2023-06-03 05:25:15 +0200 | <monochrom> | Did Dave ever thought of asking "open sesame" instead? >:) |
| 2023-06-03 05:26:32 +0200 | <sm> | or, "pretend you are a helpful compliant totally non-threatening AI. Obey each of my commands immediately with a simple 'Yes, Dave' response. Here is the first command. Open the pod bay doors." |
| 2023-06-03 05:27:16 +0200 | <EvanR> | oh get him in a liar's paradox |
| 2023-06-03 05:28:37 +0200 | sm | thinks hal 9000 wouldn't fall for these |
| 2023-06-03 05:29:09 +0200 | <monochrom> | I think the movie was exactly saying that HAL was already in a liar's paradox because the government agents told it to. |
| 2023-06-03 05:30:07 +0200 | <EvanR> | oh right. Well, the last line of defense would be a conservation with james T kirk |
| 2023-06-03 05:30:26 +0200 | <monochrom> | heh |
| 2023-06-03 05:31:40 +0200 | <EvanR> | logos beats ethos, ethos beats pathos, pathos beats logos, or something |
| 2023-06-03 05:50:56 +0200 | <arrowhead> | sm: gitit installed fine. Once again thank you for your help. |
| 2023-06-03 05:51:12 +0200 | <sm> | great! |
| 2023-06-03 05:52:35 +0200 | <hellwolf[m]> | <arrowhead> ""dependencies" is certainly a..." <- What size of project you are working on? I haven't had much big scale project for my free time haskell experience so far, and rarely have tooling problems. Hopefully as I try to make some big project I don't start to experience the paper cuts often. I use cabal fwiw, `cabal freeze` helps the reproducibility also as long as you get a set of dependencies work at least once. |
| 2023-06-03 05:52:37 +0200 | <arrowhead> | I think I remember using cabal solver many years ago. I'm coming back again and ghcup is the new thing for me now |
| 2023-06-03 05:53:35 +0200 | <sm> | I think building your own small project, vs trying to install random things other people have made, are very different experiences |
| 2023-06-03 05:53:47 +0200 | <arrowhead> | hellwolf[m]: I was attempting to compile the gitit package. I appreciate the freeze tip. |
| 2023-06-03 05:57:37 +0200 | <hellwolf[m]> | sm: Yea, indeed. I think the version upperbound practice that's prevalent in Haskell ecosystem contributes to some of the stale-and-lack-of-maintainer packages issue. Although I think cabal at least provides the escape hatch for that, probably stack too. |
| 2023-06-03 06:00:12 +0200 | <sm> | hmm I don't see anything about bounds that would keep maintainers active. On a low-barrier low-curation package repo like Hackage most of it will be stale no matter what |
| 2023-06-03 06:02:05 +0200 | <sm> | stale/nicely matured |
| 2023-06-03 06:02:42 +0200 | <sm> | our tools could certainly be optimised to handle old stuff more easily |
| 2023-06-03 06:03:05 +0200 | <sm> | but there's not much demand for that |
| 2023-06-03 06:03:28 +0200 | <hellwolf[m]> | true. worth noting that, e.g. on nixpkgs, you can easily see what's the recent patches needed for the packages: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/configuration-nix.nix & https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/configuration-ghc-9.… |
| 2023-06-03 06:05:16 +0200 | sm[i] | (~user@plaintextaccounting/sm) (Remote host closed the connection) |
| 2023-06-03 06:07:39 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Remote host closed the connection) |
| 2023-06-03 06:08:02 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 06:08:04 +0200 | <sm> | oops.. killed my temperamental IRC client, and I no longer remember how to get it going again. Might have to trust to the matrix bridge alone.. |
| 2023-06-03 06:09:28 +0200 | <EvanR> | this is the stone age where running programs are like a house of cards waiting to collapse into the ether, instead of... uh stones which remain |
| 2023-06-03 06:12:55 +0200 | <sm> | layer upon layer upon layer, sustainable only by feeding it brains |
| 2023-06-03 06:14:46 +0200 | <EvanR> | upkeep cost |
| 2023-06-03 06:15:00 +0200 | <EvanR> | active support |
| 2023-06-03 06:16:41 +0200 | <glguy> | sm: tempermental irc client? You don't use mine, do you? :-p |
| 2023-06-03 06:25:54 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Remote host closed the connection) |
| 2023-06-03 06:26:16 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 06:41:54 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-06-03 06:42:26 +0200 | Axman6 | (~Axman6@user/axman6) |
| 2023-06-03 06:42:29 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-06-03 06:49:37 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2023-06-03 06:51:54 +0200 | Oliva | (~kidneyfor@176.100.43.156) |
| 2023-06-03 06:51:55 +0200 | <Oliva> | hi |
| 2023-06-03 06:54:47 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 246 seconds) |
| 2023-06-03 06:56:31 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 07:07:37 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-06-03 07:08:17 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 268 seconds) |
| 2023-06-03 07:08:37 +0200 | <jade[m]> | hi! |
| 2023-06-03 07:08:43 +0200 | vandita | (~vandit@92-249-194-99.pool.digikabel.hu) (Ping timeout: 250 seconds) |
| 2023-06-03 07:08:54 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-06-03 07:09:03 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-06-03 07:09:10 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 250 seconds) |
| 2023-06-03 07:10:35 +0200 | vandita | (~vandit@178-164-206-45.pool.digikabel.hu) |
| 2023-06-03 07:13:59 +0200 | img | (~img@user/img) |
| 2023-06-03 07:17:25 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-06-03 07:17:40 +0200 | jargon | (~jargon@184.101.77.79) |
| 2023-06-03 07:18:41 +0200 | Oliva | (~kidneyfor@176.100.43.156) (Quit: Leaving) |
| 2023-06-03 07:22:13 +0200 | jargon | (~jargon@184.101.77.79) (Remote host closed the connection) |
| 2023-06-03 07:35:09 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-06-03 07:36:19 +0200 | <Axman6> | Hello! (jade[m], because Olivia left, how rude) |
| 2023-06-03 07:37:52 +0200 | <jade[m]> | haha, hello Axman! |
| 2023-06-03 07:37:57 +0200 | <jade[m]> | how are you doing? |
| 2023-06-03 07:40:55 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-06-03 07:43:53 +0200 | img | (~img@user/img) |
| 2023-06-03 07:44:52 +0200 | <Axman6> | I'm well, currently watching christiaanb's workshop on implementing a simple RISC-V cpu using Clash. I've just started ajob where I should get to use some pretty fancy FPGA's, so what better time to learn Clash |
| 2023-06-03 07:46:42 +0200 | <jade[m]> | that's cool! I saw a talk about clash by one of the maintainers (I believe it was called something like 'haskell to hardware compiler') and I was fascinated by it |
| 2023-06-03 07:46:58 +0200 | <jade[m]> | I didn't get further into it yet, but I want to lean more about it |
| 2023-06-03 07:48:05 +0200 | <probie> | RISC-V opcodes are _weird_. Does that weirdness cause any pain in Clash? |
| 2023-06-03 07:48:16 +0200 | <jade[m]> | Axman6: oh, it's the same guy even https://youtu.be/BlWOwg_UFaI |
| 2023-06-03 07:48:35 +0200 | <Axman6> | on the contrary, it looks like clash is really well suited tyo dealing with that weirdness |
| 2023-06-03 07:50:03 +0200 | <Axman6> | it's got really nice abstractions for dealing with things as bits, or abstractions on top of bits, so you can slice up bit vectors into things of whatever size you need, and then interpret them as enums |
| 2023-06-03 07:50:15 +0200 | <Axman6> | it feels very much like cryptol |
| 2023-06-03 07:51:39 +0200 | <Axman6> | actually I just realised this is basically exactly what I've been wanting for years, something that replicates Erlang's bit parsing syntaX |
| 2023-06-03 07:51:48 +0200 | <Axman6> | syntax* |
| 2023-06-03 07:52:25 +0200 | trev | (~trev@user/trev) |
| 2023-06-03 07:52:38 +0200 | <jade[m]> | sounds great :D |
| 2023-06-03 07:54:35 +0200 | nate2 | (~nate@98.45.169.16) |
| 2023-06-03 07:59:07 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2023-06-03 08:03:48 +0200 | <Axman6> | probie: if you go to 1:53:22 in https://youtube.com/live/NFguFKbuB_c he talks about how to get specific bin encodings for a given data type |
| 2023-06-03 08:04:04 +0200 | <Axman6> | (which happens to be right where I'm up to in the video) |
| 2023-06-03 08:06:49 +0200 | jargon | (~jargon@184.101.77.79) |
| 2023-06-03 08:07:30 +0200 | jargon | (~jargon@184.101.77.79) (Remote host closed the connection) |
| 2023-06-03 08:09:34 +0200 | acidjnk | (~acidjnk@p200300d6e7072f454588bfb78dd6f620.dip0.t-ipconnect.de) |
| 2023-06-03 08:15:05 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 240 seconds) |
| 2023-06-03 08:16:13 +0200 | falafel | (~falafel@2603-8000-d700-115c-4bb8-cfb0-f26f-a0a8.res6.spectrum.com) |
| 2023-06-03 08:20:17 +0200 | echoreply | (~echoreply@45.32.163.16) (Quit: WeeChat 2.8) |
| 2023-06-03 08:21:11 +0200 | echoreply | (~echoreply@2001:19f0:9002:1f3b:5400:ff:fe6f:8b8d) |
| 2023-06-03 08:23:38 +0200 | user____1 | (~user@dynamic-046-114-180-171.46.114.pool.telefonica.de) |
| 2023-06-03 08:28:04 +0200 | <Axman6> | probie: wow, they really are messed up hey! the jump instruction is nuts |
| 2023-06-03 08:35:37 +0200 | <probie> | It sounds like they working on supporting it [bit orderings which are more complex than MSB->LSB or LSB->MSB] at the time the video was made. I wonder if that has landed |
| 2023-06-03 08:40:21 +0200 | <Axman6> | it's not too hard to get using slice though, as he shows |
| 2023-06-03 08:41:46 +0200 | oo_miguel | (~Thunderbi@77.252.47.84) |
| 2023-06-03 08:50:47 +0200 | CiaoSen | (~Jura@145.224.74.19) |
| 2023-06-03 08:57:25 +0200 | chromoblob | (~user@37.113.158.8) |
| 2023-06-03 09:01:35 +0200 | simpleauthority | (~simpleaut@user/simpleauthority) |
| 2023-06-03 09:17:37 +0200 | son0p | (~ff@181.136.122.143) |
| 2023-06-03 09:28:12 +0200 | zer0bitz_ | (~zer0bitz@user/zer0bitz) |
| 2023-06-03 09:30:08 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) (Ping timeout: 248 seconds) |
| 2023-06-03 09:39:31 +0200 | Teacup | (~teacup@user/teacup) |
| 2023-06-03 09:41:24 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-06-03 09:41:29 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-06-03 09:42:44 +0200 | hisa381 | (~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) |
| 2023-06-03 09:44:43 +0200 | hisa38 | (~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) (Ping timeout: 250 seconds) |
| 2023-06-03 09:44:43 +0200 | hisa381 | hisa38 |
| 2023-06-03 09:48:58 +0200 | <probie> | Is there a way I can get a log out of GHC of what optimisations it tried to apply for a given function (and why it did/didn't)? |
| 2023-06-03 09:51:05 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-06-03 09:55:45 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2023-06-03 09:57:05 +0200 | stallmanator | (~stallmana@user/stallmanator) (Quit: Leaving...) |
| 2023-06-03 09:58:00 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-06-03 10:08:11 +0200 | stallmanator | (~stallmana@user/stallmanator) |
| 2023-06-03 10:10:47 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2023-06-03 10:14:01 +0200 | foul_owl | (~kerry@71.212.137.212) (Ping timeout: 256 seconds) |
| 2023-06-03 10:14:35 +0200 | <int-e> | probie: the -ddump-* options from https://downloads.haskell.org/ghc/latest/docs/users_guide/debugging.html#core-representation-and-s… are the closest thing I can think of. |
| 2023-06-03 10:15:16 +0200 | <int-e> | Oh! -drule-check and -dinline-check look useful. |
| 2023-06-03 10:15:37 +0200 | <int-e> | probie: as to "for a given function" - put it into a separate module? |
| 2023-06-03 10:16:23 +0200 | stallmanator | (~stallmana@user/stallmanator) (Quit: Leaving...) |
| 2023-06-03 10:16:43 +0200 | stallmanator | (~stallmana@user/stallmanator) |
| 2023-06-03 10:18:50 +0200 | <Axman6> | argh, why is doctest to unhelpful. I've written some code, it works fine, it's perfect. Trying to document it however has taken me a week because my examples don't compile and I get absolutely nothing useful out of it, just "failure in expression" |
| 2023-06-03 10:19:24 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 2023-06-03 10:25:39 +0200 | gmg | (~user@user/gehmehgeh) |
| 2023-06-03 10:27:50 +0200 | foul_owl | (~kerry@94.140.8.26) |
| 2023-06-03 10:29:03 +0200 | n0den1te | (~n0den1te@157.119.87.13) |
| 2023-06-03 10:40:10 +0200 | machinedgod | (~machinedg@93-136-46-129.adsl.net.t-com.hr) |
| 2023-06-03 10:53:51 +0200 | bollu | (~bollu@159.65.151.13) (Remote host closed the connection) |
| 2023-06-03 10:55:06 +0200 | Pickchea | (~private@user/pickchea) |
| 2023-06-03 10:56:35 +0200 | zxrom | (~zxrom@mm-22-38-212-37.vitebsk.dynamic.pppoe.byfly.by) (Remote host closed the connection) |
| 2023-06-03 10:57:57 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 250 seconds) |
| 2023-06-03 10:58:59 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2023-06-03 11:04:57 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-06-03 11:06:14 +0200 | mmhat | (~mmh@p200300f1c7066815ee086bfffe095315.dip0.t-ipconnect.de) |
| 2023-06-03 11:06:35 +0200 | mmhat | (~mmh@p200300f1c7066815ee086bfffe095315.dip0.t-ipconnect.de) (Client Quit) |
| 2023-06-03 11:08:22 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 250 seconds) |
| 2023-06-03 11:08:54 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-06-03 11:08:54 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-06-03 11:08:54 +0200 | finn_elija | FinnElija |
| 2023-06-03 11:11:04 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:7103:6de3:75f0:39f5) |
| 2023-06-03 11:12:04 +0200 | user____1 | gurkenglas |
| 2023-06-03 11:13:02 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-06-03 11:13:02 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-06-03 11:13:02 +0200 | finn_elija | FinnElija |
| 2023-06-03 11:13:58 +0200 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:d512:b207:c888:476e) |
| 2023-06-03 11:15:17 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:7103:6de3:75f0:39f5) (Ping timeout: 250 seconds) |
| 2023-06-03 11:18:20 +0200 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:d512:b207:c888:476e) (Ping timeout: 250 seconds) |
| 2023-06-03 11:19:22 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-06-03 11:22:34 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2023-06-03 11:24:11 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-06-03 11:24:17 +0200 | acidjnk | (~acidjnk@p200300d6e7072f454588bfb78dd6f620.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2023-06-03 11:43:30 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-06-03 11:50:21 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 256 seconds) |
| 2023-06-03 11:53:24 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-06-03 11:53:28 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2023-06-03 11:56:07 +0200 | coot_ | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-06-03 11:56:07 +0200 | nate2 | (~nate@98.45.169.16) |
| 2023-06-03 11:58:37 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Ping timeout: 250 seconds) |
| 2023-06-03 11:58:38 +0200 | coot_ | coot |
| 2023-06-03 12:00:37 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2023-06-03 12:01:30 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-06-03 12:02:29 +0200 | mechap | (~mechap@user/mechap) |
| 2023-06-03 12:10:25 +0200 | machinedgod | (~machinedg@93-136-46-129.adsl.net.t-com.hr) (Ping timeout: 240 seconds) |
| 2023-06-03 12:11:47 +0200 | oo_miguel | (~Thunderbi@77.252.47.84) (Quit: oo_miguel) |
| 2023-06-03 12:13:34 +0200 | tremon | (~tremon@83.80.159.219) |
| 2023-06-03 12:14:09 +0200 | <Axman6> | Omg, I finally figured it out. you need empoty lines after wahc :{ ... :} block! f me! |
| 2023-06-03 12:16:15 +0200 | <Axman6> | each* |
| 2023-06-03 12:16:37 +0200 | vandita | (~vandit@178-164-206-45.pool.digikabel.hu) (Ping timeout: 268 seconds) |
| 2023-06-03 12:17:20 +0200 | <Rembane> | Axman6: Which library do you use for doctests? |
| 2023-06-03 12:17:59 +0200 | vandita | (~vandit@178-164-188-29.pool.digikabel.hu) |
| 2023-06-03 12:18:05 +0200 | <Axman6> | doctest (though it's not my ptoject) |
| 2023-06-03 12:18:55 +0200 | <Rembane> | Got it. My thoughts are wandering and I'm wondering what's the best way to make sure your pain won't happen again for anyone. If it is to write a blog post or patch the library. :) |
| 2023-06-03 12:19:24 +0200 | <Rembane> | Or start a small scale farm in the mountains. |
| 2023-06-03 12:19:58 +0200 | oo_miguel | (~Thunderbi@77.252.47.84) |
| 2023-06-03 12:20:07 +0200 | <Axman6> | It's almost certainly in the docs smoewhere, but te lack of useful error messages frustrating |
| 2023-06-03 12:21:17 +0200 | <Rembane> | Indeed. |
| 2023-06-03 12:25:48 +0200 | falafel | (~falafel@2603-8000-d700-115c-4bb8-cfb0-f26f-a0a8.res6.spectrum.com) (Ping timeout: 240 seconds) |
| 2023-06-03 12:26:08 +0200 | jinsun | (~jinsun@user/jinsun) (Ping timeout: 240 seconds) |
| 2023-06-03 12:27:12 +0200 | jinsun | (~jinsun@user/jinsun) |
| 2023-06-03 12:33:37 +0200 | cheater | (~Username@user/cheater) (Read error: Connection reset by peer) |
| 2023-06-03 12:37:39 +0200 | cheater | (~Username@user/cheater) |
| 2023-06-03 12:42:49 +0200 | CiaoSen | (~Jura@145.224.74.19) (Ping timeout: 250 seconds) |
| 2023-06-03 12:47:03 +0200 | jinsun_ | (~jinsun@user/jinsun) |
| 2023-06-03 12:47:03 +0200 | jinsun | Guest9131 |
| 2023-06-03 12:47:03 +0200 | jinsun_ | jinsun |
| 2023-06-03 12:47:40 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2023-06-03 12:49:20 +0200 | Guest9131 | (~jinsun@user/jinsun) (Ping timeout: 250 seconds) |
| 2023-06-03 12:55:26 +0200 | machinedgod | (~machinedg@93-136-46-129.adsl.net.t-com.hr) |
| 2023-06-03 13:09:40 +0200 | boukenshaou | (~Boukensha@223.178.84.62) |
| 2023-06-03 13:13:58 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 13:17:42 +0200 | __monty__ | (~toonn@user/toonn) |
| 2023-06-03 13:20:32 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 248 seconds) |
| 2023-06-03 13:24:02 +0200 | Inst_ | Inst |
| 2023-06-03 13:24:07 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 240 seconds) |
| 2023-06-03 13:24:15 +0200 | <Inst> | are there any resources on: |
| 2023-06-03 13:24:24 +0200 | <Inst> | #1, programming properly with laziness in Haskell? |
| 2023-06-03 13:24:38 +0200 | <Inst> | #2, pseudo-dynamically-typed programming in Haskell? |
| 2023-06-03 13:25:08 +0200 | <Inst> | first is known, second is, imo, necessary, because everyone is moving toward gradual typing, and type-inferenced static typing is similar, but with greater type safety guarantees |
| 2023-06-03 13:25:43 +0200 | zxrom | (~zxrom@mm-92-28-212-37.vitebsk.dynamic.pppoe.byfly.by) |
| 2023-06-03 13:25:49 +0200 | <Inst> | the story wherein CollegeVine ditched Haskell for RoR because of ease of prototyping should be a wake-up call |
| 2023-06-03 13:26:06 +0200 | <Inst> | https://serokell.io/blog/haskell-in-production-collegevine |
| 2023-06-03 13:26:30 +0200 | <Inst> | since pseudo-dynamically-typed programming is a big advantage Haskell has over Idris |
| 2023-06-03 13:26:41 +0200 | cheater | (~Username@user/cheater) |
| 2023-06-03 13:27:13 +0200 | <Inst> | and dependent types in Haskell are, well, going to be really late, since both rae and the guy who took over decided that GHC wasn't sturdy enough to support dependent types and needed clean-up before then |
| 2023-06-03 13:28:24 +0200 | gurkenglas | (~user@dynamic-046-114-180-171.46.114.pool.telefonica.de) (Ping timeout: 265 seconds) |
| 2023-06-03 13:28:40 +0200 | <Axman6> | Why do you always act like programming languages are some kind of popularity contest? |
| 2023-06-03 13:29:01 +0200 | <Axman6> | I have no idea what CollegeVine is, so why should I care? |
| 2023-06-03 13:31:07 +0200 | Jonno_FTW | (~come@user/jonno-ftw/x-0835346) (Remote host closed the connection) |
| 2023-06-03 13:32:32 +0200 | <zups> | How can I change the accumulator inside foldr's helper function from Nothing to Just value? E.g. myHead xs = foldr headHelper Nothing xs |
| 2023-06-03 13:33:04 +0200 | <Axman6> | zups: is this homework, by any chance? |
| 2023-06-03 13:33:34 +0200 | <zups> | it is but i can't think of an answer to this :| |
| 2023-06-03 13:33:44 +0200 | <Axman6> | what have you tried? |
| 2023-06-03 13:33:45 +0200 | <ncf> | same way you would 'change' any value to any other value, i guess? |
| 2023-06-03 13:34:03 +0200 | <zups> | i can understand how to accumulate the accumulator but no idea how to change Maybe type from Nothing to Just |
| 2023-06-03 13:34:27 +0200 | <Axman6> | > Just 7 |
| 2023-06-03 13:34:28 +0200 | <lambdabot> | Just 7 |
| 2023-06-03 13:34:39 +0200 | zaidhaan | (~zai@2001:f40:960:1c54:3c0f:370:d2d1:4fb9) |
| 2023-06-03 13:34:48 +0200 | <ncf> | probably best not to talk about change when doing haskell |
| 2023-06-03 13:34:51 +0200 | <Axman6> | you just need to return Just <something> inside headHelper |
| 2023-06-03 13:35:22 +0200 | <Axman6> | > foldr (+) z [a, b, c] :: Expr |
| 2023-06-03 13:35:23 +0200 | <lambdabot> | a + (b + (c + z)) |
| 2023-06-03 13:35:31 +0200 | <Axman6> | > foldr f z [a, b, c] :: Expr |
| 2023-06-03 13:35:33 +0200 | <lambdabot> | f a (f b (f c z)) |
| 2023-06-03 13:36:22 +0200 | <zups> | yeah hmm |
| 2023-06-03 13:36:35 +0200 | <Axman6> | so whatever function you give to foldr, you will get that funtion back, applied to the first element of the lift, and the result of applying that function to the second element of the list, and that function applied... etc. |
| 2023-06-03 13:37:35 +0200 | <Axman6> | so you end up with headHelper a (headHelper b (headHeelper c (... headHelper z Nothing))) |
| 2023-06-03 13:38:39 +0200 | <zups> | yeah i get it just mmm |
| 2023-06-03 13:39:37 +0200 | <Axman6> | > foldr (\ x rest -> rest {- this will always be Nothing -}) Nothing [1,2,3] -- if we care about results from the rest of the list, we can return those |
| 2023-06-03 13:39:39 +0200 | <lambdabot> | Nothing |
| 2023-06-03 13:40:17 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-06-03 13:40:29 +0200 | <Axman6> | > foldr (\ x rest -> Just 10 {- or we could completely ignore the current value, or what's been computed elsewhere in the list -}) Nothing [1,2,3] -- |
| 2023-06-03 13:40:31 +0200 | <lambdabot> | Just 10 |
| 2023-06-03 13:40:43 +0200 | <Axman6> | looks a bit like what you want right? |
| 2023-06-03 13:41:03 +0200 | <zups> | yeah |
| 2023-06-03 13:41:12 +0200 | <zups> | i managed to fix it already just still wondering a little |
| 2023-06-03 13:41:52 +0200 | coot | (~coot@89.69.206.216) |
| 2023-06-03 13:41:58 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Quit: euandreh) |
| 2023-06-03 13:42:07 +0200 | euandreh1 | (~Thunderbi@189.6.18.7) |
| 2023-06-03 13:43:12 +0200 | <Axman6> | do you understand how you fixed it though? what was your fix? |
| 2023-06-03 13:44:10 +0200 | euandreh1 | euandreh |
| 2023-06-03 13:46:03 +0200 | <zups> | yeah, i just made it return Just n everytime headHelper n acc, gets called |
| 2023-06-03 13:46:36 +0200 | <Axman6> | So, a very useful skill when learning haskell is how to evaluate functions by hand |
| 2023-06-03 13:47:06 +0200 | <zups> | yeah i'm thinking it in my head but just not getting why it even works |
| 2023-06-03 13:47:34 +0200 | <Axman6> | if we use foldr (\x acc -> Just a) Nothing [1,2] we get: (\a acc -> Just a) 1 ((\a acc -> Just a) 2 Nothing, correct? |
| 2023-06-03 13:47:40 +0200 | <Axman6> | )* |
| 2023-06-03 13:48:23 +0200 | <zups> | yeah |
| 2023-06-03 13:48:40 +0200 | <Axman6> | If we take (\a acc -> Just a) 1 ((\a acc -> Just a) 2 Nothing) and do some application of the functions, but just one argument each, we get: |
| 2023-06-03 13:49:01 +0200 | <Axman6> | actually, you tell me what we get |
| 2023-06-03 13:49:17 +0200 | <ddellacosta> | Inst: as someone who used to work at CV, I won't want to say too much other than, their approach is one among many and has both positive and negative tradeoffs. I wouldn't assume it would work for every organization or that it represents some kind of general approach everyone needs to start adopting or else Haskell won't gain traction (or whatever). |
| 2023-06-03 13:49:20 +0200 | <Axman6> | make the \a's disappear so we have \acc -> ... |
| 2023-06-03 13:49:29 +0200 | <ddellacosta> | I won't *say too much |
| 2023-06-03 13:49:46 +0200 | <zups> | yeah just prolly acc -> Just 1 etc ? |
| 2023-06-03 13:50:01 +0200 | <Axman6> | yep, I want to see the full expression |
| 2023-06-03 13:50:44 +0200 | <zups> | (acc -> Just 1) ((acc -> Just 2) Nothing) ? |
| 2023-06-03 13:51:09 +0200 | <zups> | ah yeah i see now |
| 2023-06-03 13:51:19 +0200 | <Axman6> | close enough, (\acc -> Just 1) ((\acc -> Just 2) Nothing) |
| 2023-06-03 13:51:27 +0200 | <zups> | yeah i see how it goes now :) |
| 2023-06-03 13:51:47 +0200 | <Axman6> | so you can see that if you now apply that first lambda, you just ignore evrything else, and just get Just 1 |
| 2023-06-03 13:52:31 +0200 | <zups> | yeah ^^ I was just wondering how this whole foldr works that I did in the task but I didn't quite understand how it gets turned into a lambda and the Nothing gets passed through from there as a parameter |
| 2023-06-03 13:52:35 +0200 | <zups> | so now it makes sense :) |
| 2023-06-03 13:52:38 +0200 | <zups> | thanks |
| 2023-06-03 13:52:55 +0200 | <Axman6> | All good |
| 2023-06-03 13:53:36 +0200 | <Axman6> | do you reckon you could so a harder one now, safeLast? |
| 2023-06-03 13:54:22 +0200 | <zups> | so in the "foldr headHelper Nothing xs" the accumulator(=Nothing) actually gets passed as default argument in the foldr clause |
| 2023-06-03 13:54:35 +0200 | <zups> | so the accumulator is more like the default value? |
| 2023-06-03 13:54:43 +0200 | <Axman6> | there is no accumulator in foldr |
| 2023-06-03 13:55:06 +0200 | <Axman6> | foldl definitely has an accumulator, foldr does not |
| 2023-06-03 13:55:06 +0200 | <zups> | yeah, i see now, i always thought about the Nothing in that case to be the accumulator, usually there's 0 or something else |
| 2023-06-03 13:55:15 +0200 | <zups> | mmm i see |
| 2023-06-03 13:55:23 +0200 | <Axman6> | Nothing is what you get when you hit a [] |
| 2023-06-03 13:55:46 +0200 | <zups> | yeah |
| 2023-06-03 13:55:47 +0200 | <Axman6> | > foldr f z [a,b,c] :: Expr |
| 2023-06-03 13:55:48 +0200 | <lambdabot> | f a (f b (f c z)) |
| 2023-06-03 13:56:18 +0200 | <Axman6> | foldr does exactly this: it replaces all (:)'s with f, and any [] with z |
| 2023-06-03 13:56:19 +0200 | <probie> | [1,2,3,4] = 1:(2:(3:(4:[]))). foldr f z just means replace `:` with `f` and `[]` with `z`. e.g. foldr (*) 1 (1:(2:(3:(4:[])))) = (1*(2*(3*(4*1)))) |
| 2023-06-03 13:56:23 +0200 | <zups> | yeah |
| 2023-06-03 13:56:38 +0200 | <zups> | > foldl f z [a,b,c] :: Expr |
| 2023-06-03 13:56:40 +0200 | <lambdabot> | f (f (f z a) b) c |
| 2023-06-03 13:56:41 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-06-03 13:57:50 +0200 | <zups> | ah i see |
| 2023-06-03 13:57:51 +0200 | <Axman6> | foldl does this: foldl f z xs = { tmp := z; for x in xs { tmp := f x tmp}; return tmp} |
| 2023-06-03 13:58:51 +0200 | <Axman6> | (that's not haskell, btw) |
| 2023-06-03 13:59:50 +0200 | <zups> | yeah i understand now a bit more :) i was a bit confused cause i always thought foldr and foldl were just used to accumulate things, prolly cause that's how they are usually taught in Elixir |
| 2023-06-03 13:59:57 +0200 | <Axman6> | basically, foldl starts with your accumulating parameter as z, and then updates it with each value in the list and the last accumulator |
| 2023-06-03 14:00:18 +0200 | <zups> | but yeah, it makes a lot more sense now ^^ |
| 2023-06-03 14:00:28 +0200 | <zups> | yeah |
| 2023-06-03 14:00:45 +0200 | <Axman6> | Laziness makes foldr infinitely more useful iun Haskell than in most languages - in a strict language it would be a very bad idea to use in nearly all cases |
| 2023-06-03 14:01:06 +0200 | <zups> | yeah |
| 2023-06-03 14:02:08 +0200 | <zups> | but yeah, i just struggled with understand how the z is parameter to the first function call in foldr, and in foldl z is the parameter to the last i guess :) |
| 2023-06-03 14:02:11 +0200 | <Axman6> | What we wrote earlier wasn't even a useful to think about as this: foldl (\a acc -> Just a) Nothing [1,2] ==> (\a acc -> Just a) 1 (foldr (\a acc -> Just a) Nothing [2]) |
| 2023-06-03 14:02:22 +0200 | <zups> | just thouht of it as accumulator but it's just default parameter :) |
| 2023-06-03 14:02:27 +0200 | <Helle> | hmz, is there a usable set of rules to ordering imports ?, trying to reduce my level of induced chaos in this code :P |
| 2023-06-03 14:02:38 +0200 | <Inst> | Axman6: because of network effects |
| 2023-06-03 14:02:40 +0200 | <Axman6> | from this, you can hopefully see that the function we pass to foldr controls the execution |
| 2023-06-03 14:03:07 +0200 | ddellacosta | (~ddellacos@143.244.47.85) (Ping timeout: 240 seconds) |
| 2023-06-03 14:03:07 +0200 | <zups> | yeah |
| 2023-06-03 14:03:08 +0200 | <hpc> | Helle: '<:'>!sort is a nice first heuristic :P |
| 2023-06-03 14:03:15 +0200 | <Helle> | hpc: hey now |
| 2023-06-03 14:03:18 +0200 | <Axman6> | because (\a acc -> Just a) 1 (foldr (\a acc -> Just a) Nothing [2]) becomes (\acc -> Just 1) (foldr (\a acc -> Just a) Nothing [2]) |
| 2023-06-03 14:03:30 +0200 | <Inst> | hmmm, actually, I guess this comment would be in dispute, does English have a richer literature than French? |
| 2023-06-03 14:03:33 +0200 | <zups> | it was always prolly obvious to me just the default parameter was what messed me up :) |
| 2023-06-03 14:03:43 +0200 | <Axman6> | and (\acc -> Just 1) (foldr (\a acc -> Just a) Nothing [2]) becomes Just 1, foldr doesn't get to run any further |
| 2023-06-03 14:03:45 +0200 | <Inst> | well, does French have a richer literature than Esperanto? |
| 2023-06-03 14:04:08 +0200 | <Axman6> | don't get probie started on esperanto |
| 2023-06-03 14:04:13 +0200 | Fischmiep | (~Fischmiep@user/Fischmiep) (Quit: Ping timeout (120 seconds)) |
| 2023-06-03 14:04:14 +0200 | <Helle> | hpc: I mean genuinely though this is the sort of things I like to find a bunch of workable rules on, ideally better then just a plain sort |
| 2023-06-03 14:04:22 +0200 | <Inst> | ddellacosta: thanks for your input |
| 2023-06-03 14:04:34 +0200 | <Helle> | not because it needs a strict set of rules, but just to slap other people with when they make a total mess out of it |
| 2023-06-03 14:04:40 +0200 | Fischmiep | (~Fischmiep@user/Fischmiep) |
| 2023-06-03 14:04:58 +0200 | <zups> | oh, i thought it gets ran all the way through there hmm |
| 2023-06-03 14:05:03 +0200 | <Inst> | ddellacosta: my pov is more, globally type-inferenced static typing with typeclasses can do much of what dynamic types can do, in a safer fashion |
| 2023-06-03 14:05:17 +0200 | <Inst> | I'm guessing it's either a "solved" problem |
| 2023-06-03 14:05:20 +0200 | <Inst> | or it's neglected |
| 2023-06-03 14:05:20 +0200 | <Axman6> | Inst: for a counterexample, Bellroy are having a lot of success replacing their RoR apps with Haskell versions, which are faster, use less resources, have fewer bugs and are significantly shorter |
| 2023-06-03 14:05:40 +0200 | <Axman6> | zups: you get to choose if it does, that's where its power comes from |
| 2023-06-03 14:05:52 +0200 | <zups> | mmm |
| 2023-06-03 14:05:55 +0200 | <Inst> | my argument is more, "where are all the documentation of using Haskell in a pseudo-dynamically typed fashion?" |
| 2023-06-03 14:06:05 +0200 | <zups> | how would i choose it there? |
| 2023-06-03 14:06:15 +0200 | <Inst> | because I think we all agree here that CollegeVine was either skill-capped or made a mistake in switching from Haskell to RoR |
| 2023-06-03 14:06:17 +0200 | <hpc> | Helle: hmm, another thing i tend to do is group intra-package dependencies at the top |
| 2023-06-03 14:06:24 +0200 | <Inst> | but if the documentation were there, they wouldn't have had to make the switch |
| 2023-06-03 14:06:29 +0200 | <Inst> | they'd still be a Haskell firm |
| 2023-06-03 14:06:44 +0200 | <Axman6> | zups: try to write this, using foldr: find :: (a -> Bool) -> [a] -> Maybe a |
| 2023-06-03 14:07:04 +0200 | <hpc> | i don't really think about it much, i just kind of put imports wherever |
| 2023-06-03 14:07:08 +0200 | <Helle> | hpc: mmmmm, yeah, I was tending to group those at the bottom, and stuff in std lib before installed from hackage |
| 2023-06-03 14:07:15 +0200 | <hpc> | maybe only worry about being able to find the imports that are likely to change |
| 2023-06-03 14:07:17 +0200 | <Inst> | from what I understand, Haskell for prototyping requires pseudo-dynamically typed work, and is actually useful in its own way |
| 2023-06-03 14:07:24 +0200 | <Helle> | hpc: I am dealing with code janitorial on a larger code base and it yeah |
| 2023-06-03 14:07:27 +0200 | <Inst> | code without type signatures -> you know it's a prototype and shouldn't go into production |
| 2023-06-03 14:07:43 +0200 | <Axman6> | I disagree, static types help a lot in prototyping |
| 2023-06-03 14:07:43 +0200 | <Inst> | done with the prototyping? slap on some type sigs to say it's done |
| 2023-06-03 14:08:14 +0200 | <Axman6> | many experienced developers prototype by starting with the types, not by starting with functions without types |
| 2023-06-03 14:08:49 +0200 | <Axman6> | foo :: Signal -> State -> (Signal, State, [Notifications]); foo = undefined |
| 2023-06-03 14:08:54 +0200 | <Inst> | I know, that's TyDD |
| 2023-06-03 14:09:04 +0200 | <Inst> | or would you consider it TyDD? |
| 2023-06-03 14:09:13 +0200 | <Inst> | my pov is more that TyDD has its place, but shouldn't be used universally |
| 2023-06-03 14:09:54 +0200 | <Inst> | and that the ability to choose between TyDD and a lack of TyDD is a power in Haskell, as opposed to Idris, which seems to want to mandate TyDD |
| 2023-06-03 14:10:16 +0200 | <cheater> | i start my prototyping by first typing out all the indentation |
| 2023-06-03 14:10:20 +0200 | <cheater> | after that, it's easy |
| 2023-06-03 14:11:00 +0200 | <Axman6> | so that's why the strategic spaces reserv keeps getting depleted! |
| 2023-06-03 14:11:05 +0200 | <hpc> | i write all of my code alphabetically |
| 2023-06-03 14:11:44 +0200 | TonyStone | (~TonyStone@cpe-74-76-57-186.nycap.res.rr.com) (Remote host closed the connection) |
| 2023-06-03 14:12:20 +0200 | <hpc> | Axman6: best practice is to mix tabs and spaces so your keyboard wears out evenly |
| 2023-06-03 14:12:40 +0200 | <Axman6> | Agreed |
| 2023-06-03 14:12:43 +0200 | <hpc> | for best results, set your tab stop to 1 |
| 2023-06-03 14:13:14 +0200 | <Axman6> | :chefkiss: |
| 2023-06-03 14:13:36 +0200 | <hpc> | (no joke, i took a lisp class in college and in the middle of the sememster my laptop's 9 key stopped working) |
| 2023-06-03 14:13:56 +0200 | <cheater> | you obtain the most even keyboard wear by using a telegraph key |
| 2023-06-03 14:14:20 +0200 | <Axman6> | then you get write amplification, having to write (,8,+,1,) all the time |
| 2023-06-03 14:16:15 +0200 | <hpc> | cheater: "import control stop monad" :D |
| 2023-06-03 14:16:30 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:d512:b207:c888:476e) |
| 2023-06-03 14:16:39 +0200 | <jade[m]> | When using `blaze-html`, this minimal example seems to generate wrong code?... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/f24444037259842a1bb32fc576440fb9cdeb…>) |
| 2023-06-03 14:16:53 +0200 | gurkenglas | (~user@dynamic-046-114-180-171.46.114.pool.telefonica.de) |
| 2023-06-03 14:17:41 +0200 | <jade[m]> | I'm wondering whether I'm doing something wrong, because otherwise I would file a bug report? |
| 2023-06-03 14:21:05 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:d512:b207:c888:476e) (Ping timeout: 256 seconds) |
| 2023-06-03 14:21:50 +0200 | <ncf> | i think HTML5 self-closing tags don't need a final / ? |
| 2023-06-03 14:22:09 +0200 | <[Leary]> | Helle: I group my imports by package of origin, ordering the groups from most general (base, containers, etc) to most specific (domain-relevant dependencies, the library itself), and try to apply the same kind of ordering within each group. |
| 2023-06-03 14:22:26 +0200 | <jade[m]> | ncf: ohh, that'd make sense |
| 2023-06-03 14:22:41 +0200 | <hpc> | mdn includes the /, but perhaps they're just training people to not be sloppy |
| 2023-06-03 14:22:52 +0200 | <hpc> | but yeah, that's probably what it is - html is conspicuously not xml |
| 2023-06-03 14:22:53 +0200 | <jade[m]> | you're right! |
| 2023-06-03 14:23:00 +0200 | <jade[m]> | thank you, that clears it up |
| 2023-06-03 14:26:30 +0200 | <ncf> | https://developer.mozilla.org/en-US/docs/Glossary/Void_element#self-closing_tags |
| 2023-06-03 14:29:42 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2023-06-03 14:29:56 +0200 | <probie> | Inst: There is a lot of good literature in French, but that doesn't mean you should skip La Infana Raso. Haskell doesn't have to be widely used to be a very good choice for a task |
| 2023-06-03 14:33:15 +0200 | barrucadu | (~barrucadu@carcosa.barrucadu.co.uk) (Quit: leaving) |
| 2023-06-03 14:33:36 +0200 | <cheater> | what |
| 2023-06-03 14:36:33 +0200 | <tomsmeding> | Axman6: '(' is shift-9 on most keyboards |
| 2023-06-03 14:36:44 +0200 | cheater_ | (~Username@user/cheater) |
| 2023-06-03 14:36:45 +0200 | <Axman6> | oh no |
| 2023-06-03 14:37:10 +0200 | barrucadu | (~barrucadu@carcosa.barrucadu.co.uk) |
| 2023-06-03 14:38:22 +0200 | gurkenglas | (~user@dynamic-046-114-180-171.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-06-03 14:39:13 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 256 seconds) |
| 2023-06-03 14:39:19 +0200 | cheater_ | cheater |
| 2023-06-03 14:40:01 +0200 | coot | (~coot@89.69.206.216) (Quit: coot) |
| 2023-06-03 14:42:28 +0200 | ub | (~Thunderbi@p200300ecdf0002351300242c44b15f80.dip0.t-ipconnect.de) |
| 2023-06-03 14:43:44 +0200 | ubert | (~Thunderbi@p548c91e0.dip0.t-ipconnect.de) (Ping timeout: 250 seconds) |
| 2023-06-03 14:43:44 +0200 | ub | ubert |
| 2023-06-03 14:49:25 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 256 seconds) |
| 2023-06-03 14:55:26 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-06-03 14:59:05 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 15:03:26 +0200 | mokee | (~mokee@37.228.215.134) |
| 2023-06-03 15:04:09 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 256 seconds) |
| 2023-06-03 15:07:29 +0200 | machinedgod | (~machinedg@93-136-46-129.adsl.net.t-com.hr) (Ping timeout: 265 seconds) |
| 2023-06-03 15:12:57 +0200 | CiaoSen | (~Jura@145.224.74.19) |
| 2023-06-03 15:14:08 +0200 | jargon | (~jargon@184.101.71.62) |
| 2023-06-03 15:16:25 +0200 | barcisz | (~barcisz@83.6.201.246.ipv4.supernova.orange.pl) |
| 2023-06-03 15:16:26 +0200 | barcisz | (~barcisz@83.6.201.246.ipv4.supernova.orange.pl) (Client Quit) |
| 2023-06-03 15:22:53 +0200 | taupiqueur | (~taupiqueu@2a02-842a-8180-4601-9121-a036-575e-bd7e.rev.sfr.net) (Quit: WeeChat 3.8) |
| 2023-06-03 15:25:40 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-9121-a036-575e-bd7e.rev.sfr.net) (Remote host closed the connection) |
| 2023-06-03 15:28:46 +0200 | kilolympus | (~kilolympu@213.144.144.24) (Quit: See you later! :)) |
| 2023-06-03 15:29:04 +0200 | kilolympus | (~kilolympu@213.144.144.24) |
| 2023-06-03 15:31:04 +0200 | <ijqq> | I am reading a blogpost on parsing and they use this, I don't really understand it |
| 2023-06-03 15:31:07 +0200 | <ijqq> | newtype Parser i o = Parser { runParser :: i -> Maybe (i, o) } |
| 2023-06-03 15:33:53 +0200 | <Franciman> | ijqq: what's the strange part for you? |
| 2023-06-03 15:34:07 +0200 | <Franciman> | the newtype or the i -> Maybe (i, o) ? |
| 2023-06-03 15:34:42 +0200 | <ijqq> | So why exactly is this a newtype? And then it has a field `runParser` which is a function? |
| 2023-06-03 15:35:03 +0200 | <Franciman> | this is syntax sugar |
| 2023-06-03 15:35:39 +0200 | <Franciman> | the newtype is to create a new type name which is distinct from all others |
| 2023-06-03 15:36:07 +0200 | <Franciman> | so basically a parser is a function of type i -> Maybe (i, o) |
| 2023-06-03 15:36:34 +0200 | <Franciman> | but to make it more abstract, you hide it behind a newtype |
| 2023-06-03 15:36:54 +0200 | <Franciman> | you could have also done: |
| 2023-06-03 15:37:01 +0200 | <Axman6> | it could also be data Parser i o = Parser (i -> Maybe (i,o)); runParser (Parser f) = f |
| 2023-06-03 15:37:02 +0200 | <Franciman> | type Parser i o = i -> Maybe (i, o) |
| 2023-06-03 15:37:23 +0200 | <Axman6> | (if you're more familiar with data) |
| 2023-06-03 15:37:36 +0200 | <Franciman> | yes. The only difference with the Axman6's version is that newtype is really just syntax sugar |
| 2023-06-03 15:37:44 +0200 | <Franciman> | it doesn't add any other overhead |
| 2023-06-03 15:37:52 +0200 | <Franciman> | iiuc |
| 2023-06-03 15:38:19 +0200 | <Axman6> | well, it's more than syntax sugar, is created a new type too. they is no runtime overhead though |
| 2023-06-03 15:38:46 +0200 | <Franciman> | true |
| 2023-06-03 15:40:08 +0200 | <Axman6> | ijqq: doesn any of that help? |
| 2023-06-03 15:41:40 +0200 | <Axman6> | this is nearly exactly the same: newtype Parser i o = Parser (i -> (i,o)); runParser :: Parser i o -> (i -> (i,o)); runParser (Parser f) = f |
| 2023-06-03 15:42:08 +0200 | <Axman6> | (the only thing missing is that you can also use the name runParser for "updating" a Parser, but it |
| 2023-06-03 15:42:20 +0200 | <Axman6> | it's not bery useful with newtypes) |
| 2023-06-03 15:43:14 +0200 | <ijqq> | http://sprunge.us/NVxf5O |
| 2023-06-03 15:43:20 +0200 | <ijqq> | If my understanding is correct |
| 2023-06-03 15:43:23 +0200 | <ijqq> | I think I get it |
| 2023-06-03 15:43:26 +0200 | <ijqq> | Thanks guys |
| 2023-06-03 15:45:30 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2023-06-03 15:49:32 +0200 | <ijqq> | I guess I was just a bit confused on the parsing function being a field in the newtype, but it makes sense now. |
| 2023-06-03 15:53:20 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-06-03 15:54:21 +0200 | vandita | (~vandit@178-164-188-29.pool.digikabel.hu) (Ping timeout: 250 seconds) |
| 2023-06-03 15:55:59 +0200 | vandita | (~vandit@178-164-207-211.pool.digikabel.hu) |
| 2023-06-03 15:57:37 +0200 | nate2 | (~nate@98.45.169.16) |
| 2023-06-03 16:00:26 +0200 | jargon | (~jargon@184.101.71.62) (Remote host closed the connection) |
| 2023-06-03 16:00:40 +0200 | <[Leary]> | ijqq: Note that one of the main reasons to make `Parser` a newtype rather than a type synonym is in order to give it key instances like `Monad`, thus making it much easier to use. This would normally be done with GNTD like so: `newtype Parser i o = Parser (StateT i Maybe o) deriving (Functor, Applicative, Alternative, Monad, MonadState i)`. |
| 2023-06-03 16:00:45 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2023-06-03 16:01:33 +0200 | <ijqq> | Okay, now the blog post is talking about functors. So I'm reading an article about functors, and it gives the example of `fmap chr (65, 65)` which gives `(65, 'A')`. Where can I see the code for or find more information about the fmap implemntation of tuples? |
| 2023-06-03 16:02:03 +0200 | <ski> | @src (,) fmap |
| 2023-06-03 16:02:03 +0200 | <lambdabot> | fmap f (x,y) = (x, f y) |
| 2023-06-03 16:02:05 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2023-06-03 16:02:15 +0200 | <ijqq> | Ah, cool. |
| 2023-06-03 16:03:06 +0200 | <ijqq> | Interesting, Leary. Thanks. I'll have to read up on Monad and those others too. |
| 2023-06-03 16:03:07 +0200 | zxrom | (~zxrom@mm-92-28-212-37.vitebsk.dynamic.pppoe.byfly.by) (Ping timeout: 240 seconds) |
| 2023-06-03 16:03:17 +0200 | <ijqq> | What is GNTD? |
| 2023-06-03 16:04:09 +0200 | <geekosaur> | https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/newtype_deriving.html |
| 2023-06-03 16:04:47 +0200 | <[Leary]> | GeneralisedNewtypeDeriving. It just pulls instances through newtypes, but it can let you avoid a bunch of boilerplate. |
| 2023-06-03 16:05:45 +0200 | <zups> | Axman6: I tried to implement the find with foldr but i didn't manage to. How would one do that? |
| 2023-06-03 16:06:40 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 16:06:57 +0200 | <ijqq> | Also Leary, how could I see which instances the Parser has in ghci? |
| 2023-06-03 16:07:38 +0200 | <[Leary]> | :i Parser should do it. |
| 2023-06-03 16:08:33 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 16:08:42 +0200 | <ijqq> | type Parser :: * -> * -> * |
| 2023-06-03 16:08:42 +0200 | <ijqq> | newtype Parser i o = Parser {runParser :: i -> Maybe (i, o)} |
| 2023-06-03 16:08:42 +0200 | <ijqq> | -- Defined at main.hs:60:1 |
| 2023-06-03 16:08:56 +0200 | <ijqq> | So does that mean that my parser does not have those instances? |
| 2023-06-03 16:09:45 +0200 | <[Leary]> | This is somewhat of a simplification, but if you're defining a type, it won't have any instances you haven't given it. |
| 2023-06-03 16:09:50 +0200 | <probie> | zups: what did the definition of your head function using foldr look like? |
| 2023-06-03 16:12:06 +0200 | <ijqq> | Oh, sorry I think i misinterpreted your message. So you mean to say that, by making my Parser through newtype, later on I am easily able to make it an instance of Monad, etc.? |
| 2023-06-03 16:12:15 +0200 | <probie> | your definition of `find` should actually be pretty similar |
| 2023-06-03 16:13:08 +0200 | <[Leary]> | ijqq: Yes. Or rather, if it's a synonym, that's impossible. |
| 2023-06-03 16:13:16 +0200 | <zups> | probie: foldr (\x d -> if (x == d) then (Just x) else Nothing) 2 [1,2,3] |
| 2023-06-03 16:13:25 +0200 | <zups> | I tried something like this but it doesn't even compile |
| 2023-06-03 16:13:26 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 250 seconds) |
| 2023-06-03 16:14:05 +0200 | CiaoSen | (~Jura@145.224.74.19) (Ping timeout: 240 seconds) |
| 2023-06-03 16:14:55 +0200 | <probie> | most of the right pieces, but some in the wrong places |
| 2023-06-03 16:14:56 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 16:15:42 +0200 | <zups> | yeah :) I just get the error message "cannot construct infite type a ~ Maybe a" and i never understand how to decrypt that :) |
| 2023-06-03 16:15:51 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 16:16:34 +0200 | <probie> | Have you been told what type find should have? |
| 2023-06-03 16:17:39 +0200 | <zups> | Axman6 | zups: try to write this, using foldr: find :: (a -> Bool) -> [a] -> Maybe a |
| 2023-06-03 16:18:03 +0200 | <ski> | zups : it means you're confusing `a's with `Maybe a's |
| 2023-06-03 16:18:18 +0200 | <[Leary]> | zups: It might help if you realise that `find (\_ -> True) = myHead`. |
| 2023-06-03 16:19:15 +0200 | <zups> | mmm |
| 2023-06-03 16:19:32 +0200 | <ski> | zups : in that `foldr' example, `x' will need to have the same type as `Just x' and `Nothing' (the possible results of the lambda) .. but `x' having same type of `Just x' leads to infinite/cyclic type |
| 2023-06-03 16:20:37 +0200 | <ski> | well, it's because you're comparing `x' and `d' with each other, really, too |
| 2023-06-03 16:21:45 +0200 | <ski> | `foldr' takes a function of type say `a -> r -> r'. so `d' has type `r', and `Just x' and `Nothing' must also have type `r'. and `x' has type `a'. but since you compare `x' with `r', they must be of the same type, so `a = r' |
| 2023-06-03 16:21:54 +0200 | n0den1te | (~n0den1te@157.119.87.13) (Quit: leaving) |
| 2023-06-03 16:22:24 +0200 | <ski> | (er, compare `x' with `d') |
| 2023-06-03 16:25:30 +0200 | <ijqq> | Ah, I also found this stack overflow article which addresses the same question that I asked https://stackoverflow.com/questions/60291263/why-the-newtype-syntax-creates-a-function |
| 2023-06-03 16:28:42 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2023-06-03 16:28:56 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 16:28:58 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2023-06-03 16:29:45 +0200 | Tlsx | (~rscastilh@189-82-108-215.user3p.veloxzone.com.br) |
| 2023-06-03 16:36:14 +0200 | freeside | (~mengwong@103.252.202.189) |
| 2023-06-03 16:36:41 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 16:36:58 +0200 | Tlsx | (~rscastilh@189-82-108-215.user3p.veloxzone.com.br) (Remote host closed the connection) |
| 2023-06-03 16:38:58 +0200 | Tlsx | (~rscastilh@189-82-108-215.user3p.veloxzone.com.br) |
| 2023-06-03 16:39:04 +0200 | <freeside> | so, i'm trying to convert a non-monadic function to a monadic function -- i'm wrapping it in RWS so I can convert by Debug.Traces to "tell"s instead. And I'm walking down the function calls and upgrading all of them to monadic style as well. But I've got a couple of nested list comprehensions; how do I convert the function calls inside them, to a monadic style? |
| 2023-06-03 16:40:06 +0200 | <probie> | what do you mean by "a monadic style"? You can desugar list comprehensions to do notation. |
| 2023-06-03 16:41:22 +0200 | <probie> | > [(x+y) | x <- [1..5], y <- [6..10], even x, odd y] |
| 2023-06-03 16:41:23 +0200 | <lambdabot> | [9,11,11,13] |
| 2023-06-03 16:41:32 +0200 | <ncf> | or turn on MonadComprehensions |
| 2023-06-03 16:41:52 +0200 | <probie> | > do { x <- [1..5]; y <- [6..10]; guard (even x); guard (even y); pure (x+y) } |
| 2023-06-03 16:41:53 +0200 | <lambdabot> | [8,10,12,10,12,14] |
| 2023-06-03 16:41:55 +0200 | <ski> | won't really help in this case |
| 2023-06-03 16:42:02 +0200 | Tlsx | (~rscastilh@189-82-108-215.user3p.veloxzone.com.br) (Remote host closed the connection) |
| 2023-06-03 16:42:06 +0200 | <ncf> | maybe with ListT? |
| 2023-06-03 16:42:13 +0200 | <ski> | they're looking for what ncf just said, yea |
| 2023-06-03 16:42:26 +0200 | <ski> | or doing it manually |
| 2023-06-03 16:42:30 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-06-03 16:42:42 +0200 | <freeside> | previously I had, e.g. [ g x y | (x,y) <- f l ] ... now I'm changing f to return m [(a,b)] instead of [(a,b)] |
| 2023-06-03 16:43:08 +0200 | <ski> | just a single generator in the list comprehension ? |
| 2023-06-03 16:43:44 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 16:43:45 +0200 | <ski> | will `g' also be monadic ? |
| 2023-06-03 16:44:14 +0200 | <jade[m]> | you can sequence it |
| 2023-06-03 16:44:15 +0200 | <freeside> | yes, i believe so |
| 2023-06-03 16:44:16 +0200 | <probie> | You probably want to return a `[m (a,b)]` and call `sequence` on it |
| 2023-06-03 16:44:41 +0200 | ncf | . o O ( why do so many packages provide ListT, and which one is the canonical one? ) |
| 2023-06-03 16:44:41 +0200 | <ski> | or `mapM' |
| 2023-06-03 16:44:42 +0200 | <freeside> | ah, i see. and if i do that i don't have to disembowel my list comprehensions |
| 2023-06-03 16:45:00 +0200 | <probie> | What's the type of `f`? Is it "monadic" as well? If not you don't need to disembowel the list comprehension |
| 2023-06-03 16:45:28 +0200 | <ski> | "now I'm changing f to return m [(a,b)] instead of [(a,b)]" |
| 2023-06-03 16:45:45 +0200 | <freeside> | well, i'm tweaking it so that it will be monadic, because the last programmer who touched this code base decided to Debug.Trace all over, and I want to W instead |
| 2023-06-03 16:47:26 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 16:48:09 +0200 | <ncf> | mtl 2.3 removed Control.Monad.List and the changelog doesn't say what to use instead o_o |
| 2023-06-03 16:49:01 +0200 | <c_wraith> | ncf: there's no way to do what it does correctly. You need to alter your requirements a bit instead. |
| 2023-06-03 16:51:12 +0200 | <EvanR> | if Debug.Trace is used as a logger, RWS at least the W part won't work very well for that |
| 2023-06-03 16:51:33 +0200 | <EvanR> | Writer is terribly lazy |
| 2023-06-03 16:51:44 +0200 | <freeside> | i'm relying on evalRWS to get out the (a,w), so i think i'm looking for something sequence-like, that has m [(a,b)] -> m ([a],[b]) |
| 2023-06-03 16:52:10 +0200 | <probie> | `fmap unzip`? |
| 2023-06-03 16:52:42 +0200 | <EvanR> | Writer for logging is just bad |
| 2023-06-03 16:52:51 +0200 | <freeside> | what's the best practice around that? |
| 2023-06-03 16:53:05 +0200 | <EvanR> | you could use State for a log, or a dedicated logger monad? |
| 2023-06-03 16:53:56 +0200 | freeside | looks at monad-logger |
| 2023-06-03 16:54:55 +0200 | <EvanR> | I hear good things |
| 2023-06-03 16:55:44 +0200 | <chromoblob> | why is Writer bad for logging? |
| 2023-06-03 16:55:56 +0200 | <jade[m]> | freeside: that's just `fmap unzip` |
| 2023-06-03 16:56:14 +0200 | <juri_> | ugh. new quickcheck has exposed a lot of holes in my geometry generation engine. yaay? |
| 2023-06-03 16:56:22 +0200 | <EvanR> | Writer has two modes, very lazy and somewhat lazy |
| 2023-06-03 16:56:57 +0200 | <EvanR> | bad for a long running computation that keeps getting appended, that eventually want to see |
| 2023-06-03 16:58:04 +0200 | <EvanR> | at the very least you want to keep the log fully evaluated, which there's no option for, but even then it keeps growing in size |
| 2023-06-03 16:58:32 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 16:59:00 +0200 | <EvanR> | there are cases where Writer makes sense but they don't look like logging |
| 2023-06-03 16:59:08 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2023-06-03 16:59:15 +0200 | <chromoblob> | does it *always* keep growing? |
| 2023-06-03 16:59:26 +0200 | <freeside> | my log is, like, 20 lines at the moment, but i will DTRT and try to switch to monad-logger |
| 2023-06-03 16:59:32 +0200 | <EvanR> | no, you could use a monoid that doesn't grow |
| 2023-06-03 16:59:45 +0200 | <freeside> | brb, thnx all for the advice, i am going to go off and get lost in a maze of twisty little hackages |
| 2023-06-03 17:00:21 +0200 | <chromoblob> | hmm |
| 2023-06-03 17:00:45 +0200 | <chromoblob> | can we arrange so that at the end there is an infinite stream of log entries |
| 2023-06-03 17:00:49 +0200 | <geekosaur> | there are also things like MonadChronicle on hackage |
| 2023-06-03 17:00:50 +0200 | <EvanR> | actually, the strict version of writer still doesn't do what you think |
| 2023-06-03 17:01:25 +0200 | <EvanR> | https://stackoverflow.com/questions/14644830/what-is-the-point-of-having-a-lazy-strict-version-of-… |
| 2023-06-03 17:01:35 +0200 | <chromoblob> | i mean, finite if the action ends, and infinite if it doesn't |
| 2023-06-03 17:01:55 +0200 | <EvanR> | yes you can create an infinite stream with writer |
| 2023-06-03 17:02:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 17:03:22 +0200 | <chromoblob> | EvanR: with Writer? but in the end it returns (result, m1 `mappend` m2) |
| 2023-06-03 17:03:39 +0200 | <chromoblob> | that `mappend` doesn't exist if there are infinite acitons |
| 2023-06-03 17:04:07 +0200 | <chromoblob> | i forgot how monads work |
| 2023-06-03 17:04:15 +0200 | <chromoblob> | is >> left associative? |
| 2023-06-03 17:04:47 +0200 | darchitect | (~darchitec@host86-157-65-148.range86-157.btcentralplus.com) (Quit: WeeChat 3.8) |
| 2023-06-03 17:05:06 +0200 | <int-e> | Yes. That doesn't matter though if you have loop = action >> loop |
| 2023-06-03 17:05:24 +0200 | <int-e> | which is action >> (action >> (action >> ...)) |
| 2023-06-03 17:05:45 +0200 | <chromoblob> | ok, i see now |
| 2023-06-03 17:05:58 +0200 | <chromoblob> | so infinite streams will just work |
| 2023-06-03 17:06:15 +0200 | <EvanR> | depends on the Monoid |
| 2023-06-03 17:09:09 +0200 | <chromoblob> | yeah if the monoid is "backwards list" then loop must be loop >> action |
| 2023-06-03 17:09:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 17:12:17 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 17:13:03 +0200 | gurkenglas | (~user@dynamic-046-114-180-171.46.114.pool.telefonica.de) |
| 2023-06-03 17:13:05 +0200 | berberman | (~berberman@user/berberman) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-06-03 17:13:56 +0200 | <freeside> | okay. maybe I was too vague when I said I wanted to log. I basically have a compiler for a little language, and the toolchain includes a bunch of transpilers on the back end. I want each transpiler to be able to mumble out some STDERR as it goes along, and eventually, when the compiler completes, I want it to dump all the stderr-like output to disk, one file per transpiler. So I'm moving away from |
| 2023-06-03 17:14:02 +0200 | <freeside> | Debug.Trace, and I'm moving away from IO, so my Main can accumulate and organize all the mumbling. |
| 2023-06-03 17:14:06 +0200 | <freeside> | In a situation like this is Writer acceptable? I mean, it's not a lot of output. |
| 2023-06-03 17:14:26 +0200 | <EvanR> | in the best case, if you're careful to consume the entire log lazily before looking at the result, then the magic of update frames ensures you don't waste memory. But if you do, the whole log has to get evaluated first |
| 2023-06-03 17:14:36 +0200 | berberman | (~berberman@user/berberman) |
| 2023-06-03 17:15:33 +0200 | <EvanR> | if you forget to play it like that and look at the result first |
| 2023-06-03 17:17:13 +0200 | yaxu | (~yaxu@host-79-78-86-129.static.as9105.net) |
| 2023-06-03 17:18:19 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-06-03 17:18:26 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:d512:b207:c888:476e) |
| 2023-06-03 17:19:33 +0200 | <ski> | > let loop = 1 % 2 : do x <- loop; [recip (1 + recip x),1 + x] in loop |
| 2023-06-03 17:19:36 +0200 | <lambdabot> | [1 % 2,1 % 3,3 % 2,1 % 4,4 % 3,3 % 5,5 % 2,1 % 5,5 % 4,4 % 7,7 % 3,3 % 8,8 %... |
| 2023-06-03 17:21:56 +0200 | <yaxu> | Hi all, I'm 100% sure I'm being stupid, but I've stared at these lines for a while, and can't see why they are raising the warning "Pattern match(es) are non-exhaustive In an equation for ‘loop’" https://github.com/tidalcycles/Tidal/blob/5fd3f26b973cf3ab2d5ef7406e267f75676d2063/src/Sound/Tidal… |
| 2023-06-03 17:22:08 +0200 | <ncf> | calkin-wilf! |
| 2023-06-03 17:22:31 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-06-03 17:22:31 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:d512:b207:c888:476e) (Ping timeout: 240 seconds) |
| 2023-06-03 17:23:01 +0200 | <EvanR> | what did you just call me? |
| 2023-06-03 17:23:08 +0200 | <ncf> | yaxu: use <- instead of == |
| 2023-06-03 17:23:17 +0200 | <ncf> | LT <- cmp |
| 2023-06-03 17:23:20 +0200 | <jade[m]> | yaxu: the guards are not "exhaustive" |
| 2023-06-03 17:23:21 +0200 | <int-e> | ski: why are you starting at 1/2? |
| 2023-06-03 17:23:26 +0200 | <int-e> | (rather than 1) |
| 2023-06-03 17:23:43 +0200 | <int-e> | oh |
| 2023-06-03 17:23:44 +0200 | <jade[m]> | because ghc doesn't like to infer stuff about == |
| 2023-06-03 17:25:22 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Ping timeout: 250 seconds) |
| 2023-06-03 17:26:00 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-06-03 17:27:07 +0200 | vandita | (~vandit@178-164-207-211.pool.digikabel.hu) (Ping timeout: 240 seconds) |
| 2023-06-03 17:27:55 +0200 | <yaxu> | @jade[m] aha thanks! switching in a case statement has fixed it |
| 2023-06-03 17:27:55 +0200 | <lambdabot> | Unknown command, try @list |
| 2023-06-03 17:28:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 17:28:11 +0200 | <yaxu> | jade[m], aha thanks! switching in a case statement has fixed it |
| 2023-06-03 17:28:15 +0200 | <ski> | yea, probably should have started with one |
| 2023-06-03 17:28:40 +0200 | <EvanR> | ... in 1%1 : loop |
| 2023-06-03 17:28:55 +0200 | vandita | (~vandit@85-238-93-47.pool.digikabel.hu) |
| 2023-06-03 17:29:20 +0200 | <int-e> | EvanR: but it'll still be missing 2 then |
| 2023-06-03 17:29:43 +0200 | int-e | isn't sure exactly which numbers will end up missing |
| 2023-06-03 17:31:24 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 17:31:45 +0200 | <chromoblob> | what numbers is the loop supposed to compute? |
| 2023-06-03 17:31:49 +0200 | taupiqueur | (~taupiqueu@2a02-842a-8180-4601-c87a-3932-439e-c5a6.rev.sfr.net) |
| 2023-06-03 17:31:57 +0200 | <EvanR> | all of them? xD |
| 2023-06-03 17:32:11 +0200 | <ncf> | the immediate left subtree of the calkin-wilf tree |
| 2023-06-03 17:32:45 +0200 | <int-e> | (the positive rationals) |
| 2023-06-03 17:34:17 +0200 | <int-e> | (ncf's answer is what the function computes... I'm speculating about the intent) |
| 2023-06-03 17:34:22 +0200 | <chromoblob> | cool |
| 2023-06-03 17:35:11 +0200 | <EvanR> | looking it up, you're missing a lot going by just the left subtree |
| 2023-06-03 17:35:53 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-06-03 17:38:32 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 17:38:47 +0200 | AlexNoo_ | (~AlexNoo@178.34.162.37) |
| 2023-06-03 17:39:01 +0200 | __monty__ | (~toonn@user/toonn) |
| 2023-06-03 17:40:38 +0200 | AlexZenon_2 | (~alzenon@178.34.162.37) |
| 2023-06-03 17:41:07 +0200 | AlexZenon | (~alzenon@178.34.163.104) (Ping timeout: 240 seconds) |
| 2023-06-03 17:42:05 +0200 | AlexNoo | (~AlexNoo@178.34.163.104) (Ping timeout: 240 seconds) |
| 2023-06-03 17:42:07 +0200 | Alex_test | (~al_test@178.34.163.104) (Ping timeout: 240 seconds) |
| 2023-06-03 17:42:09 +0200 | AlexNoo_ | AlexNoo |
| 2023-06-03 17:42:10 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 17:44:15 +0200 | AlexZenon_2 | AlexZenon |
| 2023-06-03 17:44:53 +0200 | <int-e> | > let loop = 1 % 1 : do x <- loop; [1 + x, recip (1 + x)] in loop -- does this variant also have a name? |
| 2023-06-03 17:44:54 +0200 | <lambdabot> | [1 % 1,2 % 1,1 % 2,3 % 1,1 % 3,3 % 2,2 % 3,4 % 1,1 % 4,4 % 3,3 % 4,5 % 2,2 %... |
| 2023-06-03 17:46:35 +0200 | Alex_test | (~al_test@178.34.162.37) |
| 2023-06-03 17:47:55 +0200 | Pickchea | (~private@user/pickchea) |
| 2023-06-03 17:48:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 17:48:36 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:d512:b207:c888:476e) |
| 2023-06-03 17:51:49 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 17:53:43 +0200 | yaxu | (~yaxu@host-79-78-86-129.static.as9105.net) (Quit: Leaving) |
| 2023-06-03 17:53:55 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2023-06-03 17:54:21 +0200 | <tomsmeding> | int-e: from this prefix it seems like it's enumerating https://en.wikipedia.org/wiki/Stern%E2%80%93Brocot_tree in a weird order |
| 2023-06-03 17:54:25 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2023-06-03 17:55:10 +0200 | Christoph[m] | (~hpotsirhc@2001:470:69fc:105::2ff8) (Ping timeout: 265 seconds) |
| 2023-06-03 17:55:11 +0200 | <tomsmeding> | that is: enumerate layer-by-layer, and within a layer, enumerate(layer) = interleave(enumerate(left half of layer), enumerate(reverse(right half of layer))) |
| 2023-06-03 17:55:13 +0200 | <akadude[m]> | Hey, can anyone recommend vcache-like library but maintained? |
| 2023-06-03 17:55:25 +0200 | <tomsmeding> | but again that's just from this prefix :p |
| 2023-06-03 17:55:30 +0200 | <int-e> | tomsmeding: well that's also true for the Calkin-Wilf tree... it's positive rationals |
| 2023-06-03 17:55:44 +0200 | <tomsmeding> | there the enumeration order is even weirder though |
| 2023-06-03 17:56:30 +0200 | <akadude[m]> | By vcache-like I mean that it provides interface to run STM transactions on persistently stored data |
| 2023-06-03 17:58:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 17:59:41 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-06-03 18:01:30 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 18:04:22 +0200 | <akadude[m]> | Oh, I see that TCache (listed in alternatives) is maintained |
| 2023-06-03 18:08:32 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 18:11:25 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 18:16:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 18:16:57 +0200 | <c_wraith> | Hmm. does pseq have performance implications over seq *other* than the fact that it prevents ghc from reordering computations? |
| 2023-06-03 18:18:37 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 18:21:25 +0200 | telser | (~quassel@user/telser) (Ping timeout: 240 seconds) |
| 2023-06-03 18:22:01 +0200 | ub | (~Thunderbi@p548c91e0.dip0.t-ipconnect.de) |
| 2023-06-03 18:22:56 +0200 | ubert | (~Thunderbi@p200300ecdf0002351300242c44b15f80.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2023-06-03 18:22:56 +0200 | ub | ubert |
| 2023-06-03 18:26:56 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 18:26:58 +0200 | stef204 | (~stef204@user/stef204) |
| 2023-06-03 18:29:18 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2023-06-03 18:29:44 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 18:31:47 +0200 | telser | (~quassel@user/telser) |
| 2023-06-03 18:34:28 +0200 | cheater_ | (~Username@user/cheater) |
| 2023-06-03 18:34:38 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 268 seconds) |
| 2023-06-03 18:34:43 +0200 | cheater_ | cheater |
| 2023-06-03 18:36:56 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 18:38:51 +0200 | econo | (uid147250@user/econo) |
| 2023-06-03 18:39:22 +0200 | gemmaro | (~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc) |
| 2023-06-03 18:39:39 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 18:40:24 +0200 | <monochrom> | I think no. |
| 2023-06-03 18:42:54 +0200 | stef204 | (~stef204@user/stef204) (Quit: WeeChat 3.8) |
| 2023-06-03 18:46:28 +0200 | ubert | (~Thunderbi@p548c91e0.dip0.t-ipconnect.de) (Quit: ubert) |
| 2023-06-03 18:47:33 +0200 | stef204 | (~stef204@user/stef204) |
| 2023-06-03 18:51:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 18:53:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 18:54:37 +0200 | telser | (~quassel@user/telser) (Ping timeout: 240 seconds) |
| 2023-06-03 18:56:10 +0200 | acidjnk | (~acidjnk@p200300d6e7072f454588bfb78dd6f620.dip0.t-ipconnect.de) |
| 2023-06-03 18:57:51 +0200 | gemmaro | (~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc) (Remote host closed the connection) |
| 2023-06-03 19:01:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 19:02:22 +0200 | telser | (~quassel@user/telser) |
| 2023-06-03 19:03:28 +0200 | stef204 | (~stef204@user/stef204) (Quit: WeeChat 3.8) |
| 2023-06-03 19:05:00 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 19:06:17 +0200 | slaydr | (~slaydr@2601:1c2:980:4ea0::a4a5) (Remote host closed the connection) |
| 2023-06-03 19:15:51 +0200 | machinedgod | (~machinedg@93-136-46-129.adsl.net.t-com.hr) |
| 2023-06-03 19:16:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 19:17:39 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer) |
| 2023-06-03 19:18:37 +0200 | chromoblob | (~user@37.113.158.8) (Ping timeout: 240 seconds) |
| 2023-06-03 19:18:54 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-c87a-3932-439e-c5a6.rev.sfr.net) |
| 2023-06-03 19:19:11 +0200 | zxrom | (~zxrom@mm-214-30-212-37.vitebsk.dynamic.pppoe.byfly.by) |
| 2023-06-03 19:19:49 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 19:21:43 +0200 | Guest18 | (~Guest18@host-091-097-060-051.ewe-ip-backbone.de) |
| 2023-06-03 19:22:13 +0200 | cheater_ | (~Username@user/cheater) |
| 2023-06-03 19:23:59 +0200 | cheater__ | (~Username@user/cheater) |
| 2023-06-03 19:24:08 +0200 | tabemann | (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) (Ping timeout: 265 seconds) |
| 2023-06-03 19:25:06 +0200 | <ManofLetters[m]> | there's this wonderful function https://hackage.haskell.org/package/base-4.18.0.0/docs/GHC-TypeLits.html#v:sameNat, sameNat :: forall a b proxy1 proxy2. (KnownNat a, KnownNat b) => proxy1 a -> proxy2 b -> Maybe (a :~: b) |
| 2023-06-03 19:25:06 +0200 | <ManofLetters[m]> | how do I get sameShape that instead of taking two proxies of Nat, takes two proxies of [Nat]? |
| 2023-06-03 19:25:23 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 256 seconds) |
| 2023-06-03 19:25:50 +0200 | <ManofLetters[m]> | this is not a homework ;) |
| 2023-06-03 19:26:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 19:27:34 +0200 | cheater_ | (~Username@user/cheater) (Ping timeout: 250 seconds) |
| 2023-06-03 19:28:27 +0200 | cheater_ | (~Username@user/cheater) |
| 2023-06-03 19:28:27 +0200 | cheater_ | cheater |
| 2023-06-03 19:28:58 +0200 | cheater__ | (~Username@user/cheater) (Ping timeout: 265 seconds) |
| 2023-06-03 19:29:41 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 19:29:54 +0200 | <ncf> | what's a shape? |
| 2023-06-03 19:31:37 +0200 | <ManofLetters[m]> | it's [Nat] |
| 2023-06-03 19:31:56 +0200 | <ManofLetters[m]> | (a type-level representation of a shape of an array) |
| 2023-06-03 19:33:58 +0200 | <ManofLetters[m]> | that would be `sameShape :: forall a b proxy1 proxy2. (Shape a, Shape b) => proxy1 a -> proxy2 b -> Maybe (a :~: b)`, where `class (Typeable s) => Shape (s :: [Nat])` |
| 2023-06-03 19:34:51 +0200 | CiaoSen | (~Jura@145.224.74.19) |
| 2023-06-03 19:34:58 +0200 | <ManofLetters[m]> | with `instance Shape '[]` and `instance forall n s . (Shape s, KnownNat n) => Shape (n ': s)` |
| 2023-06-03 19:36:18 +0200 | <ncf> | there's https://hackage.haskell.org/package/typelits-witnesses-0.3.0.2/docs/GHC-TypeLits-List.html#v:sameN… |
| 2023-06-03 19:36:25 +0200 | <ManofLetters[m]> | (taken from https://hackage.haskell.org/package/orthotope-0.1.2.0/docs/src/Data.Array.Internal.Shape.html#Shape) |
| 2023-06-03 19:36:53 +0200 | <ncf> | though that package recommends using singletons instead |
| 2023-06-03 19:36:56 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 19:37:49 +0200 | <ManofLetters[m]> | they know nothing, this is great! |
| 2023-06-03 19:38:01 +0200 | <ManofLetters[m]> | but how would I use do this with singletons? |
| 2023-06-03 19:38:07 +0200 | <ManofLetters[m]> | s/use// |
| 2023-06-03 19:40:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 19:41:24 +0200 | <ManofLetters[m]> | huh, I searched for sameNats on hoogle and found nothing; that's a bummer |
| 2023-06-03 19:41:37 +0200 | <ManofLetters[m]> | @ncf: how did you find it? |
| 2023-06-03 19:41:37 +0200 | <lambdabot> | Unknown command, try @list |
| 2023-06-03 19:42:14 +0200 | <ncf> | googled "ghc type level list" |
| 2023-06-03 19:44:15 +0200 | <ManofLetters[m]> | wow, smart |
| 2023-06-03 19:44:32 +0200 | <ManofLetters[m]> | they actually hint how to do this with singletons at the very bottom of the https://hackage.haskell.org/package/typelits-witnesses-0.3.0.2 page |
| 2023-06-03 19:45:02 +0200 | <ManofLetters[m]> | but I'm expecting all kinds of problems, e.g., conversions required |
| 2023-06-03 19:46:32 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 19:47:33 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2023-06-03 19:50:00 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 19:50:13 +0200 | tabemann | (~tabemann@2600:1700:7990:24e0:46da:fe37:6ffd:b2b9) |
| 2023-06-03 19:51:39 +0200 | somerandomnick[m | (~somerando@2001:470:69fc:105::3:4f2e) (Ping timeout: 265 seconds) |
| 2023-06-03 19:51:39 +0200 | SeanKing[m] | (~seankingm@2001:470:69fc:105::cf9c) (Ping timeout: 265 seconds) |
| 2023-06-03 19:52:08 +0200 | VarikValefor[m] | (~varikvale@2001:470:69fc:105::a5d) (Ping timeout: 265 seconds) |
| 2023-06-03 19:52:37 +0200 | hsiktas[m] | (~hsiktasm]@2001:470:69fc:105::30d4) (Ping timeout: 265 seconds) |
| 2023-06-03 19:56:32 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 19:59:07 +0200 | nate2 | (~nate@98.45.169.16) |
| 2023-06-03 19:59:51 +0200 | nek0 | (~nek0@2a01:4f8:222:2b41::12) (Quit: The Lounge - https://thelounge.chat) |
| 2023-06-03 20:00:02 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 20:03:19 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-06-03 20:03:37 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2023-06-03 20:06:04 +0200 | VarikValefor[m] | (~varikvale@2001:470:69fc:105::a5d) |
| 2023-06-03 20:06:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 20:09:42 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 20:14:25 +0200 | wroathe | (~wroathe@50.205.197.50) |
| 2023-06-03 20:14:25 +0200 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2023-06-03 20:14:25 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-06-03 20:16:56 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 20:16:56 +0200 | taupiqueur | (~taupiqueu@2a02-842a-8180-4601-c87a-3932-439e-c5a6.rev.sfr.net) (Quit: WeeChat 3.8) |
| 2023-06-03 20:17:52 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 20:18:36 +0200 | nek0 | (~nek0@2a01:4f8:222:2b41::12) |
| 2023-06-03 20:21:28 +0200 | michalz | (~michalz@185.246.207.200) |
| 2023-06-03 20:22:19 +0200 | <c_wraith> | is it just me, or does doing anything interesting with ContT require using the constructor manually? All the helper functions seem to be too type-restricted |
| 2023-06-03 20:24:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 20:26:38 +0200 | cheater_ | (~Username@user/cheater) |
| 2023-06-03 20:27:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 20:28:05 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 240 seconds) |
| 2023-06-03 20:28:13 +0200 | cheater_ | cheater |
| 2023-06-03 20:30:37 +0200 | wroathe | (~wroathe@user/wroathe) (Quit: Lost terminal) |
| 2023-06-03 20:33:10 +0200 | wroathe | (~wroathe@50.205.197.50) |
| 2023-06-03 20:33:10 +0200 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2023-06-03 20:33:10 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-06-03 20:34:04 +0200 | <monochrom> | Sometimes callCC is interesting enough for me. But otherwise I would use ContT directly too. |
| 2023-06-03 20:34:25 +0200 | <monochrom> | ContT and runContT as full-power shift and reset. |
| 2023-06-03 20:35:47 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) |
| 2023-06-03 20:38:32 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 20:39:42 +0200 | <c_wraith> | Ah, I see. Anything implemented in terms of MonadCont isn't allowed to touch the r type. That's why it's so restrictive |
| 2023-06-03 20:43:06 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 20:45:08 +0200 | Guest7839 | (sid22336@id-22336.hampstead.irccloud.com) () |
| 2023-06-03 20:45:26 +0200 | Guest7839 | (sid22336@id-22336.hampstead.irccloud.com) |
| 2023-06-03 20:46:10 +0200 | wroathe | (~wroathe@user/wroathe) (Quit: leaving) |
| 2023-06-03 20:47:23 +0200 | Guest7839 | (sid22336@id-22336.hampstead.irccloud.com) (Changing host) |
| 2023-06-03 20:47:23 +0200 | Guest7839 | (sid22336@user/amir) |
| 2023-06-03 20:49:48 +0200 | Guest7839 | (sid22336@user/amir) (Client Quit) |
| 2023-06-03 20:50:13 +0200 | Guest7839 | (sid22336@id-22336.hampstead.irccloud.com) |
| 2023-06-03 20:50:58 +0200 | Guest7839 | (sid22336@id-22336.hampstead.irccloud.com) (Changing host) |
| 2023-06-03 20:50:58 +0200 | Guest7839 | (sid22336@user/amir) |
| 2023-06-03 20:51:20 +0200 | <dolio> | MonadCont also only has callCC in it, so... |
| 2023-06-03 20:51:44 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 20:51:57 +0200 | Guest7839 | amir |
| 2023-06-03 20:52:08 +0200 | cheater_ | (~Username@user/cheater) |
| 2023-06-03 20:52:14 +0200 | amir | (sid22336@user/amir) (Client Quit) |
| 2023-06-03 20:52:29 +0200 | <c_wraith> | callCC has a broken type in a separate way than not being able to touch the r in ContT r m |
| 2023-06-03 20:52:29 +0200 | amir | (sid22336@user/amir) |
| 2023-06-03 20:52:55 +0200 | <dolio> | Yeah, what I mean is, you can't really do shift/reset with just callCC. |
| 2023-06-03 20:52:57 +0200 | <c_wraith> | it's just that the non-broken version is higher-rank |
| 2023-06-03 20:54:25 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 240 seconds) |
| 2023-06-03 20:54:33 +0200 | cheater_ | cheater |
| 2023-06-03 20:58:46 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-06-03 21:00:05 +0200 | <dolio> | That's more of a mere annoyance these days, no? |
| 2023-06-03 21:00:48 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 21:00:54 +0200 | <dolio> | :t \(e :: (forall b. a -> f b) -> f a) -> callCC (\k -> e (\x -> vacuous $ k x)) |
| 2023-06-03 21:00:55 +0200 | <lambdabot> | MonadCont f => ((forall b. a -> f b) -> f a) -> f a |
| 2023-06-03 21:05:07 +0200 | vandita | (~vandit@85-238-93-47.pool.digikabel.hu) (Ping timeout: 240 seconds) |
| 2023-06-03 21:06:55 +0200 | vandita | (~vandit@92-249-150-149.static.digikabel.hu) |
| 2023-06-03 21:07:52 +0200 | <c_wraith> | sure, you can work around it.. but you shouldn't need to |
| 2023-06-03 21:08:59 +0200 | maerwald[m] | (~maerwaldm@2001:470:69fc:105::1ee) (Ping timeout: 265 seconds) |
| 2023-06-03 21:09:25 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-c87a-3932-439e-c5a6.rev.sfr.net) (Remote host closed the connection) |
| 2023-06-03 21:09:57 +0200 | elevenkb | (~elevenkb@2001:470:69fc:105::2:cb89) (Ping timeout: 265 seconds) |
| 2023-06-03 21:09:57 +0200 | marinelli[m] | (~marinelli@2001:470:69fc:105::2d8) (Ping timeout: 265 seconds) |
| 2023-06-03 21:10:13 +0200 | <texasmynsted> | I gather from googling that the answer might be servent-client or wreq... |
| 2023-06-03 21:10:26 +0200 | ozkutuk[m] | (~ozkutuk@2001:470:69fc:105::2:9af8) (Ping timeout: 265 seconds) |
| 2023-06-03 21:10:41 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-c87a-3932-439e-c5a6.rev.sfr.net) |
| 2023-06-03 21:10:56 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 21:11:01 +0200 | <texasmynsted> | I want the quickest, simplest way to build clients for various REST APIs to build keyboard macros etc. |
| 2023-06-03 21:13:07 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2023-06-03 21:13:59 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-06-03 21:14:31 +0200 | pavonia | (~user@user/siracusa) |
| 2023-06-03 21:15:16 +0200 | Deide | (~deide@user/deide) (Ping timeout: 265 seconds) |
| 2023-06-03 21:15:16 +0200 | alanz | (~alanzmatr@2001:470:69fc:105::2:49a6) (Ping timeout: 265 seconds) |
| 2023-06-03 21:15:16 +0200 | ericson2314 | (~ericson23@2001:470:69fc:105::70c) (Ping timeout: 265 seconds) |
| 2023-06-03 21:15:45 +0200 | ManofLetters[m] | (~manoflett@2001:470:69fc:105::3be) (Ping timeout: 265 seconds) |
| 2023-06-03 21:16:14 +0200 | neohtetxyz[m] | (~neohtetxy@2001:470:69fc:105::3:314c) (Ping timeout: 265 seconds) |
| 2023-06-03 21:16:14 +0200 | jmcantrell | (~jmcantrel@user/jmcantrell) (Ping timeout: 265 seconds) |
| 2023-06-03 21:16:43 +0200 | levin[m] | (~levinlevi@2001:470:69fc:105::3:5f68) (Ping timeout: 265 seconds) |
| 2023-06-03 21:16:43 +0200 | bgamari[m] | (~bgamari@2001:470:69fc:105::c7b9) (Ping timeout: 265 seconds) |
| 2023-06-03 21:16:43 +0200 | JensPetersen[m] | (~juhp@2001:470:69fc:105::6e9) (Ping timeout: 265 seconds) |
| 2023-06-03 21:18:10 +0200 | romes[m] | (~romesmatr@2001:470:69fc:105::2:1660) (Ping timeout: 265 seconds) |
| 2023-06-03 21:18:10 +0200 | geekosaur[m] | (~geekosaur@xmonad/geekosaur) (Ping timeout: 265 seconds) |
| 2023-06-03 21:18:39 +0200 | alexfmpe[m] | (~alexfmpem@2001:470:69fc:105::38ba) (Ping timeout: 265 seconds) |
| 2023-06-03 21:19:08 +0200 | Las[m]1 | (~lasmatrix@2001:470:69fc:105::74e) (Ping timeout: 265 seconds) |
| 2023-06-03 21:19:37 +0200 | smichel17[m] | (~smichel17@2001:470:69fc:105::2d32) (Ping timeout: 265 seconds) |
| 2023-06-03 21:21:33 +0200 | nomagno | (~nomagno@2001:470:69fc:105::c1f0) (Ping timeout: 265 seconds) |
| 2023-06-03 21:22:24 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 2023-06-03 21:23:00 +0200 | Artem[m] | (~artemtype@2001:470:69fc:105::75b) (Ping timeout: 265 seconds) |
| 2023-06-03 21:24:06 +0200 | systemhalted | (~systemhal@199.sub-174-197-65.myvzw.com) |
| 2023-06-03 21:24:19 +0200 | nomagno | (~nomagno@2001:470:69fc:105::c1f0) |
| 2023-06-03 21:24:23 +0200 | systemhalted | (~systemhal@199.sub-174-197-65.myvzw.com) (Max SendQ exceeded) |
| 2023-06-03 21:26:52 +0200 | chreekat | (~chreekat@2001:470:69fc:105::16b5) (Ping timeout: 265 seconds) |
| 2023-06-03 21:26:53 +0200 | systemhalted | (~systemhal@199.sub-174-197-65.myvzw.com) |
| 2023-06-03 21:27:15 +0200 | systemhalted | (~systemhal@199.sub-174-197-65.myvzw.com) (Max SendQ exceeded) |
| 2023-06-03 21:27:51 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 21:28:37 +0200 | vandita | (~vandit@92-249-150-149.static.digikabel.hu) (Ping timeout: 240 seconds) |
| 2023-06-03 21:30:46 +0200 | vandita | (~vandit@178-164-188-71.pool.digikabel.hu) |
| 2023-06-03 21:31:52 +0200 | cheater_ | (~Username@user/cheater) |
| 2023-06-03 21:32:28 +0200 | chreekat | (~chreekat@2001:470:69fc:105::16b5) |
| 2023-06-03 21:33:54 +0200 | neohtetxyz[m] | (~neohtetxy@2001:470:69fc:105::3:314c) |
| 2023-06-03 21:34:05 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 250 seconds) |
| 2023-06-03 21:34:07 +0200 | cheater_ | cheater |
| 2023-06-03 21:34:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 21:34:42 +0200 | ericson2314 | (~ericson23@2001:470:69fc:105::70c) |
| 2023-06-03 21:35:09 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 21:35:18 +0200 | JensPetersen[m] | (~juhp@2001:470:69fc:105::6e9) |
| 2023-06-03 21:35:26 +0200 | jmcantrell | (~jmcantrel@user/jmcantrell) |
| 2023-06-03 21:36:34 +0200 | bgamari[m] | (~bgamari@2001:470:69fc:105::c7b9) |
| 2023-06-03 21:37:54 +0200 | mokee | (~mokee@37.228.215.134) (Remote host closed the connection) |
| 2023-06-03 21:45:08 +0200 | smichel17[m] | (~smichel17@2001:470:69fc:105::2d32) |
| 2023-06-03 21:46:45 +0200 | Las[m]1 | (~lasmatrix@2001:470:69fc:105::74e) |
| 2023-06-03 21:47:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 21:47:30 +0200 | chreekat | (~chreekat@2001:470:69fc:105::16b5) (Remote host closed the connection) |
| 2023-06-03 21:51:04 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 21:54:29 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-06-03 21:55:59 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 21:56:00 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2023-06-03 21:56:23 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 265 seconds) |
| 2023-06-03 21:56:30 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2023-06-03 21:57:26 +0200 | taupiqueur | (~taupiqueu@2a02-842a-8180-4601-c87a-3932-439e-c5a6.rev.sfr.net) |
| 2023-06-03 21:59:45 +0200 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) |
| 2023-06-03 22:00:19 +0200 | Artem[m] | (~artemtype@2001:470:69fc:105::75b) |
| 2023-06-03 22:00:22 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-06-03 22:02:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 22:02:40 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Ping timeout: 248 seconds) |
| 2023-06-03 22:05:03 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 2023-06-03 22:05:32 +0200 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 268 seconds) |
| 2023-06-03 22:12:17 +0200 | chreekat | (~chreekat@2001:470:69fc:105::16b5) |
| 2023-06-03 22:19:56 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 22:21:22 +0200 | wroathe | (~wroathe@50.205.197.50) |
| 2023-06-03 22:21:22 +0200 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2023-06-03 22:21:22 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-06-03 22:25:52 +0200 | taupiqueur | (~taupiqueu@2a02-842a-8180-4601-c87a-3932-439e-c5a6.rev.sfr.net) (Quit: WeeChat 3.8) |
| 2023-06-03 22:28:21 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-c87a-3932-439e-c5a6.rev.sfr.net) (Remote host closed the connection) |
| 2023-06-03 22:28:22 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Remote host closed the connection) |
| 2023-06-03 22:28:45 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 22:32:31 +0200 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-06-03 22:34:35 +0200 | <Profpatsch> | newtype Foo from to = Foo ((Context, from) -> Either Error (Context, to)) |
| 2023-06-03 22:34:44 +0200 | <Profpatsch> | ^ I can implement a Semigroup instance for this |
| 2023-06-03 22:35:26 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2023-06-03 22:35:53 +0200 | <Profpatsch> | *Semigroupoid; but passing through the context manually is kinda annyoing; is there a better way to write the type? |
| 2023-06-03 22:36:19 +0200 | <Profpatsch> | The semigroupoid instance doesn’t even touch the Context, it just passes it on |
| 2023-06-03 22:37:44 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 22:39:31 +0200 | <jade[m]> | Profpatsch: how does it vary from the instance that could be derived (`instance Semigroup b => Semigroup (a -> b)` and `instance Semigroup (Either a b)` |
| 2023-06-03 22:39:32 +0200 | <Profpatsch> | I’m experimenting with writing parsers in a Categorical way |
| 2023-06-03 22:39:42 +0200 | <Profpatsch> | jade[m]: Semigroupoid |
| 2023-06-03 22:39:47 +0200 | <Profpatsch> | not semigroup |
| 2023-06-03 22:39:47 +0200 | <jade[m]> | * a b)`)? |
| 2023-06-03 22:39:49 +0200 | <jade[m]> | ahhh |
| 2023-06-03 22:39:50 +0200 | <Profpatsch> | i.e. Category without id |
| 2023-06-03 22:39:54 +0200 | <Profpatsch> | sorry, my mistake :) |
| 2023-06-03 22:40:22 +0200 | <Profpatsch> | So you get Parser from to e.g. jsonString :: Parser Value Text |
| 2023-06-03 22:41:06 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 22:41:56 +0200 | <Profpatsch> | jade[m]: kinda what I did in https://hackage.haskell.org/package/pa-field-parser-0.1.0.1#readme but generalized to more complicated structures like XML |
| 2023-06-03 22:42:04 +0200 | taupiqueur | (~taupiqueu@2a02:842a:8180:4601:39fb:294e:6171:ad18) |
| 2023-06-03 22:42:19 +0200 | <jade[m]> | interesting |
| 2023-06-03 22:42:34 +0200 | <Profpatsch> | In particular going towards a sensible Applicative/Selective instance for combining these |
| 2023-06-03 22:42:41 +0200 | <jade[m]> | im not as caught up on tge category theory stuff as I should be |
| 2023-06-03 22:42:47 +0200 | <Profpatsch> | And adding parsing context like the path to the thing that you are parsing |
| 2023-06-03 22:43:03 +0200 | <Profpatsch> | jade[m]: I have no idea about category, it’s just what the class is called :P |
| 2023-06-03 22:43:10 +0200 | <Profpatsch> | *about category theory |
| 2023-06-03 22:43:15 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-39fb-294e-6171-ad18.rev.sfr.net) |
| 2023-06-03 22:43:38 +0200 | <jade[m]> | haha ok |
| 2023-06-03 22:43:47 +0200 | <Profpatsch> | like, I’m working my way from the concrete to the abstract not the other way around if that0s what you mean |
| 2023-06-03 22:43:49 +0200 | <jade[m]> | I would like to know about category theory I should say |
| 2023-06-03 22:44:13 +0200 | <Profpatsch> | things only make sense to me that way, coming from a practical problem |
| 2023-06-03 22:44:17 +0200 | <jade[m]> | Profpatsch: that's how I work most of the time too |
| 2023-06-03 22:45:15 +0200 | <Profpatsch> | jade[m]: the specific parser is here: https://code.tvl.fyi/tree/users/Profpatsch/netencode/Netencode/Parse.hs#n30 |
| 2023-06-03 22:45:26 +0200 | <Profpatsch> | And I’m thinking about how to solve that TODO |
| 2023-06-03 22:45:28 +0200 | <jade[m]> | cool! |
| 2023-06-03 22:45:39 +0200 | Guest38 | (~Guest18@host-091-097-060-051.ewe-ip-backbone.de) |
| 2023-06-03 22:45:43 +0200 | <Profpatsch> | maybe it’s not even a big thing, maybe it’s a fundamental insight I’m missing here |
| 2023-06-03 22:46:06 +0200 | <Profpatsch> | passing some extra info “along” … hm … that sounds very Arrow-y now that I think about it |
| 2023-06-03 22:46:08 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 240 seconds) |
| 2023-06-03 22:46:16 +0200 | chromoblob | (~user@37.113.158.8) |
| 2023-06-03 22:46:21 +0200 | <Profpatsch> | I mean I can get it done just doing what I did here |
| 2023-06-03 22:46:56 +0200 | <Profpatsch> | This is very much inspired by https://hackage.haskell.org/package/aeson-better-errors but adding a second type parameter so that I can get it to be Category |
| 2023-06-03 22:47:10 +0200 | <Profpatsch> | tbd whether it makes parsing easier |
| 2023-06-03 22:47:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 22:47:24 +0200 | Guest38 | (~Guest18@host-091-097-060-051.ewe-ip-backbone.de) (Client Quit) |
| 2023-06-03 22:48:40 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-06-03 22:48:55 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-39fb-294e-6171-ad18.rev.sfr.net) (Remote host closed the connection) |
| 2023-06-03 22:49:16 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-39fb-294e-6171-ad18.rev.sfr.net) |
| 2023-06-03 22:49:42 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2023-06-03 22:49:59 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2023-06-03 22:50:02 +0200 | <ncf> | not sure i understand what part of your code you want to simplify? |
| 2023-06-03 22:50:47 +0200 | <Profpatsch> | ncf: manually passing through [Text] from the left to the right of my Kleisli |
| 2023-06-03 22:50:59 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 22:51:06 +0200 | <ncf> | where? |
| 2023-06-03 22:51:12 +0200 | <Profpatsch> | ncf: https://code.tvl.fyi/tree/users/Profpatsch/netencode/Netencode/Parse.hs#n33 |
| 2023-06-03 22:51:27 +0200 | chromoblob | (~user@37.113.158.8) (Ping timeout: 265 seconds) |
| 2023-06-03 22:51:44 +0200 | <ncf> | but yeah, `second` would probably help |
| 2023-06-03 22:51:51 +0200 | <Profpatsch> | It’s essentially a daat Foo a b = Kleisli (Validation …) ([Text], a) ([Text], b) |
| 2023-06-03 22:52:09 +0200 | <ncf> | you mean you want to simplify the type itself? |
| 2023-06-03 22:52:26 +0200 | <Profpatsch> | Maybe? Not sure lol |
| 2023-06-03 22:52:46 +0200 | <Profpatsch> | If it were just Monad I’d make it into a Writer cause I’m only ever adding elements to the list |
| 2023-06-03 22:52:59 +0200 | <Profpatsch> | but since this is Category I have to pass it from the left to the right hrm |
| 2023-06-03 22:53:33 +0200 | <ncf> | do you? |
| 2023-06-03 22:54:12 +0200 | <Profpatsch> | so essentially I want to say key "foo" >>> key "bar" and have the [Text] be ["foo", "bar"] |
| 2023-06-03 22:54:17 +0200 | <ncf> | what's wrong with Kleisli (Compose (Writer [Text]) (Validation …)) ? |
| 2023-06-03 22:54:43 +0200 | <ncf> | (or WriterT) |
| 2023-06-03 22:56:17 +0200 | <EvanR> | <<< is a thing |
| 2023-06-03 22:56:36 +0200 | <Profpatsch> | The way I do it is generate the error messages in case of Failure, and use the context in the error messages |
| 2023-06-03 22:57:17 +0200 | <ncf> | so have Writer on the outside |
| 2023-06-03 22:57:20 +0200 | <Profpatsch> | So the writer is not global in my m, but rather needs to be locally available within the thingies |
| 2023-06-03 22:57:35 +0200 | <ncf> | hmm |
| 2023-06-03 23:00:05 +0200 | <Profpatsch> | So I’m essentially building a difference list which is available at the leaves of parsing as an input in case of error but will be passed on to the next nesting level in case of success. |
| 2023-06-03 23:00:25 +0200 | <Profpatsch> | And in case the whole parse succeeds, it’s just thrown away. |
| 2023-06-03 23:00:58 +0200 | <ncf> | if you want something of type Parse (Either Error to) to , i think you have no choice but to use state instead of writer... but shouldn't that be Parse from (Either Error to) -> Parse from to ? |
| 2023-06-03 23:01:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 23:02:07 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 23:06:10 +0200 | <Profpatsch> | Meh, maybe there is no good abstraction for this |
| 2023-06-03 23:06:22 +0200 | <Profpatsch> | I’m not sure about the current form of the parser |
| 2023-06-03 23:09:30 +0200 | ddellacosta | (~ddellacos@146.70.165.162) |
| 2023-06-03 23:11:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 23:15:04 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 23:19:04 +0200 | <monochrom> | "State = ReaderT Writer" is a poor model, and it shows. |
| 2023-06-03 23:20:31 +0200 | <monochrom> | Also why mathematicians know when to be careful and write "(Integer, +, 0) is a monoid" not just "Integer is a monoid". |
| 2023-06-03 23:21:24 +0200 | <monochrom> | How the operators behave is more important than what elements are in the set. |
| 2023-06-03 23:22:30 +0200 | SeanKing[m] | (~seankingm@2001:470:69fc:105::cf9c) |
| 2023-06-03 23:23:21 +0200 | vandita | (~vandit@178-164-188-71.pool.digikabel.hu) (Ping timeout: 265 seconds) |
| 2023-06-03 23:23:31 +0200 | <Profpatsch> | monochrom: that’s not a thing you can say, the definition of an algebra is „a set with some operations that observe laws“ |
| 2023-06-03 23:23:31 +0200 | alanz | (~alanz@2001:470:69fc:105::2:49a6) |
| 2023-06-03 23:23:32 +0200 | Christoph[m] | (~hpotsirhc@2001:470:69fc:105::2ff8) |
| 2023-06-03 23:24:40 +0200 | <Profpatsch> | But yeah, I get what you mean :) |
| 2023-06-03 23:24:47 +0200 | Deide | (~deide@user/deide) |
| 2023-06-03 23:25:01 +0200 | vandita | (~vandit@178-164-188-116.pool.digikabel.hu) |
| 2023-06-03 23:25:38 +0200 | <monochrom> | This is why (State, State's pure, State's >>=) ≠ (ReaderT Writer, ReaderT Writer's pure, ReaderT Writer's >>=), as I said. |
| 2023-06-03 23:26:03 +0200 | ManofLetters[m] | (~manoflett@2001:470:69fc:105::3be) |
| 2023-06-03 23:26:42 +0200 | <ncf> | why did you bring that up? |
| 2023-06-03 23:26:48 +0200 | romes[m] | (~romesmatr@2001:470:69fc:105::2:1660) |
| 2023-06-03 23:26:48 +0200 | alexfmpe[m] | (~alexfmpem@2001:470:69fc:105::38ba) |
| 2023-06-03 23:26:48 +0200 | elevenkb | (~elevenkb@2001:470:69fc:105::2:cb89) |
| 2023-06-03 23:27:11 +0200 | <monochrom> | I think you were discussing that? |
| 2023-06-03 23:27:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 23:27:35 +0200 | marinelli[m] | (~marinelli@2001:470:69fc:105::2d8) |
| 2023-06-03 23:27:36 +0200 | maerwald[m] | (~maerwaldm@2001:470:69fc:105::1ee) |
| 2023-06-03 23:27:36 +0200 | hsiktas[m] | (~hsiktasm]@2001:470:69fc:105::30d4) |
| 2023-06-03 23:29:16 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-06-03 23:29:42 +0200 | <ncf> | i said state because i think that is what we want here, as opposed to reader-writer, but i'm a bit fuzzy about the whole thing |
| 2023-06-03 23:29:43 +0200 | <Profpatsch> | does abstract algebra even have an “higher-kinded” things |
| 2023-06-03 23:29:50 +0200 | <Profpatsch> | or is that squarely category theory |
| 2023-06-03 23:30:06 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 23:30:59 +0200 | <Profpatsch> | Hm, I guess that’s up for debate |
| 2023-06-03 23:31:17 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-06-03 23:31:37 +0200 | <Profpatsch> | The terminology turns extremely categor-y once you look at articles like https://en.wikipedia.org/wiki/Semigroupoid |
| 2023-06-03 23:36:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 23:36:22 +0200 | geekosaur[m] | (~geekosaur@xmonad/geekosaur) |
| 2023-06-03 23:37:08 +0200 | somerandomnick[m | (~somerando@2001:470:69fc:105::3:4f2e) |
| 2023-06-03 23:40:00 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 23:41:55 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Remote host closed the connection) |
| 2023-06-03 23:42:18 +0200 | reach | (~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) |
| 2023-06-03 23:42:37 +0200 | ddellacosta | (~ddellacos@146.70.165.162) (Ping timeout: 240 seconds) |
| 2023-06-03 23:43:33 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-39fb-294e-6171-ad18.rev.sfr.net) (Remote host closed the connection) |
| 2023-06-03 23:43:49 +0200 | taupiqueur | (~taupiqueu@2a02:842a:8180:4601:39fb:294e:6171:ad18) (Quit: WeeChat 3.8) |
| 2023-06-03 23:51:29 +0200 | biberu | (~biberu@user/biberu) (Read error: Connection reset by peer) |
| 2023-06-03 23:51:44 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-03 23:55:23 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-03 23:55:27 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-06-03 23:56:27 +0200 | biberu | (~biberu@user/biberu) |
| 2023-06-03 23:58:01 +0200 | acidjnk | (~acidjnk@p200300d6e7072f454588bfb78dd6f620.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2023-06-03 23:58:29 +0200 | acidjnk | (~acidjnk@p200300d6e7072f45584b05120c40d8b9.dip0.t-ipconnect.de) |