| 2025-02-10 00:01:07 +0100 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) myxokephale |
| 2025-02-10 00:04:25 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-10 00:07:36 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2025-02-10 00:07:36 +0100 | ljdarj1 | ljdarj |
| 2025-02-10 00:09:29 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 00:12:00 +0100 | xff0x | (~xff0x@2405:6580:b080:900:a75:2366:4e5c:4ce9) (Ping timeout: 246 seconds) |
| 2025-02-10 00:13:10 +0100 | xff0x | (~xff0x@2405:6580:b080:900:f1ee:cf4b:ec98:147a) |
| 2025-02-10 00:13:48 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-10 00:16:00 +0100 | xff0x | (~xff0x@2405:6580:b080:900:f1ee:cf4b:ec98:147a) (Client Quit) |
| 2025-02-10 00:18:55 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Remote host closed the connection) |
| 2025-02-10 00:28:37 +0100 | xff0x | (~xff0x@2405:6580:b080:900:f597:997a:28cf:fd48) |
| 2025-02-10 00:32:48 +0100 | robertm | (robertm@lattice.rojoma.com) (Quit: WeeChat 3.8) |
| 2025-02-10 00:35:15 +0100 | robertm | (robertm@lattice.rojoma.com) robertm |
| 2025-02-10 00:55:17 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@static-198-54-134-151.cust.tzulo.com) Jeanne-Kamikaze |
| 2025-02-10 00:57:54 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 01:00:30 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2025-02-10 01:00:55 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 01:01:11 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Read error: Connection reset by peer) |
| 2025-02-10 01:02:03 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-02-10 01:02:17 +0100 | zaz | (~zaz@195.89.33.222) |
| 2025-02-10 01:04:36 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2025-02-10 01:12:36 +0100 | xff0x_ | (~xff0x@2405:6580:b080:900:37f4:5b69:766f:630) |
| 2025-02-10 01:15:04 +0100 | xff0x | (~xff0x@2405:6580:b080:900:f597:997a:28cf:fd48) (Ping timeout: 265 seconds) |
| 2025-02-10 01:16:57 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Remote host closed the connection) |
| 2025-02-10 01:17:57 +0100 | MyNetAz | (~MyNetAz@user/MyNetAz) (Remote host closed the connection) |
| 2025-02-10 01:19:04 +0100 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-02-10 01:20:24 +0100 | img | (~img@user/img) img |
| 2025-02-10 01:24:49 +0100 | otbergsten | (~otbergste@user/otbergsten) (Remote host closed the connection) |
| 2025-02-10 01:24:58 +0100 | MyNetAz | (~MyNetAz@user/MyNetAz) MyNetAz |
| 2025-02-10 01:25:01 +0100 | zaz | Zaz_ |
| 2025-02-10 01:31:34 +0100 | xff0x_ | (~xff0x@2405:6580:b080:900:37f4:5b69:766f:630) (Ping timeout: 268 seconds) |
| 2025-02-10 01:31:35 +0100 | xff0x | (~xff0x@2405:6580:b080:900:7b94:8fe8:c4af:8544) |
| 2025-02-10 01:34:17 +0100 | <Zaz_> | ncf Thanks a lot! Am I correct in thinking that it would be bijective if the codomain was the pair of strings where the first character of the second string is not lower case? Is this something that can be modelled in Haskell? E.g. with refined? |
| 2025-02-10 01:34:18 +0100 | <Zaz_> | Are you referring to Control.Lens.Iso? Is there any reason not to work with lenses? Or are they the best tool we have for implementing bijective programs? |
| 2025-02-10 01:36:57 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-10 01:39:49 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 248 seconds) |
| 2025-02-10 01:39:49 +0100 | ljdarj1 | ljdarj |
| 2025-02-10 01:42:46 +0100 | causal | (~eric@50.35.84.231) causal |
| 2025-02-10 01:46:59 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 01:48:57 +0100 | xff0x | (~xff0x@2405:6580:b080:900:7b94:8fe8:c4af:8544) (Ping timeout: 252 seconds) |
| 2025-02-10 01:50:15 +0100 | Axman6 | (~Axman6@user/axman6) Axman6 |
| 2025-02-10 01:51:13 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
| 2025-02-10 01:56:47 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 01:58:07 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@static-198-54-134-151.cust.tzulo.com) (Quit: Leaving) |
| 2025-02-10 02:01:47 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Ping timeout: 268 seconds) |
| 2025-02-10 02:03:59 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-02-10 02:07:24 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 264 seconds) |
| 2025-02-10 02:10:19 +0100 | Googulator | (~Googulato@2a01-036d-0106-4074-758c-12a1-cbb4-05eb.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-02-10 02:12:13 +0100 | sprotte24 | (~sprotte24@p200300d16f25850039a3b2714e26a8e3.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2025-02-10 02:15:01 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f26c4dbaee3a15423f1.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-02-10 02:18:56 +0100 | zenstoic | (uid461840@id-461840.hampstead.irccloud.com) zenstoic |
| 2025-02-10 02:19:07 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-02-10 02:23:40 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 02:27:31 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-10 02:28:16 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-02-10 02:28:16 +0100 | tnt2 | tnt1 |
| 2025-02-10 02:32:18 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-02-10 02:34:31 +0100 | califax | (~califax@user/califx) califx |
| 2025-02-10 02:35:04 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 02:36:25 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-02-10 02:39:29 +0100 | KicksonButt | (~quassel@187.21.174.221) |
| 2025-02-10 02:39:33 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-10 02:55:24 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
| 2025-02-10 02:57:13 +0100 | KicksonButt | (~quassel@187.21.174.221) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2025-02-10 03:11:13 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-02-10 03:16:46 +0100 | pabs3 | (~pabs3@user/pabs3) (Read error: Connection reset by peer) |
| 2025-02-10 03:17:50 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2025-02-10 03:23:54 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 272 seconds) |
| 2025-02-10 03:24:09 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 03:24:49 +0100 | user363627 | (~user@user/user363627) user363627 |
| 2025-02-10 03:28:44 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-02-10 03:28:53 +0100 | weary-traveler | (~user@user/user363627) (Ping timeout: 244 seconds) |
| 2025-02-10 03:45:38 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2025-02-10 03:47:58 +0100 | <tri> | https://paste.tomsmeding.com/G0FDnu6f |
| 2025-02-10 03:48:36 +0100 | <tri> | I'm confused about the second function, how can handle still be referenced by hClose? It's already outside the lambda |
| 2025-02-10 03:49:27 +0100 | <tri> | in my first solution the second bind function >>= and >> is nested inside the lambda, so it makes sense handle is visible there |
| 2025-02-10 03:49:32 +0100 | <Leary> | No, those functions are exactly the same, only the formatting differs. |
| 2025-02-10 03:51:45 +0100 | <tri> | you mean the second function is nested >>= and >> in the lambda? |
| 2025-02-10 03:51:57 +0100 | <tri> | nesting* |
| 2025-02-10 03:52:24 +0100 | <Leary> | Yes. |
| 2025-02-10 03:54:33 +0100 | <tri> | I don't get it... my thought is >>= \content -> putStrLn content is working off of the result from the block openFile "/tmp/foo.txt" ReadMode >>= \handle -> hGetContents handle |
| 2025-02-10 03:55:16 +0100 | <tri> | but you mean it's only working off of the result of hGetContents handle inside the lambda |
| 2025-02-10 03:55:55 +0100 | <Leary> | There is no block. You can indent or unindent those lines as much as you want; Haskell doesn't care. |
| 2025-02-10 03:56:16 +0100 | <Leary> | Well, so long as you don't touch the top level. |
| 2025-02-10 03:57:07 +0100 | <monochrom> | Every lambda extends to the right as much as is legal. |
| 2025-02-10 03:58:11 +0100 | <tri> | https://paste.tomsmeding.com/t5ptrR9w |
| 2025-02-10 03:58:46 +0100 | <tri> | that's my mental model, but apparently that's wrong, and I'm still confused. I need to think a bit more... |
| 2025-02-10 03:59:10 +0100 | <monochrom> | It is a tautology that all confusions come from wrong models. |
| 2025-02-10 04:00:05 +0100 | <monochrom> | You attached too much meaning to indentation. At present, you are just formatting "\h -> foo >>= bar >> hClose h" in two ways that only humans see a difference. |
| 2025-02-10 04:01:46 +0100 | <geekosaur> | indentation does have meaning to Haskell, but only under certain conditions |
| 2025-02-10 04:02:01 +0100 | <geekosaur> | in particular, it is introduced by specifc keywords (let, where, case, do) |
| 2025-02-10 04:03:48 +0100 | <tri> | https://paste.tomsmeding.com/esi2Te6Q |
| 2025-02-10 04:05:57 +0100 | <tri> | I thought >>= will take everything before it as a single something, and feed it into the second param |
| 2025-02-10 04:07:28 +0100 | <monochrom> | Haskell is not a shell script language. |
| 2025-02-10 04:08:35 +0100 | <Leary> | `>>=` is just an operator, not special syntax. `\ <vars> -> <body>`, on the other hand, is. It wins. |
| 2025-02-10 04:09:58 +0100 | potatoespotatoes | (~quassel@user/potatoespotatoes) (Ping timeout: 245 seconds) |
| 2025-02-10 04:10:40 +0100 | potatoespotatoes | (~quassel@130.44.147.204) |
| 2025-02-10 04:10:40 +0100 | potatoespotatoes | (~quassel@130.44.147.204) (Changing host) |
| 2025-02-10 04:10:40 +0100 | potatoespotatoes | (~quassel@user/potatoespotatoes) potatoespotatoes |
| 2025-02-10 04:11:36 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-02-10 04:12:15 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 04:14:28 +0100 | <tri> | https://paste.tomsmeding.com/DHEbn4x0 |
| 2025-02-10 04:15:17 +0100 | <tri> | So I understand how handle is visible to hClose now, it's just the non-indentation throws me off |
| 2025-02-10 04:15:50 +0100 | user363627 | (~user@user/user363627) (Ping timeout: 272 seconds) |
| 2025-02-10 04:16:48 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 265 seconds) |
| 2025-02-10 04:19:04 +0100 | <tri> | thank you everyone |
| 2025-02-10 04:19:38 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Remote host closed the connection) |
| 2025-02-10 04:22:34 +0100 | <mauke> | https://paste.tomsmeding.com/EUvPtmbm |
| 2025-02-10 04:23:20 +0100 | <monochrom> | Haha Excel Haskell |
| 2025-02-10 04:24:43 +0100 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-02-10 04:26:02 +0100 | img | (~img@user/img) img |
| 2025-02-10 04:26:51 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 04:37:41 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Ping timeout: 252 seconds) |
| 2025-02-10 04:37:41 +0100 | Square2 | (~Square@user/square) Square |
| 2025-02-10 04:40:11 +0100 | <cheater> | better Ex than In |
| 2025-02-10 04:44:55 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 04:44:58 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 272 seconds) |
| 2025-02-10 04:57:32 +0100 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) (Ping timeout: 268 seconds) |
| 2025-02-10 04:58:35 +0100 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) Raito_Bezarius |
| 2025-02-10 05:00:03 +0100 | Taneb | (~Taneb@runciman.hacksoc.org) (Quit: I seem to have stopped.) |
| 2025-02-10 05:01:15 +0100 | Taneb | (~Taneb@2001:41c8:51:10d:aaaa:0:aaaa:0) Taneb |
| 2025-02-10 05:01:18 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 05:05:34 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-02-10 05:22:40 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-10 05:28:53 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Remote host closed the connection) |
| 2025-02-10 05:33:25 +0100 | saimazoon | (~hrtz@user/haritz) (Ping timeout: 252 seconds) |
| 2025-02-10 05:37:21 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 05:40:24 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-02-10 05:40:35 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2025-02-10 05:41:40 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich) |
| 2025-02-10 05:42:17 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-10 05:42:40 +0100 | haritz | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) |
| 2025-02-10 05:42:41 +0100 | haritz | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) (Changing host) |
| 2025-02-10 05:42:41 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2025-02-10 05:49:21 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 05:52:37 +0100 | aforemny | (~aforemny@2001:9e8:6cfe:5000:87c7:acaa:b551:71f7) aforemny |
| 2025-02-10 05:52:58 +0100 | aforemny_ | (~aforemny@2001:9e8:6cdf:f800:9bf4:7ea7:4c6a:c80f) (Ping timeout: 265 seconds) |
| 2025-02-10 05:53:37 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-02-10 05:56:44 +0100 | <famubu> | tomsmeding: Thanks for mentioning the LexicalNegation extension. (Sorry been away and forgot to reply). |
| 2025-02-10 06:07:29 +0100 | haritz | (~hrtz@user/haritz) (Ping timeout: 248 seconds) |
| 2025-02-10 06:12:14 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:5d9a:9bab:ee5e:b737) |
| 2025-02-10 06:12:18 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:5d9a:9bab:ee5e:b737) (Changing host) |
| 2025-02-10 06:12:18 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2025-02-10 06:19:33 +0100 | Square2 | (~Square@user/square) (Ping timeout: 268 seconds) |
| 2025-02-10 06:23:38 +0100 | hsw_ | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Quit: Leaving) |
| 2025-02-10 06:23:53 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) hsw |
| 2025-02-10 06:26:26 +0100 | michalz | (~michalz@185.246.207.221) |
| 2025-02-10 06:27:34 +0100 | haritz | (~hrtz@user/haritz) (Ping timeout: 272 seconds) |
| 2025-02-10 06:27:56 +0100 | zenstoic | (uid461840@id-461840.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-02-10 06:28:25 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-10 06:29:57 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 276 seconds) |
| 2025-02-10 06:29:57 +0100 | tnt2 | tnt1 |
| 2025-02-10 06:33:23 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Quit: Leaving) |
| 2025-02-10 06:33:37 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) hsw |
| 2025-02-10 06:36:21 +0100 | Square2 | (~Square4@user/square) Square |
| 2025-02-10 06:36:39 +0100 | <albet70> | is that a->b can be a function type signature? |
| 2025-02-10 06:37:26 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 06:37:40 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Client Quit) |
| 2025-02-10 06:37:54 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) hsw |
| 2025-02-10 06:38:41 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Remote host closed the connection) |
| 2025-02-10 06:38:46 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-02-10 06:38:55 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) hsw |
| 2025-02-10 06:41:38 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-10 06:42:18 +0100 | mhatta_ | (~mhatta@www21123ui.sakura.ne.jp) (Quit: ZNC 1.9.1+deb2+b2 - https://znc.in) |
| 2025-02-10 06:42:33 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Client Quit) |
| 2025-02-10 06:42:59 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) hsw |
| 2025-02-10 06:50:25 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2025-02-10 06:52:54 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:5d9a:9bab:ee5e:b737) |
| 2025-02-10 06:52:57 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:5d9a:9bab:ee5e:b737) (Changing host) |
| 2025-02-10 06:52:57 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2025-02-10 06:57:24 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2025-02-10 06:58:58 +0100 | Anushka | (~Anushka@101.0.63.173) |
| 2025-02-10 06:59:17 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-02-10 07:02:12 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Remote host closed the connection) |
| 2025-02-10 07:02:52 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 07:07:39 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Ping timeout: 268 seconds) |
| 2025-02-10 07:08:31 +0100 | dgip^ | (~dgip@108.192.66.114) |
| 2025-02-10 07:11:22 +0100 | <ski> | huh ? |
| 2025-02-10 07:11:39 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-02-10 07:12:19 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-02-10 07:25:50 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 07:27:10 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) |
| 2025-02-10 07:30:01 +0100 | Axma24393 | (~Axman6@user/axman6) Axman6 |
| 2025-02-10 07:30:02 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-10 07:32:12 +0100 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 240 seconds) |
| 2025-02-10 07:36:07 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
| 2025-02-10 07:39:51 +0100 | <int-e> | albet70: a -> b is the type of a function that takes an argument of type a and returns a result of type b |
| 2025-02-10 07:40:30 +0100 | <int-e> | (and the spaces are technically optional but highly recommended for readability) |
| 2025-02-10 07:40:48 +0100 | <int-e> | anyway. if that wasn't your question, please rephrase. |
| 2025-02-10 07:48:12 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 264 seconds) |
| 2025-02-10 07:49:21 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-02-10 07:50:56 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 07:55:45 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Ping timeout: 268 seconds) |
| 2025-02-10 08:03:21 +0100 | chele | (~chele@user/chele) chele |
| 2025-02-10 08:08:24 +0100 | HappyNewYear2025 | (~newyear@2.219.56.221) (Ping timeout: 244 seconds) |
| 2025-02-10 08:13:54 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 08:17:22 +0100 | Anushka | (~Anushka@101.0.63.173) (Quit: Client closed) |
| 2025-02-10 08:18:13 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-02-10 08:21:36 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f99c4dbaee3a15423f1.dip0.t-ipconnect.de) acidjnk |
| 2025-02-10 08:28:00 +0100 | j1n37- | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-02-10 08:29:23 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-02-10 08:32:25 +0100 | Anushka | (~Anushka@101.0.63.173) |
| 2025-02-10 08:32:59 +0100 | Anushka | (~Anushka@101.0.63.173) (Client Quit) |
| 2025-02-10 08:35:01 +0100 | ft | (~ft@p4fc2a610.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-02-10 08:41:45 +0100 | reidrac | (~reidrac@user/reidrac) (Quit: bye now!) |
| 2025-02-10 08:43:09 +0100 | reidrac | (~reidrac@user/reidrac) reidrac |
| 2025-02-10 08:44:48 +0100 | p3n | (~p3n@217.198.124.246) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-02-10 08:46:36 +0100 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) p3n |
| 2025-02-10 08:48:52 +0100 | dysthesis | (~dysthesis@user/dysthesis) dysthesis |
| 2025-02-10 08:51:45 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2025-02-10 08:52:05 +0100 | haver | (~newyear@2.219.56.221) |
| 2025-02-10 08:55:34 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-02-10 08:58:01 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich) |
| 2025-02-10 09:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-02-10 09:00:06 +0100 | <albet70> | I thought that b as result type must show before |
| 2025-02-10 09:01:31 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-02-10 09:01:38 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 09:01:43 +0100 | <int-e> | :t const undefined |
| 2025-02-10 09:01:44 +0100 | <lambdabot> | b -> a |
| 2025-02-10 09:03:50 +0100 | <ski> | "must show before" ? |
| 2025-02-10 09:04:26 +0100 | <int-e> | @djinn a -> b |
| 2025-02-10 09:04:26 +0100 | <lambdabot> | -- f cannot be realized. |
| 2025-02-10 09:05:03 +0100 | <int-e> | yeah figuring out the question is still a puzzle with insufficient information |
| 2025-02-10 09:05:45 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-10 09:06:13 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 248 seconds) |
| 2025-02-10 09:08:58 +0100 | <albet70> | b must be defined somewhere, f :: a -> Int , is Ok, Int is defined, f :: a-> b -> b is Ok, even f :: a -> m b is Ok, but f :: a -> b is not |
| 2025-02-10 09:09:55 +0100 | <ski> | `a' and `b' there would be type variables, not having a global definition |
| 2025-02-10 09:10:06 +0100 | <ski> | (and ditto for `m') |
| 2025-02-10 09:10:23 +0100 | <albet70> | :t callCC |
| 2025-02-10 09:10:24 +0100 | <lambdabot> | MonadCont m => ((a -> m b) -> m a) -> m a |
| 2025-02-10 09:10:26 +0100 | <ski> | and .. it's not clear what your "is Ok" respectively "is not" means |
| 2025-02-10 09:11:30 +0100 | <haskellbridge> | <Bowuigi> I think it concerns inhabitation, ignoring the lack of constraints in "a -> m b" |
| 2025-02-10 09:12:03 +0100 | <albet70> | what is k's type in callCC $ \k -> do ... |
| 2025-02-10 09:12:45 +0100 | <albet70> | k :: (a -> m b) -> m a? or k :: a -> m b? |
| 2025-02-10 09:12:47 +0100 | <haskellbridge> | <Bowuigi> In the most general case it would be "(a -> m b) -> m a" |
| 2025-02-10 09:12:54 +0100 | <ski> | would be `a -> m b', for the particular `a' and `m' referenced by that `do ...', and by the surrounding context of that `callCC (\k -> do ...)' call |
| 2025-02-10 09:13:04 +0100 | <ski> | (and `b' is arbitrary) |
| 2025-02-10 09:13:30 +0100 | <albet70> | :t (>>=) |
| 2025-02-10 09:13:31 +0100 | <lambdabot> | Monad m => m a -> (a -> m b) -> m b |
| 2025-02-10 09:14:36 +0100 | <haskellbridge> | <Bowuigi> Oh yeah k is "a -> m b", the whole lambda is "(a -> m b) -> m a" |
| 2025-02-10 09:14:48 +0100 | <ski> | `do ...' there have type `m a', given `k' having type `a -> m b' |
| 2025-02-10 09:15:01 +0100 | <ski> | therefore `\k -> do ...' would have type `(a -> m b) -> m a' |
| 2025-02-10 09:15:18 +0100 | <ski> | and therefore `callCC (\k -> do ...)' would have type `m a' |
| 2025-02-10 09:16:02 +0100 | FragByte | (~christian@user/fragbyte) (Quit: Quit) |
| 2025-02-10 09:16:14 +0100 | <haskellbridge> | <Bowuigi> The "m a" (where m is an instance of MonadCont and therefore an instance of Monad) part in the signature is why you can use the do |
| 2025-02-10 09:17:02 +0100 | <haskellbridge> | <Bowuigi> The "m a" in the lambda, I mean |
| 2025-02-10 09:17:26 +0100 | <ski> | (a possible alternative type for `callCC', which would be slightly more general, would be `MonadCont m => ((forall b. a -> m b) -> m a) -> m a'. this would be a rank-3 type, which would allow `k' to be used polymorphically, being invoked in multiple places inside `do ..', having potentially different monadic result types `b' in each place) |
| 2025-02-10 09:18:00 +0100 | FragByte | (~christian@user/fragbyte) FragByte |
| 2025-02-10 09:18:12 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-02-10 09:21:02 +0100 | <haskellbridge> | <Bowuigi> Anyway, regarding the "functions that are not ok", you can know which one is inhabited (by non-bottoms) on simple cases by just looking at the type signature. This property is a corollary of parametricity |
| 2025-02-10 09:22:09 +0100 | <haskellbridge> | <Bowuigi> You mentioned that "a -> b" is not ok, this is because you have no way to get a "b" given an "a" as is. If you had some constraint that allowed this, it would be "ok" |
| 2025-02-10 09:24:18 +0100 | <ski> | similarly, `f :: a -> m b' is "not ok" (contrary to what you said), because you have no way to build an `m b', from an `a' |
| 2025-02-10 09:25:09 +0100 | <haskellbridge> | <Bowuigi> "a -> b -> b" is ok because you can get a "b" directly. In fact, any function of this type (ignoring bottoms) is equal to "\a b -> b". |
| 2025-02-10 09:25:45 +0100 | <haskellbridge> | <Bowuigi> The same can be said about "a -> b -> a" and "\a b -> a" |
| 2025-02-10 09:25:56 +0100 | Anushka | (~Anushka@103.158.254.201) |
| 2025-02-10 09:26:13 +0100 | <ski> | @djinn a -> b -> b |
| 2025-02-10 09:26:14 +0100 | <lambdabot> | f _ a = a |
| 2025-02-10 09:28:47 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-02-10 09:30:49 +0100 | Anushka88 | (~Anushka@2409:40f2:200a:540c:99ac:eae:949f:cdf1) |
| 2025-02-10 09:33:40 +0100 | Anushka | (~Anushka@103.158.254.201) (Ping timeout: 240 seconds) |
| 2025-02-10 09:35:36 +0100 | Anushka88 | (~Anushka@2409:40f2:200a:540c:99ac:eae:949f:cdf1) (Client Quit) |
| 2025-02-10 09:35:49 +0100 | Anushka | (~Anushka@2409:40f2:200a:540c:99ac:eae:949f:cdf1) |
| 2025-02-10 09:41:05 +0100 | <Leary> | @free bad :: a -> b |
| 2025-02-10 09:42:45 +0100 | <Leary> | `True = (const True . bad) () = (bad . g) () = (const False . bad) () = False`; contradiction; QED (no `bad`). |
| 2025-02-10 09:43:59 +0100 | <ski> | is `g' `id', here ? |
| 2025-02-10 09:44:07 +0100 | <Leary> | It's anything. |
| 2025-02-10 09:44:36 +0100 | <ski> | yea, but for concreteness |
| 2025-02-10 09:44:57 +0100 | <Leary> | Let it be `id` then. |
| 2025-02-10 09:45:49 +0100 | Zaz_ | (~zaz@195.89.33.222) (Quit: Client closed) |
| 2025-02-10 09:45:49 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-02-10 09:46:18 +0100 | <ski> | (cf. `forall (x : A). P x |- exists (x : A). P x', but only if `A' is inhabited) |
| 2025-02-10 09:49:22 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 09:49:37 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-10 09:49:37 +0100 | Anushka | (~Anushka@2409:40f2:200a:540c:99ac:eae:949f:cdf1) (Quit: Client closed) |
| 2025-02-10 09:51:07 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-10 09:51:15 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-02-10 09:52:22 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-02-10 09:54:09 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-02-10 09:55:51 +0100 | <albet70> | :t runKleisli |
| 2025-02-10 09:55:52 +0100 | <lambdabot> | Kleisli m a b -> a -> m b |
| 2025-02-10 09:56:11 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-02-10 09:57:11 +0100 | Anushka | (~Anushka@2409:40f2:200a:540c:99ac:eae:949f:cdf1) |
| 2025-02-10 09:57:54 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 09:58:09 +0100 | Anushka | (~Anushka@2409:40f2:200a:540c:99ac:eae:949f:cdf1) (Client Quit) |
| 2025-02-10 09:59:34 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) (Ping timeout: 260 seconds) |
| 2025-02-10 10:00:23 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-02-10 10:01:51 +0100 | Anushka | (~Anushka@2409:40f2:200a:540c:99ac:eae:949f:cdf1) |
| 2025-02-10 10:01:57 +0100 | euouae | (~euouae@user/euouae) euouae |
| 2025-02-10 10:02:09 +0100 | <euouae> | Hello when I use hls on emacs I get "SMethod_CompletionItemResolve" issues a lot and they're very annoying |
| 2025-02-10 10:02:12 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Ping timeout: 252 seconds) |
| 2025-02-10 10:02:32 +0100 | <euouae> | how can I stop them? I've grepped emacs' packages source code for this and it's not popping up I think it's in the hls itself |
| 2025-02-10 10:02:57 +0100 | <euouae> | https://github.com/haskell/haskell-language-server/blob/31b8787fed05a9cad51c4a124d99c9f10fff3d7c/g… |
| 2025-02-10 10:03:18 +0100 | dhil | (~dhil@2a0c:b381:5bf:3500:ca67:e13c:58d1:a27e) dhil |
| 2025-02-10 10:04:05 +0100 | tabaqui1 | (~root@87.200.129.102) tabaqui |
| 2025-02-10 10:05:09 +0100 | <haskellbridge> | <me7itamen> https://github.com/haskell/haskell-language-server/pull/4478 |
| 2025-02-10 10:05:30 +0100 | <haskellbridge> | <me7itamen> this PR had fixed it |
| 2025-02-10 10:05:53 +0100 | <euouae> | Is my hls maybe older then? |
| 2025-02-10 10:06:02 +0100 | <tomsmeding> | this was merged only 3 weeks ago |
| 2025-02-10 10:06:03 +0100 | <euouae> | I'm using 2.9.0.1 |
| 2025-02-10 10:06:14 +0100 | m1dnight | (~m1dnight@d8D861908.access.telenet.be) (Ping timeout: 252 seconds) |
| 2025-02-10 10:06:28 +0100 | <haskellbridge> | <me7itamen> yep, try build hls yourself |
| 2025-02-10 10:06:46 +0100 | <tomsmeding> | it's even newer than 2.10.0.0, which hasn't been released yet |
| 2025-02-10 10:07:06 +0100 | Anushka14 | (~Anushka@103.158.254.207) |
| 2025-02-10 10:07:10 +0100 | <tomsmeding> | building HLS is easy, build the repo and then `cabal build -w ghc-<VERSION> all` |
| 2025-02-10 10:07:23 +0100 | <euouae> | okay so I build hls, then what? |
| 2025-02-10 10:07:42 +0100 | <euouae> | how do I tell ghcup to use it? or are you suggesting that I configure emacs to use that built hls |
| 2025-02-10 10:07:51 +0100 | <tomsmeding> | or you could `ghcup compile hls -g master --ghc <VERSION>` |
| 2025-02-10 10:08:00 +0100 | <tomsmeding> | that would probably automatically register it in ghcup |
| 2025-02-10 10:08:05 +0100 | <haskellbridge> | <me7itamen> I use "ghcup compile hls -g 9b0c3c03aea0f6fe2f488abc09942414933c5200 --ghc 9.6.6" |
| 2025-02-10 10:08:07 +0100 | <haskellbridge> | <maerwald> "tell ghcup to use it"? |
| 2025-02-10 10:08:12 +0100 | Googulator | (~Googulato@2a01-036d-0106-4074-758c-12a1-cbb4-05eb.pool6.digikabel.hu) |
| 2025-02-10 10:08:30 +0100 | <haskellbridge> | <maerwald> you probably have to _set_ it |
| 2025-02-10 10:08:32 +0100 | <haskellbridge> | <maerwald> check the TUI |
| 2025-02-10 10:08:46 +0100 | <tomsmeding> | maerwald: I was suggesting manually `cabal build`ing a HLS, that won't appear in ghcup |
| 2025-02-10 10:08:57 +0100 | <tomsmeding> | if you do it via `ghcup compile hls` then it should, of course :) |
| 2025-02-10 10:09:13 +0100 | <haskellbridge> | <maerwald> yes, it resuses cabal store so that shouldn't be expensive |
| 2025-02-10 10:09:36 +0100 | <tomsmeding> | does it just do `cabal build` in a temporary directory on a git clone, or is there more magic involved in `ghcup compile hls`? |
| 2025-02-10 10:09:49 +0100 | <haskellbridge> | <maerwald> something like that |
| 2025-02-10 10:10:01 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:7180:4e50:ddff:fe9b:8922) CiaoSen |
| 2025-02-10 10:10:09 +0100 | <tomsmeding> | simple is good |
| 2025-02-10 10:10:21 +0100 | <haskellbridge> | <maerwald> https://github.com/haskell/ghcup-hs/blob/master/lib/GHCup/HLS.hs#L359 |
| 2025-02-10 10:10:40 +0100 | Anushka | (~Anushka@2409:40f2:200a:540c:99ac:eae:949f:cdf1) (Ping timeout: 240 seconds) |
| 2025-02-10 10:10:50 +0100 | <tomsmeding> | fancy tracked exceptions system |
| 2025-02-10 10:11:07 +0100 | <haskellbridge> | <maerwald> I don't know if it's any use, lmao |
| 2025-02-10 10:11:19 +0100 | <tomsmeding> | I just haven't seen it before in haskell :) |
| 2025-02-10 10:11:41 +0100 | <haskellbridge> | <maerwald> https://hackage.haskell.org/package/variant |
| 2025-02-10 10:12:39 +0100 | AlexZenon | (~alzenon@178.34.151.30) (Ping timeout: 268 seconds) |
| 2025-02-10 10:14:51 +0100 | Anushka14 | (~Anushka@103.158.254.207) (Quit: Client closed) |
| 2025-02-10 10:14:54 +0100 | <tomsmeding> | passing `--disable-tests` is an obvious thing I'll be stealing for my own HLS builds lol |
| 2025-02-10 10:15:11 +0100 | <tomsmeding> | but yeah it looks like it does what I said, but not quite because flexibility |
| 2025-02-10 10:16:08 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2025-02-10 10:17:17 +0100 | <euouae> | What's --disable-tests? |
| 2025-02-10 10:17:32 +0100 | <tomsmeding> | maerwald: `Member x xs = MemberAtIndex (IndexOf x xs) x xs` that feels... weirdly redundant? |
| 2025-02-10 10:17:35 +0100 | <euouae> | Oh to skip testing hls after its built? |
| 2025-02-10 10:17:42 +0100 | <tomsmeding> | euouae: no just to not _build_ the tests |
| 2025-02-10 10:17:51 +0100 | <tomsmeding> | I'm not running them anyway, but I'm spending CPU time building them |
| 2025-02-10 10:17:53 +0100 | <tomsmeding> | rather pointless |
| 2025-02-10 10:18:00 +0100 | <euouae> | sure |
| 2025-02-10 10:18:46 +0100 | AlexZenon | (~alzenon@178.34.151.30) |
| 2025-02-10 10:18:57 +0100 | <tomsmeding> | maerwald: interesting lib, thanks for the pointer |
| 2025-02-10 10:19:36 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-02-10 10:22:01 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) misterfish |
| 2025-02-10 10:23:09 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-02-10 10:24:50 +0100 | famubu | (~julinuser@user/famubu) (Quit: leaving) |
| 2025-02-10 10:25:37 +0100 | Anushka | (~Anushka@103.158.254.207) |
| 2025-02-10 10:30:28 +0100 | HappyNewYear2025 | (~newyear@2.219.56.221) |
| 2025-02-10 10:31:13 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:7180:4e50:ddff:fe9b:8922) (Ping timeout: 244 seconds) |
| 2025-02-10 10:33:04 +0100 | haver | (~newyear@2.219.56.221) (Ping timeout: 244 seconds) |
| 2025-02-10 10:33:44 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2025-02-10 10:35:10 +0100 | Anushka | (~Anushka@103.158.254.207) (Ping timeout: 240 seconds) |
| 2025-02-10 10:38:26 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 10:39:58 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-02-10 10:41:10 +0100 | <haskellbridge> | <Bowuigi> What is VariantF used for? Most of the use cases I've found don't require rows with kinds other than Type (VariantF uses Type -> Type) |
| 2025-02-10 10:42:54 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-10 10:45:28 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-10 10:55:01 +0100 | zaz | (~zaz@195.89.33.222) |
| 2025-02-10 10:56:26 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 268 seconds) |
| 2025-02-10 10:59:23 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-10 11:01:53 +0100 | m1dnight | (~m1dnight@d8D861908.access.telenet.be) m1dnight |
| 2025-02-10 11:08:37 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:7180:4e50:ddff:fe9b:8922) CiaoSen |
| 2025-02-10 11:12:06 +0100 | kuribas | (~user@ptr-17d51ep4791u6fgzj68.18120a2.ip6.access.telenet.be) kuribas |
| 2025-02-10 11:12:18 +0100 | <euouae> | Here's another issue, maybe someone knows, but how can I stop lsp autocomplete inside comments in emacs? |
| 2025-02-10 11:17:15 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2025-02-10 11:26:30 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 11:27:00 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds) |
| 2025-02-10 11:29:36 +0100 | dysthesis | (~dysthesis@user/dysthesis) (Ping timeout: 264 seconds) |
| 2025-02-10 11:30:56 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-10 11:44:11 +0100 | haritz | saimazoon |
| 2025-02-10 11:46:47 +0100 | m1dnight | (~m1dnight@d8D861908.access.telenet.be) (Quit: WeeChat 3.0) |
| 2025-02-10 11:47:59 +0100 | <tomsmeding> | Bowuigi: it's used here https://hackage.haskell.org/package/variant-1.0.1/docs/Data-Variant-EADT.html where the functor is a base functor, to describe recursive types |
| 2025-02-10 11:49:16 +0100 | <dminuoso> | Mmm, what a revelation. I just (re)discovered eldoc. With LSP it's extremely useful to just set point to an identifier, and then get both the non-monomorphized *and* monomorphized type of the thing. |
| 2025-02-10 11:49:31 +0100 | <dminuoso> | Having both at your fingertips is.. awesome. :) |
| 2025-02-10 11:49:48 +0100 | <tomsmeding> | (this is the LSP "hover" feature, right?) |
| 2025-02-10 11:50:15 +0100 | <tomsmeding> | VSCode shows it if you hover over the name with the mouse; it's one of the standard LSP bindings in vim |
| 2025-02-10 11:50:18 +0100 | <dminuoso> | Presumably yes. |
| 2025-02-10 11:50:36 +0100 | <dminuoso> | With emacs its just so cool this happens automatically when you set point. |
| 2025-02-10 11:50:37 +0100 | <tomsmeding> | and yes, it is quite useful :) |
| 2025-02-10 11:50:45 +0100 | <dminuoso> | So I dont have to use my mouse to get this information |
| 2025-02-10 11:50:57 +0100 | <tomsmeding> | using the mouse is just for vscode plebs |
| 2025-02-10 11:51:34 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 2025-02-10 11:59:16 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-10 12:01:27 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 276 seconds) |
| 2025-02-10 12:01:27 +0100 | tnt2 | tnt1 |
| 2025-02-10 12:02:04 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:7180:4e50:ddff:fe9b:8922) (Ping timeout: 260 seconds) |
| 2025-02-10 12:02:45 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f99c4dbaee3a15423f1.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-02-10 12:03:24 +0100 | <ncf> | zaz: not quite; the image of span p consists of the pairs of lists (x, y) such that all of x satisfies p and either the head of y doesn't satisfy p or y is empty |
| 2025-02-10 12:09:42 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-10 12:12:30 +0100 | koz | (~koz@121.99.240.58) (Ping timeout: 276 seconds) |
| 2025-02-10 12:14:54 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 12:16:24 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-02-10 12:18:08 +0100 | koz | (~koz@121.99.240.58) |
| 2025-02-10 12:18:59 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-10 12:21:15 +0100 | Anushka | (~Anushka@101.0.63.190) |
| 2025-02-10 12:25:19 +0100 | Anushka | (~Anushka@101.0.63.190) (Client Quit) |
| 2025-02-10 12:26:33 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection) |
| 2025-02-10 12:28:21 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-02-10 12:28:57 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
| 2025-02-10 12:28:57 +0100 | ChanServ | +v haskellbridge |
| 2025-02-10 12:29:16 +0100 | xff0x | (~xff0x@2405:6580:b080:900:36c:449b:42ad:5dc6) |
| 2025-02-10 12:32:27 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-10 12:35:36 +0100 | tabaqui | (~root@167.71.80.236) (Ping timeout: 265 seconds) |
| 2025-02-10 12:40:14 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 12:44:30 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Ping timeout: 246 seconds) |
| 2025-02-10 12:45:22 +0100 | koz | (~koz@121.99.240.58) (Ping timeout: 252 seconds) |
| 2025-02-10 12:48:16 +0100 | CiaoSen | (~Jura@ip-037-201-241-067.um10.pools.vodafone-ip.de) CiaoSen |
| 2025-02-10 12:50:56 +0100 | koz | (~koz@121.99.240.58) |
| 2025-02-10 12:52:57 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2025-02-10 12:56:51 +0100 | jespada | (~jespada@2800:a4:2243:2100:5cc9:2329:b53c:b25f) jespada |
| 2025-02-10 13:03:18 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 13:04:26 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f99c4dbaee3a15423f1.dip0.t-ipconnect.de) acidjnk |
| 2025-02-10 13:06:04 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2025-02-10 13:08:24 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 276 seconds) |
| 2025-02-10 13:10:10 +0100 | m1dnight | (~m1dnight@d8D861908.access.telenet.be) m1dnight |
| 2025-02-10 13:25:40 +0100 | tabaqui | (~root@167.71.80.236) tabaqui |
| 2025-02-10 13:27:27 +0100 | mange | (~user@user/mange) (Quit: Zzz...) |
| 2025-02-10 13:32:31 +0100 | manwithluck` | (~manwithlu@2a09:bac1:5be0:20::49:de) (Remote host closed the connection) |
| 2025-02-10 13:33:38 +0100 | manwithluck` | (~manwithlu@2a09:bac1:5be0:20::49:de) manwithluck |
| 2025-02-10 13:35:27 +0100 | HappyNewYear2025 | (~newyear@2.219.56.221) (Ping timeout: 244 seconds) |
| 2025-02-10 13:36:17 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 13:40:50 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Ping timeout: 265 seconds) |
| 2025-02-10 13:44:33 +0100 | sprotte24 | (~sprotte24@p200300d16f2cc700d9ccd33fac989807.dip0.t-ipconnect.de) |
| 2025-02-10 13:47:46 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-10 13:52:02 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 13:53:00 +0100 | otbergsten | (~otbergste@user/otbergsten) otbergsten |
| 2025-02-10 13:55:46 +0100 | CiaoSen | (~Jura@ip-037-201-241-067.um10.pools.vodafone-ip.de) (Ping timeout: 252 seconds) |
| 2025-02-10 13:56:49 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-02-10 14:00:28 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-02-10 14:01:06 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-10 14:06:03 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 246 seconds) |
| 2025-02-10 14:06:13 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-10 14:11:53 +0100 | <dminuoso> | Oh here's a curious question that I come back to a few times a year. Everytime I cook up a ToField/FromField class, I generally dont want to use Show/Read for serialization as I want the freedom to rename. |
| 2025-02-10 14:12:29 +0100 | <dminuoso> | Instead I usually do something like `toField s = case s of Started -> toField "started"; Stopped -> toField "stopped"` |
| 2025-02-10 14:12:51 +0100 | <dminuoso> | Which by itself is fine, but when I write a FromField, there's the potential for typos such that they dont qlign. |
| 2025-02-10 14:13:21 +0100 | <dminuoso> | So then I keep thinking about just writing an assoc list [(Started, "started"), ("Stopped", "stopped")], but then pattern match exhaustiveness is not on my side. |
| 2025-02-10 14:13:42 +0100 | <dminuoso> | TH is an obvious solution, but its not some simple 2-liner I want to include in every poroject |
| 2025-02-10 14:18:36 +0100 | <int-e> | (bonus point if the "qlign" was intentional) |
| 2025-02-10 14:20:08 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-02-10 14:28:23 +0100 | zwro | (~z@user/zero) (Ping timeout: 252 seconds) |
| 2025-02-10 14:30:38 +0100 | zero | (~z@user/zero) zero |
| 2025-02-10 14:33:48 +0100 | sprotte24 | (~sprotte24@p200300d16f2cc700d9ccd33fac989807.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-02-10 14:35:23 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-02-10 14:37:02 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-10 14:37:04 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 260 seconds) |
| 2025-02-10 14:37:04 +0100 | tnt2 | tnt1 |
| 2025-02-10 14:39:46 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 14:43:19 +0100 | CryptLab | (NSA@gateway/vpn/protonvpn/commanderbond007) (Read error: Connection reset by peer) |
| 2025-02-10 14:44:08 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
| 2025-02-10 14:46:13 +0100 | CryptLab | (NSA@gateway/vpn/protonvpn/commanderbond007) CommanderBond007 |
| 2025-02-10 14:46:14 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 244 seconds) |
| 2025-02-10 14:48:06 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-02-10 14:55:58 +0100 | causal | (~eric@50.35.84.231) (Quit: WeeChat 4.5.1) |
| 2025-02-10 14:57:00 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) (Ping timeout: 252 seconds) |
| 2025-02-10 15:00:36 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) |
| 2025-02-10 15:03:21 +0100 | <haskellbridge> | <Profpatsch> dminuoso: https://code.tvl.fyi/tree/users/Profpatsch/my-prelude/src/MyPrelude.hs#n695 |
| 2025-02-10 15:04:50 +0100 | tri | (~tri@ool-44c70bcb.dyn.optonline.net) (Ping timeout: 244 seconds) |
| 2025-02-10 15:05:16 +0100 | <dminuoso> | Profpatsch: Oh, so simple and effective. I had not thought of Bounded. |
| 2025-02-10 15:06:33 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-02-10 15:10:50 +0100 | <haskellbridge> | <Profpatsch> dminuoso: now that I think about this, since usually the difference between maxBound and minBound is small for enums, using List.elem instead of Map.elem should be better actually |
| 2025-02-10 15:11:02 +0100 | <haskellbridge> | <Profpatsch> Cause scanning a list is lower overhead at small size |
| 2025-02-10 15:11:07 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f99c4dbaee3a15423f1.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2025-02-10 15:11:47 +0100 | <dminuoso> | Profpatsch: I think you meant List.lookup/Map.lookup rather than elem, but yeah. |
| 2025-02-10 15:11:52 +0100 | <haskellbridge> | <Profpatsch> yeah |
| 2025-02-10 15:11:58 +0100 | <dminuoso> | I've already adapted it to use Data.List and simplified it a bit. |
| 2025-02-10 15:12:15 +0100 | <haskellbridge> | <Profpatsch> I originally copied it from relude i think |
| 2025-02-10 15:12:32 +0100 | <dminuoso> | For the large general case, if you have loads of these and want optimal performance I would use TH anyway. |
| 2025-02-10 15:12:39 +0100 | <haskellbridge> | <Profpatsch> yeah |
| 2025-02-10 15:13:24 +0100 | <haskellbridge> | <Profpatsch> dminuoso: I had this as well https://hackage.haskell.org/package/pa-field-parser-0.3.0.0/docs/FieldParser.html#v:invertPretty |
| 2025-02-10 15:13:32 +0100 | <haskellbridge> | <Profpatsch> Which fits it into my actual parsing interface |
| 2025-02-10 15:14:21 +0100 | <dminuoso> | Oh that looks a little bit more dangerous, now. |
| 2025-02-10 15:14:49 +0100 | <dminuoso> | It should contain some unsafe note about how it should only be used on injective pretty functions. |
| 2025-02-10 15:15:13 +0100 | <haskellbridge> | <Profpatsch> yeah |
| 2025-02-10 15:15:23 +0100 | <dminuoso> | Cant quite imagine the usecase. What do you use it for? |
| 2025-02-10 15:15:30 +0100 | <haskellbridge> | <Profpatsch> dminuoso: but fwiw, there’s the TH slot: https://hackage.haskell.org/package/pa-field-parser-0.3.0.0/docs/FieldParser.html#v:literal |
| 2025-02-10 15:15:48 +0100 | <haskellbridge> | <Profpatsch> dminuoso: composite parsing for simple values |
| 2025-02-10 15:16:14 +0100 | <haskellbridge> | <Profpatsch> (utf8 >>> signedDecimal) :: FieldParser ByteString Integer |
| 2025-02-10 15:16:39 +0100 | <haskellbridge> | <Profpatsch> it’s super simple but surprisingly versatile |
| 2025-02-10 15:16:47 +0100 | otbergsten | (~otbergste@user/otbergsten) (Remote host closed the connection) |
| 2025-02-10 15:16:54 +0100 | <dminuoso> | This is kind of cute. |
| 2025-02-10 15:17:10 +0100 | koz | (~koz@121.99.240.58) (Ping timeout: 252 seconds) |
| 2025-02-10 15:17:20 +0100 | <haskellbridge> | <Profpatsch> the best abstractions are cute and kinda silly :) |
| 2025-02-10 15:17:25 +0100 | <dminuoso> | I'm doing something like this but the >>> structure follows a tree, based on parsing values. |
| 2025-02-10 15:17:39 +0100 | <haskellbridge> | <Profpatsch> yeah I experimented with this as well |
| 2025-02-10 15:18:01 +0100 | <haskellbridge> | <Profpatsch> always a trade-off between unbounded memory usage and good error messages |
| 2025-02-10 15:18:06 +0100 | <dminuoso> | (So I maintain a decoding tree, and while Im parsing Im recursing into my parser function) |
| 2025-02-10 15:18:22 +0100 | <dminuoso> | Which is important since the decoding rules are sort of passed in at runtime. |
| 2025-02-10 15:18:22 +0100 | <haskellbridge> | <Profpatsch> dminuoso: something like this? https://code.tvl.fyi/tree/users/Profpatsch/my-prelude/src/Parse.hs |
| 2025-02-10 15:18:52 +0100 | <dminuoso> | No, its definitely monadic. |
| 2025-02-10 15:18:54 +0100 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2025-02-10 15:18:54 +0100 | <haskellbridge> | <Profpatsch> I don’t like the abstraction very much, but it’s useful for e.g. parsing XML |
| 2025-02-10 15:19:12 +0100 | <dminuoso> | Though I guess I could make it work too. |
| 2025-02-10 15:19:27 +0100 | <haskellbridge> | <Profpatsch> Ah yeah, you can have a specialized "bind" function usually |
| 2025-02-10 15:19:34 +0100 | <haskellbridge> | <Profpatsch> that throws away errors |
| 2025-02-10 15:19:47 +0100 | <haskellbridge> | <Profpatsch> It nearly-but-not-quite fits |
| 2025-02-10 15:19:48 +0100 | <dminuoso> | Mine is directly bolted onto flatparse |
| 2025-02-10 15:19:54 +0100 | <dminuoso> | Because I like the sheer simplicity of that interface. |
| 2025-02-10 15:20:33 +0100 | <dminuoso> | And with that, I have this super trivial refocus function: https://gist.github.com/dminuoso/e9026b66182bd438910c895184b97ad5 |
| 2025-02-10 15:20:40 +0100 | <haskellbridge> | <Profpatsch> dminuoso: I tried abstracting the pattern of creating these kinds of parsers a little with https://code.tvl.fyi/tree/users/Profpatsch/my-prelude/src/ValidationParseT.hs |
| 2025-02-10 15:20:44 +0100 | <dminuoso> | Which makes this >>> notion really simple to do. |
| 2025-02-10 15:20:56 +0100 | <haskellbridge> | <Profpatsch> but never got to a point where I think it’s super interesting for the general use-case |
| 2025-02-10 15:21:05 +0100 | <dminuoso> | (But its limited to when each stage expects a bytestring) |
| 2025-02-10 15:21:34 +0100 | <dminuoso> | Gah I find prefix Compose hard to ready. |
| 2025-02-10 15:21:44 +0100 | <dminuoso> | This should have been named :.: |
| 2025-02-10 15:21:53 +0100 | <dminuoso> | s/ready/read/ |
| 2025-02-10 15:22:12 +0100 | <dminuoso> | Profpatsch: We should compare notes when I have a little more time, I gotta blaze. |
| 2025-02-10 15:22:20 +0100 | <haskellbridge> | <Profpatsch> dminuoso: fwiw I’m not talking conventional parsers (stream of tokens to data struct) but “vertical” parsers (value of high entropy to value of lower entropy) |
| 2025-02-10 15:22:26 +0100 | <haskellbridge> | <Profpatsch> 420 :) |
| 2025-02-10 15:22:34 +0100 | <dminuoso> | haskellbridge: No I get the idea of vertical parsing. |
| 2025-02-10 15:22:40 +0100 | <dminuoso> | What I do is still a kind of vertical parsing in that sense. |
| 2025-02-10 15:22:58 +0100 | <haskellbridge> | <Profpatsch> Ah, I see |
| 2025-02-10 15:23:18 +0100 | <dminuoso> | essentially it's slowly zooming into a bytestring buffer (though that zooming action sometimes includes fusing some chunks together over the parsing) |
| 2025-02-10 15:23:19 +0100 | koz | (~koz@121.99.240.58) |
| 2025-02-10 15:23:40 +0100 | <dminuoso> | until you reach a primitive, and then that primitive gets turned into Int, Bool, String |
| 2025-02-10 15:23:53 +0100 | <dminuoso> | Plus some labels and context as to what that Int, Bool or String is. |
| 2025-02-10 15:24:04 +0100 | <dminuoso> | (Which is just a path description of the decoding tree) |
| 2025-02-10 15:24:48 +0100 | <dminuoso> | Its just that in my parser, each step produces a bytestring buffer, and I refocus (not with the primitive I linked above, that one is a bit more special) into that slice. |
| 2025-02-10 15:24:52 +0100 | jespada | (~jespada@2800:a4:2243:2100:5cc9:2329:b53c:b25f) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-02-10 15:27:58 +0100 | <euouae> | I read half of the STG paper before I felt that I've been going to deep for my own good |
| 2025-02-10 15:28:51 +0100 | <euouae> | Doing some leetcode I realized I wanted something that looked a lot like lenses so I got a book on them (penner's optics by example) and after that I'll try writing a web app |
| 2025-02-10 15:28:51 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 15:29:09 +0100 | <euouae> | I've already written this app in the past in Python so it'll be exciting to see how much I can improve with Haskell |
| 2025-02-10 15:29:40 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f99c4dbaee3a15423f1.dip0.t-ipconnect.de) acidjnk |
| 2025-02-10 15:30:42 +0100 | <euouae> | Though lenses do make Haskell look like APL a bit, they are really cool. Like view/span of C++ but more powerful and expressive |
| 2025-02-10 15:31:16 +0100 | CiaoSen | (~Jura@ip-037-201-241-067.um10.pools.vodafone-ip.de) CiaoSen |
| 2025-02-10 15:33:18 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-10 15:35:04 +0100 | <dminuoso> | euouae: Yeah optics/lenses are some of the most novel libraries in Haskell. |
| 2025-02-10 15:35:52 +0100 | <dminuoso> | Although I find the usecases where they outperform manual accessors are limited. |
| 2025-02-10 15:36:29 +0100 | <euouae> | by outperform are you talking about code performance or generally that they're the better tool? |
| 2025-02-10 15:36:40 +0100 | <dminuoso> | The latter. |
| 2025-02-10 15:36:53 +0100 | <dminuoso> | Execution performance is in general really good. |
| 2025-02-10 15:37:32 +0100 | <euouae> | maybe it's a style thing, but I like them personally |
| 2025-02-10 15:37:44 +0100 | <dminuoso> | But the DSL (especially all the operators) can look confusing, there's only so much %~~.! and ?!~..! that my eyes can tolerate. |
| 2025-02-10 15:37:45 +0100 | <euouae> | they do remind me also of lisp's SETF, which I also always liked but it is limited |
| 2025-02-10 15:38:45 +0100 | <dminuoso> | We have one big use case, which is a networking compiler. In our intermediate representation we have deeply nested data types (around 10 layers deep), with lists/maps, most have plenty of fields.. |
| 2025-02-10 15:38:58 +0100 | <euouae> | There's ways around the wackyness of the operators, one on top of my head is to color-code them |
| 2025-02-10 15:39:01 +0100 | <dminuoso> | And `optics` gives us a tool to concisely manipulate that large structure in passes. |
| 2025-02-10 15:39:19 +0100 | <euouae> | Hmm... neat. |
| 2025-02-10 15:39:36 +0100 | <euouae> | It might not be of serious use to me but the book does teach me some haskell too in between |
| 2025-02-10 15:39:39 +0100 | <dminuoso> | euouae: In general lens/optics is best when your data is deeply nested. |
| 2025-02-10 15:39:54 +0100 | <dminuoso> | If its not, I would refrain. |
| 2025-02-10 15:40:08 +0100 | <euouae> | One thing that I didn't understand, and maybe that's some GHC extension, is, how to beat the namespace problem for the record accessors? |
| 2025-02-10 15:40:11 +0100 | <euouae> | field accesosrs |
| 2025-02-10 15:40:19 +0100 | <dminuoso> | What namespace problem? |
| 2025-02-10 15:40:36 +0100 | <euouae> | well, data X = X {name :: String} and then data Y = Y {name :: String} |
| 2025-02-10 15:41:00 +0100 | <dminuoso> | I just do what most others do: data X = X { xName :: String } and data Y = Y { yName :: String } |
| 2025-02-10 15:41:22 +0100 | <euouae> | I read that there's some new GHC extension that solves this, or maybe a proposal: <https://ghc-proposals.readthedocs.io/en/latest/proposals/0282-record-dot-syntax.html> |
| 2025-02-10 15:41:29 +0100 | <euouae> | But I also read that lenses deal with this problem, not sure how. |
| 2025-02-10 15:41:30 +0100 | <dminuoso> | I know there's a *bunch* of extensions that try and give you ways to not do that.. |
| 2025-02-10 15:41:39 +0100 | <dminuoso> | But I find them all confusing. |
| 2025-02-10 15:41:54 +0100 | <dminuoso> | euouae: Oh that's quite easy. |
| 2025-02-10 15:42:04 +0100 | <dminuoso> | Very roughly you could just say |
| 2025-02-10 15:42:12 +0100 | <dminuoso> | % class HasName a where name :: a -> String |
| 2025-02-10 15:42:12 +0100 | <yahb2> | <no output> |
| 2025-02-10 15:42:25 +0100 | <dminuoso> | % data Person = Person { pName :: String; pAge :: Int } |
| 2025-02-10 15:42:25 +0100 | <yahb2> | <interactive>:137:39: error: [GHC-58481] parse error on input ‘;’ |
| 2025-02-10 15:42:28 +0100 | <dminuoso> | % data Person = Person { pName :: String, pAge :: Int } |
| 2025-02-10 15:42:28 +0100 | <yahb2> | <no output> |
| 2025-02-10 15:42:35 +0100 | <dminuoso> | % instance HasName Person where name = pName |
| 2025-02-10 15:42:35 +0100 | <yahb2> | <no output> |
| 2025-02-10 15:43:00 +0100 | <euouae> | ah right, and you let polymorphicity deal with it |
| 2025-02-10 15:43:06 +0100 | <dminuoso> | euouae: This is the idea in essence. Now you can have many things and using `name :: HasName a => a -> String` you can get the name of anything that HasName. |
| 2025-02-10 15:43:25 +0100 | <dminuoso> | euouae: With lens/optics rather than extracting the name, you can just produce some kind of optic instead |
| 2025-02-10 15:43:33 +0100 | <dminuoso> | Which you can use to read *or* modify (if its a lens) |
| 2025-02-10 15:43:49 +0100 | <dminuoso> | So you might have: |
| 2025-02-10 15:43:49 +0100 | <euouae> | it would be a `HasName x => Lens' x String` right? |
| 2025-02-10 15:43:55 +0100 | <dminuoso> | Right. |
| 2025-02-10 15:44:04 +0100 | <dminuoso> | That's all there is to it. |
| 2025-02-10 15:44:23 +0100 | <euouae> | I think RecordDotSyntax lets you do x.name instead |
| 2025-02-10 15:44:45 +0100 | <dminuoso> | Like I said, I find them confusing due to interactions with other extensions. |
| 2025-02-10 15:44:51 +0100 | <euouae> | got it |
| 2025-02-10 15:44:59 +0100 | <dminuoso> | But hey, some people seem to like it? |
| 2025-02-10 15:45:22 +0100 | <dminuoso> | In my eyes RecordDotSyntax feels very unpolished and it breaks in plenty of non-trivial cases. |
| 2025-02-10 15:45:30 +0100 | <euouae> | could've chosen something else like x`name or x@name |
| 2025-02-10 15:45:34 +0100 | <dminuoso> | `optics` does not break in non-trivial cases, b |
| 2025-02-10 15:47:29 +0100 | <mauke> | [...] Like view/span of C++ <- I always thought they were a bit like C++ member pointers, at least in the trivial case |
| 2025-02-10 15:47:50 +0100 | <mauke> | first-class, composable member pointers |