| 2024-04-24 00:01:39 +0200 | acidjnk | (~acidjnk@p200300d6e714dc429de1f5b63f3ace20.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2024-04-24 00:07:48 +0200 | xstill_1 | (xstill@fimu/xstill) |
| 2024-04-24 00:07:50 +0200 | xstill_ | (xstill@fimu/xstill) (Ping timeout: 268 seconds) |
| 2024-04-24 00:07:50 +0200 | xsarnik | (xsarnik@lounge.fi.muni.cz) (Ping timeout: 268 seconds) |
| 2024-04-24 00:07:51 +0200 | xstill_1 | xstill_ |
| 2024-04-24 00:08:06 +0200 | xsarnik | (xsarnik@lounge.fi.muni.cz) |
| 2024-04-24 00:09:44 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-04-24 00:20:03 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-04-24 00:24:34 +0200 | xal | (~xal@mx1.xal.systems) () |
| 2024-04-24 00:26:12 +0200 | xal | (~xal@mx1.xal.systems) |
| 2024-04-24 00:29:55 +0200 | philopsos | (~caecilius@user/philopsos) |
| 2024-04-24 00:35:27 +0200 | causal | (~eric@50.35.88.207) |
| 2024-04-24 00:39:05 +0200 | zzz | (~yin@user/zero) (Ping timeout: 245 seconds) |
| 2024-04-24 00:39:30 +0200 | yin | (~yin@user/zero) (Ping timeout: 245 seconds) |
| 2024-04-24 00:41:13 +0200 | zzz | (~yin@user/zero) |
| 2024-04-24 00:41:18 +0200 | yin | (~yin@user/zero) |
| 2024-04-24 00:42:01 +0200 | docelalt^ | (~cd@c-98-242-74-66.hsd1.ga.comcast.net) (Remote host closed the connection) |
| 2024-04-24 00:45:30 +0200 | ph88 | (~ph88@ip5b403f30.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2024-04-24 00:47:58 +0200 | zzz | (~yin@user/zero) (Quit: leaving) |
| 2024-04-24 00:56:53 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) (Ping timeout: 240 seconds) |
| 2024-04-24 00:58:30 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-04-24 01:03:06 +0200 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2024-04-24 01:05:51 +0200 | zetef | (~quassel@5.2.182.98) |
| 2024-04-24 01:15:05 +0200 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2024-04-24 01:17:28 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-04-24 01:19:55 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-04-24 01:19:56 +0200 | yin | zwrv |
| 2024-04-24 01:32:53 +0200 | trev | (~trev@user/trev) (Ping timeout: 240 seconds) |
| 2024-04-24 01:35:20 +0200 | trev | (~trev@user/trev) |
| 2024-04-24 01:42:00 +0200 | zwrv | (~yin@user/zero) (Ping timeout: 245 seconds) |
| 2024-04-24 01:44:12 +0200 | zwrv | (~yin@user/zero) |
| 2024-04-24 01:55:26 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-24 02:07:25 +0200 | tv | (~tv@user/tv) (Ping timeout: 245 seconds) |
| 2024-04-24 02:07:43 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2024-04-24 02:07:48 +0200 | tv | (~tv@user/tv) |
| 2024-04-24 02:18:37 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 256 seconds) |
| 2024-04-24 02:21:29 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2024-04-24 02:24:15 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 272 seconds) |
| 2024-04-24 02:34:55 +0200 | zwrv | (~yin@user/zero) (Ping timeout: 245 seconds) |
| 2024-04-24 02:36:57 +0200 | zwrv | (~yin@user/zero) |
| 2024-04-24 02:49:42 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-04-24 02:51:20 +0200 | <cheater> | i would like to make it impossible to export a type from my module and i would like to add some checking that will error out if that happens. how can i do this? |
| 2024-04-24 02:51:49 +0200 | <cheater> | it's a newtype |
| 2024-04-24 02:52:04 +0200 | <cheater> | i want it usable outside the module using only values i exported which are smart constructors |
| 2024-04-24 02:52:33 +0200 | <c_wraith> | You need some form of testing for "does not compile" |
| 2024-04-24 02:53:04 +0200 | <c_wraith> | I know of a package that tests for type errors using -fdefer-type-errors, but there's no equivalent for name errors. Which is what you're really looking for. |
| 2024-04-24 02:53:53 +0200 | <cheater> | it's mostly to make sure my coworkers don't do something stupid |
| 2024-04-24 02:54:08 +0200 | <cheater> | which, you know, given that this is an unusual way to use modules, is warranted |
| 2024-04-24 02:54:27 +0200 | <c_wraith> | not exporting constructors is a pretty common way to use modules... |
| 2024-04-24 02:54:46 +0200 | <cheater> | yes, but forbidding the exporting is a less common thing |
| 2024-04-24 02:55:01 +0200 | <cheater> | there isn't really a specific way to say in haskell "these things shall not be exported" |
| 2024-04-24 02:55:16 +0200 | <cheater> | there's only the negative statement of "these things have not been exported" |
| 2024-04-24 02:55:22 +0200 | <cheater> | but it's not like an active "do not export these" |
| 2024-04-24 02:56:16 +0200 | <c_wraith> | Oh! You can use template haskell. |
| 2024-04-24 02:56:26 +0200 | <cheater> | in what way |
| 2024-04-24 02:56:57 +0200 | <c_wraith> | > runQ [| Bin |] --> UnboundVarE Bin |
| 2024-04-24 02:56:58 +0200 | <lambdabot> | <hint>:1:7: error: parse error on input ‘|’ |
| 2024-04-24 02:57:06 +0200 | <c_wraith> | whoops, didn't mean to prefix that with > |
| 2024-04-24 02:57:07 +0200 | <c_wraith> | anyway |
| 2024-04-24 02:57:24 +0200 | <cheater> | i don't get it |
| 2024-04-24 02:57:29 +0200 | <cheater> | can you explain what it does? |
| 2024-04-24 02:57:42 +0200 | <c_wraith> | If you runQ a quote containing the name of the constructor, you will get UnboundVarE if the constructor isn't in scope |
| 2024-04-24 02:58:16 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 260 seconds) |
| 2024-04-24 02:58:17 +0200 | <cheater> | ok but how does that help me? i would have to do this in every *other* module |
| 2024-04-24 02:58:31 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-04-24 02:58:52 +0200 | <c_wraith> | Does every other module import a different version of the module containing the hidden constructors? |
| 2024-04-24 02:59:58 +0200 | <c_wraith> | Someone would have to work really hard to break such a test - moving the constructors to a different module, or renaming them |
| 2024-04-24 03:00:12 +0200 | <c_wraith> | At that point, they should get the point that they're doing something unapproved |
| 2024-04-24 03:01:29 +0200 | <cheater> | i don't understand. why are you talking about different versions of module exports? |
| 2024-04-24 03:01:42 +0200 | <c_wraith> | why are you talking about testing in every other module? |
| 2024-04-24 03:01:48 +0200 | <c_wraith> | Modules have exactly one export list |
| 2024-04-24 03:02:00 +0200 | <c_wraith> | You test the export list, not how it's imported in other modules |
| 2024-04-24 03:02:12 +0200 | <cheater> | well if i have module Foo where would i put that test? |
| 2024-04-24 03:02:18 +0200 | <c_wraith> | In a test |
| 2024-04-24 03:02:21 +0200 | <cheater> | if i put it in module Foo then obviously the constructors will be there |
| 2024-04-24 03:02:26 +0200 | <cheater> | so what, like another module? |
| 2024-04-24 03:02:27 +0200 | <c_wraith> | No, of course not |
| 2024-04-24 03:02:34 +0200 | <c_wraith> | Some other module, like all testts |
| 2024-04-24 03:02:53 +0200 | <cheater> | hmm... |
| 2024-04-24 03:03:07 +0200 | <cheater> | makes sense |
| 2024-04-24 03:03:24 +0200 | <geekosaur> | if you try to put your test in the module where you're trying to prevent exports, which might be possible with some evil TH, what would stop someone from deleting your test? |
| 2024-04-24 03:03:31 +0200 | <geekosaur> | it belongs in the test suite |
| 2024-04-24 03:03:35 +0200 | zwrv | (~yin@user/zero) (Ping timeout: 264 seconds) |
| 2024-04-24 03:03:53 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) (Ping timeout: 268 seconds) |
| 2024-04-24 03:05:07 +0200 | mima | (~mmh@aftr-62-216-211-1.dynamic.mnet-online.de) (Ping timeout: 268 seconds) |
| 2024-04-24 03:05:32 +0200 | <monochrom> | It is a test case. I have such test cases in a C course. I teach students what not to put in a *.h file. So my test case is a C file that #include's it and tries to use what should be forbidden. If my file compiles, the student gets 0 marks. |
| 2024-04-24 03:05:56 +0200 | <monochrom> | Very simple to write a shell script "if ! gcc foo.c ; then ..." for that. |
| 2024-04-24 03:06:39 +0200 | <c_wraith> | Sadly, you can't use reify with runQ. I... don't know why not. |
| 2024-04-24 03:09:11 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2024-04-24 03:12:23 +0200 | <cheater> | geekosaur: it's not about stopping someone from deleting the test |
| 2024-04-24 03:12:31 +0200 | <cheater> | geekosaur: you misunderstood the thing i said earlier |
| 2024-04-24 03:12:40 +0200 | <cheater> | [02:53:31] <cheater> there isn't really a specific way to say in haskell "these things shall not be exported" |
| 2024-04-24 03:12:40 +0200 | <cheater> | [02:53:46] <cheater> there's only the negative statement of "these things have not been exported" |
| 2024-04-24 03:13:26 +0200 | <cheater> | if someone tries to export the constructors, and then finds out the thing doesn't build, and the error comes from a line with the comment "do not export these, blah blah blah see ticket FU-69420" then they'll know not to export it |
| 2024-04-24 03:13:34 +0200 | <cheater> | it's not about *preventing* someone from exporting the thing |
| 2024-04-24 03:13:49 +0200 | <cheater> | it's to prevent them from (exporting it because they didn't know better) |
| 2024-04-24 03:17:15 +0200 | <probie> | So the goal is to preventing some well-meaning agent of chaos from breaking everything? Very low effort, slightly messy, high success chance: Add the constructor the export list yourself, and then comment it out and stick a comment above it saying why it can't be exported |
| 2024-04-24 03:17:24 +0200 | <probie> | That way if they go to export it, they'll see it |
| 2024-04-24 03:20:32 +0200 | <jackdk> | can you put constraints on pattern synonyms? If so, you could stick a `TypeError (...) =>` on it and export that in place of the actual ctor |
| 2024-04-24 03:20:42 +0200 | <geekosaur> | yeh, you were making it sound like active maliciousness which requires something more clever |
| 2024-04-24 03:26:19 +0200 | xff0x | (~xff0x@ai082039.d.east.v6connect.net) (Ping timeout: 272 seconds) |
| 2024-04-24 03:27:43 +0200 | <cheater> | probie: that's practical... not the best solution but it might be the simplest useful solution |
| 2024-04-24 03:28:00 +0200 | <cheater> | jackdk: i want those types to actually be used. |
| 2024-04-24 03:28:34 +0200 | <cheater> | just via my own functions |
| 2024-04-24 03:28:38 +0200 | <cheater> | and not via the types being instantiated. |
| 2024-04-24 03:33:24 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-04-24 03:35:51 +0200 | random-jellyfish | (~developer@user/random-jellyfish) (Ping timeout: 260 seconds) |
| 2024-04-24 03:36:45 +0200 | otto_s | (~user@p5b044a05.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2024-04-24 03:37:56 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 260 seconds) |
| 2024-04-24 03:38:15 +0200 | otto_s | (~user@p5b0445f5.dip0.t-ipconnect.de) |
| 2024-04-24 03:38:15 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 245 seconds) |
| 2024-04-24 03:57:43 +0200 | <Axman6> | So do you want users to be able to pattern match on the type but not use the constructor for creating the type? |
| 2024-04-24 03:58:06 +0200 | trqt | (~trqt@user/trqt) |
| 2024-04-24 03:58:06 +0200 | <Axman6> | that feels doable with pattern synonyms |
| 2024-04-24 04:02:20 +0200 | cipherrot | (~znc-user@user/petrichor) (Read error: Connection reset by peer) |
| 2024-04-24 04:02:40 +0200 | petrichor | (~znc-user@user/petrichor) |
| 2024-04-24 04:04:57 +0200 | hueso | (~root@user/hueso) (Quit: hueso) |
| 2024-04-24 04:08:53 +0200 | hueso | (~root@user/hueso) |
| 2024-04-24 04:09:55 +0200 | nschoe | (~nschoe@2a01:e0a:8e:a190:f3a1:c501:e8bd:2571) (Ping timeout: 245 seconds) |
| 2024-04-24 04:09:59 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2024-04-24 04:10:10 +0200 | tt123109 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) |
| 2024-04-24 04:10:16 +0200 | tabemann_ | (~tabemann@2600:1700:7990:24e0:42f1:a891:a658:f99d) |
| 2024-04-24 04:10:17 +0200 | Luj3 | (~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) |
| 2024-04-24 04:10:20 +0200 | FragByte | (~christian@user/fragbyte) (Ping timeout: 245 seconds) |
| 2024-04-24 04:10:23 +0200 | Benzi-Junior | (~BenziJuni@232-148-209-31.dynamic.hringdu.is) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-24 04:10:31 +0200 | ubert1 | (~Thunderbi@2a02:8109:ab8a:5a00:a472:8995:2c6:603d) |
| 2024-04-24 04:10:38 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Read error: Connection reset by peer) |
| 2024-04-24 04:10:39 +0200 | Benzi-Junior | (~BenziJuni@232-148-209-31.dynamic.hringdu.is) |
| 2024-04-24 04:10:41 +0200 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:a472:8995:2c6:603d) (Remote host closed the connection) |
| 2024-04-24 04:10:41 +0200 | ubert1 | ubert |
| 2024-04-24 04:10:44 +0200 | tabemann | (~tabemann@2600:1700:7990:24e0:2a56:ddeb:a57a:6071) (Read error: Connection reset by peer) |
| 2024-04-24 04:10:51 +0200 | pavonia_ | (~user@user/siracusa) |
| 2024-04-24 04:10:58 +0200 | Luj | (~Luj@2a01:e0a:5f9:9681:1b36:b307:9c84:5d03) (Read error: Connection reset by peer) |
| 2024-04-24 04:10:58 +0200 | Luj3 | Luj |
| 2024-04-24 04:11:00 +0200 | tzh_ | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) |
| 2024-04-24 04:11:07 +0200 | xal | (~xal@mx1.xal.systems) (Quit: No Ping reply in 180 seconds.) |
| 2024-04-24 04:11:07 +0200 | nschoe | (~nschoe@2a01:e0a:8e:a190:f3a1:c501:e8bd:2571) |
| 2024-04-24 04:11:12 +0200 | FragByte | (~christian@user/fragbyte) |
| 2024-04-24 04:11:19 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) (Quit: ZNC - http://znc.in) |
| 2024-04-24 04:11:25 +0200 | tcard_ | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2024-04-24 04:11:35 +0200 | tt12310 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) (Ping timeout: 245 seconds) |
| 2024-04-24 04:11:35 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Ping timeout: 245 seconds) |
| 2024-04-24 04:11:35 +0200 | tt123109 | tt12310 |
| 2024-04-24 04:11:46 +0200 | driib | (~driib@vmi931078.contaboserver.net) (Quit: Ping timeout (120 seconds)) |
| 2024-04-24 04:11:50 +0200 | JamesMowery | (~JamesMowe@ip98-171-80-211.ph.ph.cox.net) (Quit: Ping timeout (120 seconds)) |
| 2024-04-24 04:11:59 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2024-04-24 04:12:09 +0200 | JamesMowery | (~JamesMowe@ip98-171-80-211.ph.ph.cox.net) |
| 2024-04-24 04:12:17 +0200 | SteelBlueSilk | (~SteelBlue@user/SteelBlueSilk) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in) |
| 2024-04-24 04:12:18 +0200 | driib | (~driib@vmi931078.contaboserver.net) |
| 2024-04-24 04:12:18 +0200 | bcksl | (~bcksl@user/bcksl) (Quit: \) |
| 2024-04-24 04:12:22 +0200 | Ram-Z | (~Ram-Z@li1814-254.members.linode.com) (Remote host closed the connection) |
| 2024-04-24 04:12:22 +0200 | xal | (~xal@mx1.xal.systems) |
| 2024-04-24 04:12:24 +0200 | end | (~end@user/end/x-0094621) (Quit: end) |
| 2024-04-24 04:12:25 +0200 | son0p | (~ff@191.104.18.195) (Ping timeout: 245 seconds) |
| 2024-04-24 04:12:45 +0200 | Ram-Z | (~Ram-Z@li1814-254.members.linode.com) |
| 2024-04-24 04:13:05 +0200 | SteelBlueSilk | (~SteelBlue@c-98-42-249-36.hsd1.ca.comcast.net) |
| 2024-04-24 04:13:05 +0200 | SteelBlueSilk | (~SteelBlue@c-98-42-249-36.hsd1.ca.comcast.net) (Changing host) |
| 2024-04-24 04:13:05 +0200 | SteelBlueSilk | (~SteelBlue@user/SteelBlueSilk) |
| 2024-04-24 04:13:15 +0200 | td_ | (~td@i5387090C.versanet.de) (Ping timeout: 245 seconds) |
| 2024-04-24 04:13:18 +0200 | Catty | (~catties@user/meow/catties) (Quit: n_n) |
| 2024-04-24 04:13:38 +0200 | catties | (~catties@user/meow/catties) |
| 2024-04-24 04:13:40 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Ping timeout: 245 seconds) |
| 2024-04-24 04:14:05 +0200 | pavonia | (~user@user/siracusa) (Ping timeout: 245 seconds) |
| 2024-04-24 04:14:05 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) (Ping timeout: 245 seconds) |
| 2024-04-24 04:14:05 +0200 | _________ | (~nobody@user/noodly) (Ping timeout: 245 seconds) |
| 2024-04-24 04:14:09 +0200 | td_ | (~td@i5387090C.versanet.de) |
| 2024-04-24 04:14:33 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2024-04-24 04:14:34 +0200 | pavonia_ | pavonia |
| 2024-04-24 04:14:55 +0200 | tzh | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) (Ping timeout: 245 seconds) |
| 2024-04-24 04:14:55 +0200 | Patternmaster | (~georg@user/Patternmaster) (Ping timeout: 245 seconds) |
| 2024-04-24 04:14:55 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) (Ping timeout: 245 seconds) |
| 2024-04-24 04:14:59 +0200 | _________ | (~nobody@user/noodly) |
| 2024-04-24 04:15:08 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) |
| 2024-04-24 04:15:46 +0200 | Patternmaster | (~georg@user/Patternmaster) |
| 2024-04-24 04:15:56 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) |
| 2024-04-24 04:15:59 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) |
| 2024-04-24 04:18:03 +0200 | <glguy> | https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pattern_synonyms.html search for "unidirectional" |
| 2024-04-24 04:18:06 +0200 | trqt | (~trqt@user/trqt) (Quit: Using Circe, the loveliest of all IRC clients) |
| 2024-04-24 04:20:28 +0200 | bcksl | (~bcksl@user/bcksl) |
| 2024-04-24 04:22:30 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-04-24 04:23:01 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-04-24 04:23:27 +0200 | xdminsy | (~xdminsy@117.147.70.233) (Ping timeout: 260 seconds) |
| 2024-04-24 04:24:54 +0200 | end | (~end@user/end/x-0094621) |
| 2024-04-24 04:34:11 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 264 seconds) |
| 2024-04-24 04:35:39 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2024-04-24 04:35:59 +0200 | td_ | (~td@i5387090C.versanet.de) (Ping timeout: 272 seconds) |
| 2024-04-24 04:37:28 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-24 04:37:40 +0200 | td_ | (~td@i5387093D.versanet.de) |
| 2024-04-24 04:49:10 +0200 | <jackdk> | Or through the provision of `Traversal'`s |
| 2024-04-24 04:57:14 +0200 | <Inst> | is there any way to simplify this? |
| 2024-04-24 04:58:00 +0200 | <Inst> | uncurry (<$) . (id &&& tryPutMVar handle.discordHandleLibraryError) |
| 2024-04-24 04:58:39 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-04-24 05:01:40 +0200 | <mauke> | add points? |
| 2024-04-24 05:03:17 +0200 | <Inst> | msg <$ tryPutMVar handle.DiscordHandleLibraryError msg |
| 2024-04-24 05:03:26 +0200 | <Inst> | I probably don't understand Control.Arrow well enough |
| 2024-04-24 05:05:08 +0200 | <Inst> | there has to be a combinator wherein you can run a monadic / applicative action on the target, but have the bind value be the target |
| 2024-04-24 05:08:02 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 252 seconds) |
| 2024-04-24 05:09:53 +0200 | <mauke> | @pl \msg -> msg <$ tryPutMVar handle.DiscordHandleLibraryError msg |
| 2024-04-24 05:09:53 +0200 | <lambdabot> | ap (<$) ((tryPutMVar handle .) . DiscordHandleLibraryError) |
| 2024-04-24 05:11:27 +0200 | <mauke> | @pl \msg -> msg <$ tryPutMVar handle_discordHandleLibraryError msg |
| 2024-04-24 05:11:27 +0200 | <lambdabot> | ap (<$) (tryPutMVar handle_discordHandleLibraryError) |
| 2024-04-24 05:11:29 +0200 | <jackdk> | Hoogling for `a -> (a -> m b) -> m a` gives two instances of this function |
| 2024-04-24 05:13:59 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2024-04-24 05:15:13 +0200 | zmt00 | (~zmt00@user/zmt00) |
| 2024-04-24 05:16:17 +0200 | <jackdk> | If you strengthen the type signature from `IfElse`'s `Monad m => (a -> m b) -> (a -> m a)` to `Functor f => (a -> f b) -> a -> f a`, is it then the case that it has only one real implementation? Because the only way to get a `f anything` is to apply the function argument, then you have to `<$` the `a` back into it. Also, it makes it look like a `Lens a a a b`, which might be interesting |
| 2024-04-24 05:16:33 +0200 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:a472:8995:2c6:603d) (Ping timeout: 256 seconds) |
| 2024-04-24 05:19:13 +0200 | <Inst> | oof |
| 2024-04-24 05:19:16 +0200 | <Inst> | thanks mauke, so pointless |
| 2024-04-24 05:21:06 +0200 | <Inst> | (<$) <*> foo is the most toxic code ever, though |
| 2024-04-24 05:24:20 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-04-24 05:28:26 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 260 seconds) |
| 2024-04-24 05:28:40 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-04-24 05:31:01 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-04-24 05:31:58 +0200 | aforemny_ | (~aforemny@2001:9e8:6cea:cb00:f739:9bdb:c465:7132) |
| 2024-04-24 05:31:58 +0200 | aforemny | (~aforemny@2001:9e8:6cc5:7800:397f:89d3:8c7e:e3e5) (Ping timeout: 255 seconds) |
| 2024-04-24 05:51:10 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 245 seconds) |
| 2024-04-24 05:54:16 +0200 | qqq | (~qqq@92.43.167.61) (Remote host closed the connection) |
| 2024-04-24 06:00:16 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2024-04-24 06:02:35 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-04-24 06:05:36 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2024-04-24 06:06:28 +0200 | sroso | (~sroso@user/SrOso) |
| 2024-04-24 06:06:55 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-04-24 06:22:04 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) |
| 2024-04-24 06:22:20 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-04-24 06:23:11 +0200 | son0p | (~ff@191.104.18.195) |
| 2024-04-24 06:24:26 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) (Remote host closed the connection) |
| 2024-04-24 06:27:28 +0200 | danza_ | (~francesco@151.57.237.5) |
| 2024-04-24 06:29:24 +0200 | average | (uid473595@user/average) |
| 2024-04-24 06:33:40 +0200 | danza_ | (~francesco@151.57.237.5) (Ping timeout: 245 seconds) |
| 2024-04-24 06:39:22 +0200 | michalz | (~michalz@185.246.207.203) |
| 2024-04-24 06:51:56 +0200 | rdcdr | (~rdcdr@user/rdcdr) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in) |
| 2024-04-24 06:53:48 +0200 | benkard | (~mulk@p5b112e4a.dip0.t-ipconnect.de) |
| 2024-04-24 06:54:13 +0200 | rdcdr | (~rdcdr@user/rdcdr) |
| 2024-04-24 06:54:31 +0200 | mulk | (~mulk@p5b2dc97e.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2024-04-24 06:54:32 +0200 | benkard | mulk |
| 2024-04-24 07:01:36 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) |
| 2024-04-24 07:13:53 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-04-24 07:17:20 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-04-24 07:30:07 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-04-24 07:31:03 +0200 | zetef | (~quassel@5.2.182.98) |
| 2024-04-24 07:31:44 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-04-24 07:37:06 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2024-04-24 07:37:53 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2024-04-24 07:41:37 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-24 07:43:14 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 268 seconds) |
| 2024-04-24 07:43:30 +0200 | euleritian | (~euleritia@dynamic-176-001-023-202.176.1.pool.telefonica.de) |
| 2024-04-24 07:43:48 +0200 | zetef | (~quassel@5.2.182.98) (Ping timeout: 255 seconds) |
| 2024-04-24 07:46:45 +0200 | <energizer> | i guess cartesianProduct distributes over zipWith? |
| 2024-04-24 07:53:43 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 268 seconds) |
| 2024-04-24 07:55:31 +0200 | jinsun_ | (~jinsun@user/jinsun) |
| 2024-04-24 07:55:31 +0200 | jinsun | Guest225 |
| 2024-04-24 07:55:31 +0200 | Guest225 | (~jinsun@user/jinsun) (Killed (cadmium.libera.chat (Nickname regained by services))) |
| 2024-04-24 07:55:31 +0200 | jinsun_ | jinsun |
| 2024-04-24 07:57:57 +0200 | acidjnk | (~acidjnk@p200300d6e714dc53c081e76fe6dc232d.dip0.t-ipconnect.de) |
| 2024-04-24 08:07:11 +0200 | trev | (~trev@user/trev) (Ping timeout: 264 seconds) |
| 2024-04-24 08:20:48 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-24 08:36:35 +0200 | mima | (~mmh@aftr-62-216-211-228.dynamic.mnet-online.de) |
| 2024-04-24 08:39:08 +0200 | average | (uid473595@user/average) (Quit: Connection closed for inactivity) |
| 2024-04-24 08:41:47 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-04-24 08:56:56 +0200 | euleritian | (~euleritia@dynamic-176-001-023-202.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-04-24 08:57:20 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-24 09:04:15 +0200 | Guest95 | (~Guest95@217.7.130.9) |
| 2024-04-24 09:08:00 +0200 | danza_ | (~francesco@151.57.237.5) |
| 2024-04-24 09:18:51 +0200 | mima | (~mmh@aftr-62-216-211-228.dynamic.mnet-online.de) (Ping timeout: 252 seconds) |
| 2024-04-24 09:32:04 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) |
| 2024-04-24 09:34:53 +0200 | gfundler | (~user@p5b0f39a4.dip0.t-ipconnect.de) |
| 2024-04-24 09:36:20 +0200 | ft | (~ft@p4fc2a20e.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-04-24 09:36:57 +0200 | Square | (~Square@user/square) |
| 2024-04-24 09:39:33 +0200 | <Inst> | wait |
| 2024-04-24 09:39:40 +0200 | <Inst> | https://hackage.haskell.org/package/base-4.19.1.0/docs/src/Control.Arrow.html#Kleisli |
| 2024-04-24 09:39:47 +0200 | <Inst> | This... is incorrectly documented isn't it? |
| 2024-04-24 09:39:53 +0200 | <Inst> | It's not a monad, it's simply a parameterized type |
| 2024-04-24 09:39:55 +0200 | <Inst> | there's no monad constraint here |
| 2024-04-24 09:41:15 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 260 seconds) |
| 2024-04-24 09:41:53 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2024-04-24 09:42:01 +0200 | trev | (~trev@user/trev) |
| 2024-04-24 09:45:01 +0200 | <Inst> | the constraints are put in from instances, welp |
| 2024-04-24 09:45:28 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-04-24 09:48:08 +0200 | <Inst> | hmmm, could you treat the kleisli arrows as applicative? |
| 2024-04-24 09:49:28 +0200 | <Inst> | yeah, you only need pure and fmap to do it |
| 2024-04-24 09:55:59 +0200 | <Inst> | ah, i understand, applicative kleisli can't be categories, so they can't be arrows |
| 2024-04-24 09:57:51 +0200 | <probie> | Yeah, you need (sans the Kleisli new type) `(.) :: (b -> m c) -> (a -> m b) -> (a -> m c)`, which is going to require monad |
| 2024-04-24 09:58:22 +0200 | <probie> | with only `fmap` and `pure`, the best you can do is `(b -> m c) -> (a -> m b) -> (a -> m (m c))` |
| 2024-04-24 10:06:08 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-04-24 10:08:04 +0200 | tzh_ | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-04-24 10:09:01 +0200 | danza_ | (~francesco@151.57.237.5) (Read error: Connection reset by peer) |
| 2024-04-24 10:18:15 +0200 | sroso | (~sroso@user/SrOso) (Read error: Connection reset by peer) |
| 2024-04-24 10:19:52 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2024-04-24 10:20:28 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-04-24 10:22:29 +0200 | sroso | (~sroso@user/SrOso) |
| 2024-04-24 10:24:22 +0200 | lol_ | (~lol@2603:3016:1e01:b940:500c:2d35:d29f:521d) |
| 2024-04-24 10:25:44 +0200 | philopsos | (~caecilius@user/philopsos) (Ping timeout: 268 seconds) |
| 2024-04-24 10:28:30 +0200 | jcarpenter2 | (~lol@2603:3016:1e01:b940:bc60:e296:86fe:18c4) (Ping timeout: 268 seconds) |
| 2024-04-24 10:33:44 +0200 | philopsos | (~caecilius@user/philopsos) |
| 2024-04-24 10:36:34 +0200 | danse-nr3 | (~danse-nr3@151.43.249.70) |
| 2024-04-24 10:39:16 +0200 | <jackdk> | the constraint is on the instance |
| 2024-04-24 10:40:13 +0200 | philopsos | (~caecilius@user/philopsos) (Ping timeout: 255 seconds) |
| 2024-04-24 10:44:46 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-04-24 10:50:40 +0200 | Guest95 | (~Guest95@217.7.130.9) (Quit: Client closed) |
| 2024-04-24 10:54:07 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-04-24 10:54:53 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-04-24 11:00:46 +0200 | titibandit | (~titibandi@user/titibandit) |
| 2024-04-24 11:06:35 +0200 | gfundler | (~user@p5b0f39a4.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2024-04-24 11:19:35 +0200 | zetef | (~quassel@5.2.182.98) |
| 2024-04-24 11:22:36 +0200 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2024-04-24 11:25:39 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
| 2024-04-24 11:32:33 +0200 | xdminsy | (~xdminsy@117.147.70.233) |
| 2024-04-24 11:32:54 +0200 | mima | (~mmh@138.246.3.254) |
| 2024-04-24 11:34:05 +0200 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) (Ping timeout: 240 seconds) |
| 2024-04-24 11:34:31 +0200 | Luj | (~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) (Ping timeout: 256 seconds) |
| 2024-04-24 11:35:47 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2024-04-24 11:36:54 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 252 seconds) |
| 2024-04-24 11:37:01 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2024-04-24 11:42:08 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2024-04-24 11:43:32 +0200 | chele | (~chele@user/chele) |
| 2024-04-24 11:50:44 +0200 | Luj | (~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) |
| 2024-04-24 11:53:18 +0200 | zetef | (~quassel@5.2.182.99) |
| 2024-04-24 12:05:36 +0200 | Luj | (~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) (Ping timeout: 256 seconds) |
| 2024-04-24 12:09:01 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 268 seconds) |
| 2024-04-24 12:11:07 +0200 | gehmehgeh | gmg |
| 2024-04-24 12:13:43 +0200 | yin | (~yin@user/zero) |
| 2024-04-24 12:15:02 +0200 | <haskellbridge> | <irregularsphere> here's something I think would be nice to share (though has some clear issues): https://play.haskell.org/saved/oO6x9Ycd |
| 2024-04-24 12:15:09 +0200 | yin | zwrv |
| 2024-04-24 12:17:35 +0200 | Me-me | (~me-me@2602:ff16:3:0:1:dc:beef:d00d) (Changing host) |
| 2024-04-24 12:17:35 +0200 | Me-me | (~me-me@user/me-me) |
| 2024-04-24 12:20:40 +0200 | <ncf> | is that your attempt at exofunctors |
| 2024-04-24 12:21:21 +0200 | <Inst> | gahhh, streamly |
| 2024-04-24 12:21:25 +0200 | <haskellbridge> | <irregularsphere> at what? |
| 2024-04-24 12:21:28 +0200 | <Inst> | i realize i'll probably fall in love with streamly |
| 2024-04-24 12:21:36 +0200 | <Inst> | do you know what a functor is in category theory? |
| 2024-04-24 12:21:51 +0200 | <haskellbridge> | <irregularsphere> yes? |
| 2024-04-24 12:22:06 +0200 | <ncf> | https://dorchard.wordpress.com/2011/10/18/subcategories-in-haskell-exofunctors/ |
| 2024-04-24 12:22:35 +0200 | actioninja | (~actioninj@user/actioninja) (Ping timeout: 268 seconds) |
| 2024-04-24 12:22:46 +0200 | <Inst> | streamly honestly is the best library ever; a bunch of Indian guys decide to build a whole new language on top of Haskell with a library and a GHC plugin |
| 2024-04-24 12:22:46 +0200 | <haskellbridge> | <irregularsphere> oh, I wasn't even the first to think of this |
| 2024-04-24 12:24:11 +0200 | <danse-nr3> | what matters whether they were indian or not? |
| 2024-04-24 12:24:22 +0200 | yeitrafferin | (~user@2a04:4540:7213:3800:bf5b:caaa:b515:ed1a) |
| 2024-04-24 12:24:53 +0200 | <Inst> | it matters insofar as if they open up a donation box, and you give them money, they'll get more work done than if you give money to any other Haskell organization |
| 2024-04-24 12:29:28 +0200 | <haskellbridge> | <irregularsphere> ...and i was off by a margin of _thirteen_ years |
| 2024-04-24 12:30:13 +0200 | <danse-nr3> | well that's what we do all the times, but by sharing you found out early |
| 2024-04-24 12:30:53 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
| 2024-04-24 12:31:38 +0200 | <haskellbridge> | <irregularsphere> wdym "early" |
| 2024-04-24 12:32:56 +0200 | <haskellbridge> | <irregularsphere> ncf: thanks for the link by the way |
| 2024-04-24 12:40:28 +0200 | Inst | (~Inst@user/Inst) (Ping timeout: 268 seconds) |
| 2024-04-24 12:45:53 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2024-04-24 12:46:38 +0200 | Square | (~Square@user/square) (Ping timeout: 268 seconds) |
| 2024-04-24 12:47:12 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2024-04-24 12:48:45 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2024-04-24 12:48:59 +0200 | Inst | (~Inst@user/Inst) |
| 2024-04-24 12:50:14 +0200 | <Inst> | I've told the Streamly folks (ComposeWell) they really should set up a Haskell consultancy, I guess it's probably their dream or something; they can undercut Serokell and Tweag like crazy |
| 2024-04-24 12:50:27 +0200 | <Inst> | rather, I told them, they should open up a donation box |
| 2024-04-24 12:50:51 +0200 | <Inst> | but if they opened up a Haskell consultancy they'd make a ton of money, if they could keep their employees from getting sniped off by Well-Typed / Serokell / Tweag |
| 2024-04-24 12:52:57 +0200 | <danse-nr3> | haskell openings are not usually driven by low wages though |
| 2024-04-24 12:53:32 +0200 | <Inst> | usually someone idealistic or willing to give a niche language a shot |
| 2024-04-24 12:53:53 +0200 | <Inst> | still, the idea of having really cheap Haskell consultants would help move the needle on the business end |
| 2024-04-24 12:54:17 +0200 | <danse-nr3> | i mean before spending weeks or months on developing a library or something irregularsphere |
| 2024-04-24 12:56:30 +0200 | <danse-nr3> | haskellers *are* cheap nonetheless, 'cause the market is solid (to mean the opposite of a liquid market). But a cheap wage does not provide much of an edge from what i see in job offers |
| 2024-04-24 12:57:40 +0200 | <Inst> | I mean that they could open up a consultancy to attempt to compete with Well-Typed / Serokell / Tweag / Galois |
| 2024-04-24 13:01:03 +0200 | zetef | (~quassel@5.2.182.99) (Remote host closed the connection) |
| 2024-04-24 13:02:58 +0200 | xff0x | (~xff0x@2405:6580:b080:900:a709:5227:95bf:dd51) |
| 2024-04-24 13:03:53 +0200 | <Inst> | also TBH, while educated Indians usually know English, you tend to have substantial cultural differences compared to a European or American mainstream, so idioms, choices in API design, values in library construction, can differ |
| 2024-04-24 13:09:01 +0200 | sroso | (~sroso@user/SrOso) (Quit: Leaving :)) |
| 2024-04-24 13:10:10 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 256 seconds) |
| 2024-04-24 13:15:54 +0200 | danse-nr3 | (~danse-nr3@151.43.249.70) (Ping timeout: 255 seconds) |
| 2024-04-24 13:17:00 +0200 | aforemny_ | (~aforemny@2001:9e8:6cea:cb00:f739:9bdb:c465:7132) (Ping timeout: 245 seconds) |
| 2024-04-24 13:17:46 +0200 | ph88 | (~ph88@91.64.63.48) |
| 2024-04-24 13:19:01 +0200 | aforemny | (~aforemny@2001:9e8:6cf1:5c00:5feb:9e42:c858:fd24) |
| 2024-04-24 13:19:44 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-04-24 13:20:24 +0200 | zwrv | (~yin@user/zero) (Ping timeout: 255 seconds) |
| 2024-04-24 13:22:22 +0200 | zwrv | (~yin@user/zero) |
| 2024-04-24 13:25:15 +0200 | Square | (~Square@user/square) |
| 2024-04-24 13:26:39 +0200 | <Inst> | speaking of that |
| 2024-04-24 13:26:53 +0200 | <Inst> | I heard a while back that Warp is bitrotted, I mean, it still works, but it's seriously slow by modern standards |
| 2024-04-24 13:27:10 +0200 | <Inst> | i was looking at Discord-Haskell and thinking about updating it |
| 2024-04-24 13:28:17 +0200 | <Inst> | that's what led me back to streamly, and streamly doesn't have an interface for its network connection |
| 2024-04-24 13:29:02 +0200 | <ph88> | How can i see the instance implementation of Show :+: ? -ddump-deriv doesn't work because the base library is not recompiled https://hackage.haskell.org/package/base-4.19.1.0/docs/GHC-Generics.html#t:Data |
| 2024-04-24 13:29:28 +0200 | destituion | (~destituio@85.221.111.174) |
| 2024-04-24 13:29:50 +0200 | <ph88> | i want to override the default somehow and i don't know how to write the instance |
| 2024-04-24 13:33:42 +0200 | <dminuoso> | Inst: Im not sure that hearsay about the quality of warp is helpful. We use warp in a bunch of different places and we have done profiling. Never was warp a significant hotspot in our profile data. |
| 2024-04-24 13:34:33 +0200 | zetef | (~quassel@5.2.182.99) |
| 2024-04-24 13:34:34 +0200 | mreh | (~mreh@2a00:23c7:2803:ef01:8104:39a6:ada6:ece) |
| 2024-04-24 13:34:46 +0200 | <Inst> | warp got ripped off techempower benchmarks, but back when it was on, it was benchmarking 25-33% of fastest Rust frameworks, and 67% of nginx |
| 2024-04-24 13:34:56 +0200 | <mreh> | @seen limmeh |
| 2024-04-24 13:34:56 +0200 | <lambdabot> | I haven't seen limmeh. |
| 2024-04-24 13:35:09 +0200 | <mreh> | @seen lemmih |
| 2024-04-24 13:35:10 +0200 | <lambdabot> | I haven't seen lemmih. |
| 2024-04-24 13:35:20 +0200 | <mreh> | huh |
| 2024-04-24 13:35:34 +0200 | <mreh> | I guess he doesn't come on here any more |
| 2024-04-24 13:35:50 +0200 | <mreh> | I was hoping to chat to someone about hgeometry |
| 2024-04-24 13:36:02 +0200 | <Inst> | just saying, if Haskell performance experts were to give warp / wai etc a makeover, would at least bring haskell back in the running |
| 2024-04-24 13:37:33 +0200 | <dminuoso> | A straight-up comparison of warp against rust is going to be difficult, and probably not helpful either. If the HTTP server implementation itself is a relevant hotspot you either have an atypical web application that, for some reason, is not doing any IO or CPU time in the request processing, or you have scaled to a point where even a small percentage improvement will translate into huge cost |
| 2024-04-24 13:37:36 +0200 | <dminuoso> | savings. |
| 2024-04-24 13:38:57 +0200 | <dminuoso> | And just blanket performance comparisons between "X in language A" and "X in language B" easily introcues the risk of doing something non-idiomatic in one language, or having some requirement orthogonal to the server implementation, and rather about the language itself. |
| 2024-04-24 13:40:59 +0200 | <dminuoso> | I would expect a careful thorough analysis with code examples. |
| 2024-04-24 13:41:04 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-24 13:42:01 +0200 | euphores | (~SASL_euph@user/euphores) (Read error: Connection reset by peer) |
| 2024-04-24 13:42:02 +0200 | <dminuoso> | All I can say is: This is the first time I've ever heard warp being called slow. All our bottlenecks were in request processing (usually space leaks, or doing inefficient database processing like converting fields through text formats) |
| 2024-04-24 13:42:24 +0200 | <dminuoso> | I really have a hard time imagining warp being a *relevant* bottleneck. |
| 2024-04-24 13:42:33 +0200 | <Inst> | the issue wasn't that it was a straight benchmark vs Rust, beating Rust is difficult if not impossible, but it was also a comparison against frameworks written in Java, Go, C#, etc... Warp was apparently losing to all of them |
| 2024-04-24 13:42:45 +0200 | <dminuoso> | Warp is not a framework. |
| 2024-04-24 13:42:48 +0200 | <dminuoso> | Warp is just a WAI server. |
| 2024-04-24 13:42:58 +0200 | <dminuoso> | That's where the issue here is. |
| 2024-04-24 13:43:18 +0200 | <dminuoso> | It sounds like you or they were comparing a HTTP interface server implementation with some framework. |
| 2024-04-24 13:43:53 +0200 | <dminuoso> | It's like you're comparing FastCGI to Express.js. Apples and oranges. |
| 2024-04-24 13:44:29 +0200 | <Inst> | i mean Yesod was listed, as was Servant, Servant + Postgresql iirc was rating 17% or so |
| 2024-04-24 13:45:01 +0200 | <dminuoso> | See, this is why random hearsay is not useful. You are not only comparing apples and oranges, you are comparing fruit salad with oranges. |
| 2024-04-24 13:45:22 +0200 | <dminuoso> | Servant has very little overhead (well other than compile-time overhead) |
| 2024-04-24 13:46:12 +0200 | <dminuoso> | With postgresql, were they using hasql? or postgresql-simple? persistent? |
| 2024-04-24 13:46:33 +0200 | <dminuoso> | Were the queries written by hand? What types were they serialized in? By what code? |
| 2024-04-24 13:46:42 +0200 | mreh | (~mreh@2a00:23c7:2803:ef01:8104:39a6:ada6:ece) (Quit: Client closed) |
| 2024-04-24 13:47:02 +0200 | <Inst> | gotta go |
| 2024-04-24 13:48:42 +0200 | <ph88> | Inst, 25-33% in range or rust? that can't be right |
| 2024-04-24 13:48:44 +0200 | <dminuoso> | This is why you should publish not just "25-33%" number, but a full analysis, code involved, a comparison why two implementations should be equivalent (and say not doing some silly space leak in Haskell due to using foldl instead of foldl'), and full statistical data. |
| 2024-04-24 13:49:04 +0200 | <Inst> | i'm going to try to get the techempower benchmarks |
| 2024-04-24 13:49:18 +0200 | <ph88> | let me get them for you |
| 2024-04-24 13:49:21 +0200 | <dminuoso> | If you use postgresql-simple and have lots of row processing, you will probably be paying a hefty peformance penalty because postgresql-simple uses the text interface of libpq |
| 2024-04-24 13:49:41 +0200 | <dminuoso> | Switching that to hasql can potentially increase the performance up to a factor 8x on raw de-/serialization time. |
| 2024-04-24 13:50:46 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 268 seconds) |
| 2024-04-24 13:51:53 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-04-24 13:53:19 +0200 | <ph88> | snap 416888 requests/s max https://tfb-status.techempower.com/unzip/results.2018-02-04-00-49-39-094.zip/home/techempower/Fram… |
| 2024-04-24 13:53:34 +0200 | <ph88> | actix 2616147 requests/s max https://tfb-status.techempower.com/unzip/results.2018-02-04-00-49-39-094.zip/home/techempower/Fram… |
| 2024-04-24 13:54:19 +0200 | <ph88> | haskell snap 16% performance of actix 100% |
| 2024-04-24 13:54:24 +0200 | zwrv | (~yin@user/zero) (Ping timeout: 252 seconds) |
| 2024-04-24 13:54:25 +0200 | <dminuoso> | This has no profile data and shows no code. |
| 2024-04-24 13:54:30 +0200 | <dminuoso> | Who knows why that is. |
| 2024-04-24 13:54:43 +0200 | <ph88> | code is on github as usual, you can profile it |
| 2024-04-24 13:54:52 +0200 | <dminuoso> | Not my job, honestly. |
| 2024-04-24 13:55:06 +0200 | <ph88> | this is the latest result from techempower before snap got pulled out https://github.com/TechEmpower/FrameworkBenchmarks/blob/2d9b618c99ba0b0073eb49ffdb9e884bf640be1a/f… |
| 2024-04-24 13:56:09 +0200 | <dminuoso> | ph88: But really, if you do take a quick peek, this is highly synthetic and in no way representative of real code: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Haskell/snap/bench/src/M… |
| 2024-04-24 13:56:27 +0200 | zwrv | (~yin@user/zero) |
| 2024-04-24 13:56:49 +0200 | <dminuoso> | And it mixes in a bunch of libraries to the point that its impossible to say why this is slow. |
| 2024-04-24 13:57:37 +0200 | <ph88> | on real world code you add in more libraries and IO, if we want to compare the webserver part only plaintext is the best benchmark to test routing and simple responses |
| 2024-04-24 13:58:04 +0200 | <ph88> | somebody put up that snap benchmark code as best effort at the time |
| 2024-04-24 13:58:16 +0200 | <dminuoso> | If http and routing performance is ever relevant to you, you will either have reached global scaling or have a very exotic use case. |
| 2024-04-24 13:58:34 +0200 | <dminuoso> | ph88: The snap code does more, it also does database interaction |
| 2024-04-24 13:58:36 +0200 | <dminuoso> | With mysql-simple. |
| 2024-04-24 13:58:42 +0200 | <ph88> | all parts combined are relevant and http and routing is part of the total latency |
| 2024-04-24 13:58:57 +0200 | <ph88> | if you want to add in additional parts there are also benchmarks with json formatting and postgresql access |
| 2024-04-24 13:59:07 +0200 | <Inst> | https://www.techempower.com/benchmarks/#section=data-r22&hw=ph&test=json |
| 2024-04-24 13:59:28 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-04-24 13:59:31 +0200 | <dminuoso> | In my HTTP code, about half the time is spend in database IO, and the other is spend in crunching on millions of tree nodes. |
| 2024-04-24 13:59:40 +0200 | <ph88> | it's one codebase for about 5 different benchmarks, it's been this way for many years |
| 2024-04-24 13:59:40 +0200 | <dminuoso> | The HTTP overhead? Completely negligable. |
| 2024-04-24 13:59:51 +0200 | <dminuoso> | Routing overhead? Probably microseconds? |
| 2024-04-24 14:00:19 +0200 | <dminuoso> | ph88: Ah fiar enough. |
| 2024-04-24 14:00:22 +0200 | <ph88> | ye that's of course up to you if you want to crunch millions of tree nodes in a blocking way |
| 2024-04-24 14:00:28 +0200 | <Inst> | IHP is doing much better these days |
| 2024-04-24 14:01:06 +0200 | <dminuoso> | ph88: Performance is best measured in your specific problem domain, because chances are the bottlenecks will things you dont think about. |
| 2024-04-24 14:01:14 +0200 | <dminuoso> | Especially for libraries. |
| 2024-04-24 14:01:21 +0200 | <Inst> | considering its baseline was garbage, of course :3 |
| 2024-04-24 14:01:40 +0200 | <ph88> | but ecosystem optimization is best measured by libraries commonly used shared between many real world apps |
| 2024-04-24 14:02:41 +0200 | <dminuoso> | ph88: Dunno, so if you look at snap, there shouldnt even be a database handler in there because snap does not have database interaction. |
| 2024-04-24 14:02:59 +0200 | <dminuoso> | You're suddenly conflating snap with mysql-simple |
| 2024-04-24 14:03:23 +0200 | <dminuoso> | Just using what you imagine would probably be used is a silly thing to do. |
| 2024-04-24 14:03:29 +0200 | <ph88> | the mysql handler should not be hit on the route that serves plaintext |
| 2024-04-24 14:03:40 +0200 | <dminuoso> | ph88: There should not be a db handler to begin with! |
| 2024-04-24 14:03:42 +0200 | <dminuoso> | That's what Im saying. |
| 2024-04-24 14:03:58 +0200 | <dminuoso> | And there should also not be a JSON handler |
| 2024-04-24 14:04:05 +0200 | <dminuoso> | Because snap has neither JSON nor database interaction. |
| 2024-04-24 14:04:13 +0200 | <ph88> | it's part of the benchmark requirements so that all implementations have some kind of database handler inside. That doesn't mean that that code gets executed for all benchmarks |
| 2024-04-24 14:04:21 +0200 | <dminuoso> | You can do JSON and database interaction with *different* libraries and get different results. |
| 2024-04-24 14:04:58 +0200 | <dminuoso> | That's a silly requirement, then. |
| 2024-04-24 14:05:10 +0200 | <dminuoso> | It introduces the notion that modular frameworks cant exist. |
| 2024-04-24 14:05:15 +0200 | <ph88> | It's an end to end test for 5 different uses cases in 1 codebase for each implementation. The implementations are then compared to each other |
| 2024-04-24 14:05:53 +0200 | <ph88> | You can click on the buttons below "Test types" https://www.techempower.com/benchmarks/ it was already like that when the haskell frameworks where still on the charts |
| 2024-04-24 14:06:51 +0200 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-24 14:07:42 +0200 | <ph88> | code loaded in RAM/cache but not executed is not going to make a significant difference in the benchmark results with so many iterations |
| 2024-04-24 14:10:12 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 268 seconds) |
| 2024-04-24 14:10:35 +0200 | akegalj | (~akegalj@78-1-52-121.adsl.net.t-com.hr) |
| 2024-04-24 14:13:46 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) (Quit: Lost terminal) |
| 2024-04-24 14:18:16 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-04-24 14:18:25 +0200 | danse-nr3 | (~danse-nr3@151.19.252.50) |
| 2024-04-24 14:19:52 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-24 14:30:35 +0200 | koz | (~koz@121.99.240.58) (Ping timeout: 260 seconds) |
| 2024-04-24 14:32:22 +0200 | koz | (~koz@121.99.240.58) |
| 2024-04-24 14:34:58 +0200 | Inst | (~Inst@user/Inst) (Ping timeout: 246 seconds) |
| 2024-04-24 14:52:07 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-04-24 14:57:32 +0200 | <ph88> | how can i denote that something is of kind type ? |
| 2024-04-24 15:03:57 +0200 | ystael | (~ystael@user/ystael) |
| 2024-04-24 15:10:25 +0200 | <ncf> | :: Type |
| 2024-04-24 15:11:06 +0200 | <akegalj> | (from GHC.Types) |
| 2024-04-24 15:12:07 +0200 | akegalj | (~akegalj@78-1-52-121.adsl.net.t-com.hr) (Quit: leaving) |
| 2024-04-24 15:13:46 +0200 | <ncf> | or Data.Kind |
| 2024-04-24 15:14:48 +0200 | <dminuoso> | ph88: *of type Type |
| 2024-04-24 15:15:27 +0200 | <dminuoso> | TypeInType is already the default, the extension merely removes the veil that massages all the diagnostics so it looks like we still have a kind system. |
| 2024-04-24 15:15:52 +0200 | <dminuoso> | (And it removes some of the rather arbitrary restrictions to let you think TypeInType was not on) |
| 2024-04-24 15:16:53 +0200 | Buggys | (~Buggys@Buggy.shelltalk.net) (Ping timeout: 240 seconds) |
| 2024-04-24 15:17:26 +0200 | <ph88> | we don't have a kind system? :> |
| 2024-04-24 15:17:57 +0200 | <dminuoso> | No, we dont really anymore. |
| 2024-04-24 15:18:02 +0200 | <dminuoso> | It's TypeInType. |
| 2024-04-24 15:18:05 +0200 | <dminuoso> | Type :: Type |
| 2024-04-24 15:18:18 +0200 | <dminuoso> | GHC is just lying to you every time it mentions the word kind. |
| 2024-04-24 15:18:42 +0200 | <ph88> | do you have TypeInType on by default ? |
| 2024-04-24 15:19:06 +0200 | <dminuoso> | ph88: Like I said, internally its already doing TypeInType. |
| 2024-04-24 15:19:28 +0200 | <dminuoso> | The extension merely lifts some restrictions |
| 2024-04-24 15:20:14 +0200 | <dminuoso> | https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/poly_kinds.html |
| 2024-04-24 15:20:21 +0200 | <dminuoso> | "The extension TypeInType is now deprecated: its sole effect is to switch on PolyKinds (and hence KindSignatures) and DataKinds." |
| 2024-04-24 15:20:59 +0200 | <dminuoso> | So no, we do not have a kind system anymore in GHC Haskell. |
| 2024-04-24 15:22:38 +0200 | <dminuoso> | It's somewhat confusing that the word `kind` is still used all over the place in the manuals and diagnostics. |
| 2024-04-24 15:23:09 +0200 | <ph88> | yes that's very confusing |
| 2024-04-24 15:23:16 +0200 | <dminuoso> | But if we understand `kind` to mean the type of a type, I guess its alright. |
| 2024-04-24 15:23:19 +0200 | <haskellbridge> | <irregularsphere> there was a kind system? |
| 2024-04-24 15:23:22 +0200 | <Hecate> | ph88: Kind = Type :D |
| 2024-04-24 15:23:47 +0200 | <dminuoso> | irregularsphere |
| 2024-04-24 15:23:48 +0200 | <dminuoso> | irregularsphere: Yes. |
| 2024-04-24 15:24:04 +0200 | <dminuoso> | We used to have a finite tower: Value -> Type -> Kind -> Sort |
| 2024-04-24 15:24:11 +0200 | Buggys | (Buggys@shelltalk.net) |
| 2024-04-24 15:25:23 +0200 | <dminuoso> | At that time, there was only one Sort called BOX, so it used to be that `* :: BOX` and `(* -> *) :: BOX`, etc |
| 2024-04-24 15:26:45 +0200 | <haskellbridge> | <irregularsphere> let me guess, it had no use? |
| 2024-04-24 15:27:57 +0200 | <dminuoso> | I dont have experience from the time, but Im sure it was useful to denote that a particular thing is a kind. |
| 2024-04-24 15:28:11 +0200 | <dminuoso> | i.e. `type family F (k :: BOX) ...` |
| 2024-04-24 15:28:25 +0200 | <dminuoso> | Maybe it was even necessary for some interaction with other exdtensions |
| 2024-04-24 15:29:19 +0200 | <danse-nr3> | so is that only Value -> Type now? |
| 2024-04-24 15:29:36 +0200 | <dminuoso> | No, its Value -> Type -> Type -> Type -> Type -> ... |
| 2024-04-24 15:29:55 +0200 | <danse-nr3> | oh |
| 2024-04-24 15:29:58 +0200 | <dminuoso> | Compare with Agda's infinite tower `Bool : Set : Set1 : Set2 : Set3 : ...` |
| 2024-04-24 15:30:36 +0200 | <dminuoso> | danse-nr3: Its why the most concise description of TypeInType is `Type :: Type` |
| 2024-04-24 15:30:48 +0200 | <haskellbridge> | <irregularsphere> sounds like an improvement over the finite tower though |
| 2024-04-24 15:31:19 +0200 | erty | (~user@user/aeroplane) |
| 2024-04-24 15:31:23 +0200 | <dminuoso> | irregularsphere: Well, it's a very important step for dependently typed haskell. |
| 2024-04-24 15:31:32 +0200 | <danse-nr3> | interesting, had a very different mental model, i also thought it was Value -> Type -> Kind -> YouDontWannaKnow |
| 2024-04-24 15:31:42 +0200 | ncf | . o O ( Bool : repeat Type ) |
| 2024-04-24 15:32:14 +0200 | <dminuoso> | Yeah that YouDontWannaKnow was called Sort at the time. |
| 2024-04-24 15:32:39 +0200 | <danse-nr3> | an infinite tower feels more freeing i guess (: |
| 2024-04-24 15:34:01 +0200 | <ncf> | agda also uses "sort" to talk about types of types (so, what haskell used to call kinds and sorts) |
| 2024-04-24 15:34:24 +0200 | <dminuoso> | So allowing for `Type :: Type` is a double edged swords. On one hand it acts as a simplification in the underlying type system, but it comes at the cost of allowing non-termination in the type system. |
| 2024-04-24 15:34:58 +0200 | <dminuoso> | But it was swiftly argued that we have plenty of mechanisms (e.g. tyfams) to do that anyway, so we already paid for that. |
| 2024-04-24 15:35:31 +0200 | <dminuoso> | https://www.seas.upenn.edu/~sweirich/papers/fckinds.pdf is a really nice paper to read |
| 2024-04-24 15:36:42 +0200 | <dminuoso> | ncf: The infinite tower is a requirement I believe if you want termination in a dependently typed language. |
| 2024-04-24 15:36:56 +0200 | <dminuoso> | Termination in the type system, that is. |
| 2024-04-24 15:37:00 +0200 | <dminuoso> | Or in type checking, rather. |
| 2024-04-24 15:37:03 +0200 | <ncf> | termination at all |
| 2024-04-24 15:37:50 +0200 | <ncf> | you can do russell's (or girard's) paradox and get a nonterminating term |
| 2024-04-24 15:38:47 +0200 | <dminuoso> | Ah I guess there's no difference since in a fully dependently typed language there no longer is a difference between expression and types? |