2023-07-07 00:00:17 +0200 | migas | (~migas@astra4961.startdedicated.net) (Remote host closed the connection) |
2023-07-07 00:00:33 +0200 | migas | (~migas@astra4961.startdedicated.net) |
2023-07-07 00:02:37 +0200 | reio | (~reio@86-90-81-176.fixed.kpn.net) (Remote host closed the connection) |
2023-07-07 00:04:32 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
2023-07-07 00:05:30 +0200 | acidjnk | (~acidjnk@p200300d6e7072f0700a8e9aef9077b5f.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
2023-07-07 00:06:24 +0200 | jargon | (~jargon@184.101.73.95) |
2023-07-07 00:07:21 +0200 | ai5lk | (~ai5lk@209-188-121-236.taosnet.com) (Quit: WeeChat 3.8) |
2023-07-07 00:09:36 +0200 | alternateved | (~user@77-254-166-50.dynamic.inetia.pl) (Remote host closed the connection) |
2023-07-07 00:13:23 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
2023-07-07 00:13:33 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 246 seconds) |
2023-07-07 00:13:46 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 245 seconds) |
2023-07-07 00:16:16 +0200 | Guest5320 | (~finn@176-151-21-224.abo.bbox.fr) (Ping timeout: 245 seconds) |
2023-07-07 00:17:41 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
2023-07-07 00:19:08 +0200 | delYsid` | (~user@84-115-138-74.cable.dynamic.surfer.at) |
2023-07-07 00:19:11 +0200 | delYsid | (~user@user/delYsid) (Ping timeout: 245 seconds) |
2023-07-07 00:19:51 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
2023-07-07 00:27:48 +0200 | mstksg | (~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 240 seconds) |
2023-07-07 00:30:00 +0200 | mstksg | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
2023-07-07 00:30:01 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 245 seconds) |
2023-07-07 00:30:51 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-179-175.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
2023-07-07 00:31:16 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 245 seconds) |
2023-07-07 00:34:05 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
2023-07-07 00:34:05 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
2023-07-07 00:34:05 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
2023-07-07 00:35:06 +0200 | phma | (phma@2001:5b0:215a:8658:2ff0:2260:7332:7cdc) (Read error: Connection reset by peer) |
2023-07-07 00:35:31 +0200 | phma | (~phma@host-67-44-208-75.hnremote.net) |
2023-07-07 00:39:59 +0200 | lainon | (~textual@c-98-54-78-2.hsd1.al.comcast.net) |
2023-07-07 00:41:04 +0200 | nick4 | (~nick@2600:8807:9084:7800:d846:c2ed:f029:599) |
2023-07-07 00:45:30 +0200 | nick4 | (~nick@2600:8807:9084:7800:d846:c2ed:f029:599) (Ping timeout: 260 seconds) |
2023-07-07 00:45:48 +0200 | sagax | (~sagax_nb@user/sagax) (Ping timeout: 240 seconds) |
2023-07-07 00:48:21 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 245 seconds) |
2023-07-07 00:50:01 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 245 seconds) |
2023-07-07 00:55:58 +0200 | phma | (~phma@host-67-44-208-75.hnremote.net) (Read error: Connection reset by peer) |
2023-07-07 01:02:24 +0200 | phma | (~phma@2001:5b0:211c:c328:623:9873:19c7:83ce) |
2023-07-07 01:02:48 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
2023-07-07 01:02:49 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
2023-07-07 01:02:49 +0200 | wroathe | (~wroathe@user/wroathe) |
2023-07-07 01:03:08 +0200 | xff0x_ | (~xff0x@ai086045.d.east.v6connect.net) (Ping timeout: 240 seconds) |
2023-07-07 01:04:27 +0200 | phma | (~phma@2001:5b0:211c:c328:623:9873:19c7:83ce) (Read error: Connection reset by peer) |
2023-07-07 01:04:54 +0200 | inversed | (~inversed@bcdcac82.skybroadband.com) (Read error: Connection reset by peer) |
2023-07-07 01:05:16 +0200 | xff0x_ | (~xff0x@178.255.149.135) |
2023-07-07 01:07:35 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
2023-07-07 01:09:51 +0200 | phma | (phma@2001:5b0:215a:da58:dcbf:27e8:323f:f6ce) |
2023-07-07 01:15:58 +0200 | <EvanR> | has anything changed since haskell98 regarding the lexical analysis step |
2023-07-07 01:16:34 +0200 | xff0x_ | (~xff0x@178.255.149.135) (Ping timeout: 250 seconds) |
2023-07-07 01:16:47 +0200 | Sgeo | (~Sgeo@user/sgeo) |
2023-07-07 01:18:31 +0200 | xff0x_ | (~xff0x@2405:6580:b080:900:50da:9b7c:4bac:847a) |
2023-07-07 01:21:56 +0200 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (Ping timeout: 246 seconds) |
2023-07-07 01:29:33 +0200 | <geekosaur> | the layout rule, as described lexically, has changed slightly to eliminate an ambiguity iirc |
2023-07-07 01:32:13 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
2023-07-07 01:44:37 +0200 | thegeekinside | (~thegeekin@189.217.90.138) (Read error: Connection reset by peer) |
2023-07-07 01:47:37 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.1) |
2023-07-07 01:48:58 +0200 | <monochrom> | dminuoso_: Haskell's "[Int]" becomes MLs' "int list". Now suppose you define your own ADT. Nothing stops you from naming it "t". And it it's a polymorphic type, users will be writing like "int t" instead of Haskell's "T Int". Furthermore, the ML communities are fond of naming their modules nicely, and say "<module name>.t" all the time, and not bother changing "t" to a better name, because the module name there is already the perfect name. |
2023-07-07 01:49:24 +0200 | billb | (~billb@cpe-66-8-173-22.hawaii.res.rr.com) (Quit: Leaving) |
2023-07-07 01:50:58 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
2023-07-07 01:51:01 +0200 | <geekosaur> | oh, is that where henningskell comes from? |
2023-07-07 01:51:23 +0200 | <monochrom> | YES :) |
2023-07-07 01:52:11 +0200 | mauke_ | (~mauke@user/mauke) |
2023-07-07 01:52:23 +0200 | monochrom | worked with SML in a previous life because of the theorem prover HOL4. |
2023-07-07 01:53:24 +0200 | mei | (~mei@user/mei) |
2023-07-07 01:53:46 +0200 | mauke | (~mauke@user/mauke) (Ping timeout: 245 seconds) |
2023-07-07 01:53:46 +0200 | mauke_ | mauke |
2023-07-07 01:54:25 +0200 | ski | . o O ( s/polymorphic type/parametric type/ ) |
2023-07-07 01:54:51 +0200 | <monochrom> | Yeah parametric type is better. |
2023-07-07 01:55:10 +0200 | <ski> | yea, it's a common convention in the MLs |
2023-07-07 01:55:26 +0200 | <ski> | i guess module functors kinda encourage it, too ? |
2023-07-07 01:59:00 +0200 | <ski> | (imagine writing a functor (a parameterized module) where the parameter module is expected to contain a type named `t', and a `compare' function operating on it) |
2023-07-07 01:59:23 +0200 | <monochrom> | I kind of didn't want to believe that, I was hoping that humans would be above using that as an excuse, but upon 2nd thought, yeah totally. :) |
2023-07-07 02:01:00 +0200 | <ski> | .. i'm not sure how common it is to anticipate that, by naming the type `t' (and then going on to pass that module directly to a functor), rather than construct a custom wrapper ("adapter") module when instantiating the functor |
2023-07-07 02:01:13 +0200 | <ski> | anyway, the (above) thought just occured to me |
2023-07-07 02:01:42 +0200 | xff0x_ | (~xff0x@2405:6580:b080:900:50da:9b7c:4bac:847a) (Ping timeout: 246 seconds) |
2023-07-07 02:03:51 +0200 | xff0x_ | (~xff0x@ai086045.d.east.v6connect.net) |
2023-07-07 02:04:28 +0200 | inversed | (~inversed@bcdcac82.skybroadband.com) |
2023-07-07 02:05:14 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
2023-07-07 02:06:38 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) |
2023-07-07 02:06:43 +0200 | sagax | (~sagax_nb@user/sagax) |
2023-07-07 02:09:34 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2023-07-07 02:13:39 +0200 | califax | (~califax@user/califx) |
2023-07-07 02:14:34 +0200 | falafel | (~falafel@2603-7000-a700-8710-eb2d-b2d5-726c-ab42.res6.spectrum.com) |
2023-07-07 02:25:48 +0200 | ddellacosta | (~ddellacos@146.70.166.152) (Ping timeout: 240 seconds) |
2023-07-07 02:26:26 +0200 | connrs | (~connrs@user/connrs) (Read error: Connection reset by peer) |
2023-07-07 02:27:31 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
2023-07-07 02:27:55 +0200 | ddellacosta | (~ddellacos@146.70.168.100) |
2023-07-07 02:29:05 +0200 | connrs | (~connrs@user/connrs) |
2023-07-07 02:31:48 +0200 | EvanR_ | (~EvanR@user/evanr) |
2023-07-07 02:32:04 +0200 | notzmv | (~zmv@user/notzmv) |
2023-07-07 02:32:16 +0200 | EvanR | (~EvanR@user/evanr) (Read error: Connection reset by peer) |
2023-07-07 02:33:28 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 240 seconds) |
2023-07-07 02:35:02 +0200 | caryhartline | (~caryhartl@168.182.58.169) (Quit: caryhartline) |
2023-07-07 02:39:37 +0200 | EvanR_ | EvanR |
2023-07-07 02:40:41 +0200 | lainon | (~textual@c-98-54-78-2.hsd1.al.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) |
2023-07-07 02:40:52 +0200 | thegeekinside | (~thegeekin@189.217.90.138) |
2023-07-07 02:41:05 +0200 | dmgk | (~dmgk@user/dmgk) |
2023-07-07 02:42:33 +0200 | <EvanR> | the extension LexicalNegation seems to mess with the lexer |
2023-07-07 02:42:51 +0200 | <EvanR> | everything I know is wrong now |
2023-07-07 02:43:14 +0200 | <Axman6> | Welcome to the future |
2023-07-07 02:44:12 +0200 | Inst_ | (~Inst@2601:6c4:4081:2fc0:1933:a56d:b98f:3d34) |
2023-07-07 02:48:02 +0200 | Inst__ | (~Inst@2601:6c4:4081:2fc0:44fe:e619:5fe8:5723) (Ping timeout: 246 seconds) |
2023-07-07 02:51:41 +0200 | thegeekinside | (~thegeekin@189.217.90.138) (Ping timeout: 245 seconds) |
2023-07-07 02:55:03 +0200 | <jackdk> | record dot syntax will also change the lexing of what would otherwise be an operator followed by an identifier |
2023-07-07 02:57:41 +0200 | <geekosaur> | even ExplicitForAll changes the lexer |
2023-07-07 02:59:57 +0200 | priesvitne_sklo | (~priesvitn@109-230-60-22.dynamic.orange.sk) |
2023-07-07 03:01:54 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds) |
2023-07-07 03:02:31 +0200 | inversed | (~inversed@bcdcac82.skybroadband.com) (Ping timeout: 245 seconds) |
2023-07-07 03:03:10 +0200 | delYsid` | (~user@84-115-138-74.cable.dynamic.surfer.at) (ERC 5.6-git (IRC client for GNU Emacs 30.0.50)) |
2023-07-07 03:08:21 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 245 seconds) |
2023-07-07 03:08:28 +0200 | <Axman6> | What even is a token??? Nobody knows |
2023-07-07 03:10:32 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
2023-07-07 03:10:37 +0200 | <Axman6> | So WAI has Application = Request -> (Response -> IO ResponseReceived) -> IO ResponseReceived, there isn't much sodumentation about what you should do with the response function, but it feels to me like it really should be treated as a linear argument, it should only be called once. is that something that can be done with current linear types? |
2023-07-07 03:11:41 +0200 | <Axman6> | Request -> (Response -> IO ResponseReceived) %1 -> IO ResponseReceived? |
2023-07-07 03:14:27 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.) |
2023-07-07 03:16:40 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
2023-07-07 03:18:11 +0200 | <EvanR> | are you sure, because there's more things in heaven and middleware than are dreamt of in your philosophy |
2023-07-07 03:19:18 +0200 | <Axman6> | I think it should always be the case that the response handler is only called once, even when middleware is involved, as it can wrap the passed in handler in a new function which itself is only called once |
2023-07-07 03:20:12 +0200 | <jackdk> | I think under this model you have `type Middleware = Application %1 -> Application`, so you consume the old respond function and provide a new one. |
2023-07-07 03:20:47 +0200 | <Axman6> | yeah that feels right |
2023-07-07 03:22:03 +0200 | bilegeek | (~bilegeek@2600:1008:b092:dfba:4ead:a88d:cd60:d095) |
2023-07-07 03:25:08 +0200 | <EvanR> | are you required to use the response function |
2023-07-07 03:26:12 +0200 | <EvanR> | or is it more of a continuation |
2023-07-07 03:26:24 +0200 | priesvitne_sklo | (~priesvitn@109-230-60-22.dynamic.orange.sk) (Ping timeout: 246 seconds) |
2023-07-07 03:33:24 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 246 seconds) |
2023-07-07 03:35:43 +0200 | <Axman6> | it's the only way to create a ResponseReceived, so yes |
2023-07-07 03:41:29 +0200 | <jackdk> | I believe it was done to avoid a rank-2 type, and the constructor is hard to find (not impossible, but you shouldn't go using it if you're writing an application) |
2023-07-07 03:54:03 +0200 | xff0x_ | (~xff0x@ai086045.d.east.v6connect.net) (Ping timeout: 246 seconds) |
2023-07-07 04:00:44 +0200 | phma | (phma@2001:5b0:215a:da58:dcbf:27e8:323f:f6ce) (Read error: Connection reset by peer) |
2023-07-07 04:01:07 +0200 | phma | (phma@2001:5b0:215a:da58:dcbf:27e8:323f:f6ce) |
2023-07-07 04:08:40 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
2023-07-07 04:10:21 +0200 | jargon | (~jargon@184.101.73.95) (Remote host closed the connection) |
2023-07-07 04:12:57 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 246 seconds) |
2023-07-07 04:14:38 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
2023-07-07 04:14:38 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
2023-07-07 04:14:39 +0200 | finn_elija | FinnElija |
2023-07-07 04:16:34 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
2023-07-07 04:17:59 +0200 | td_ | (~td@i53870936.versanet.de) (Ping timeout: 246 seconds) |
2023-07-07 04:19:34 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) |
2023-07-07 04:19:52 +0200 | td_ | (~td@i5387091B.versanet.de) |
2023-07-07 04:28:35 +0200 | trev | (~trev@user/trev) |
2023-07-07 04:29:33 +0200 | phma | (phma@2001:5b0:215a:da58:dcbf:27e8:323f:f6ce) (Read error: Connection reset by peer) |
2023-07-07 04:30:05 +0200 | phma | (~phma@host-67-44-208-87.hnremote.net) |
2023-07-07 04:42:48 +0200 | xff0x_ | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
2023-07-07 04:42:57 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
2023-07-07 04:46:22 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
2023-07-07 04:52:01 +0200 | <talismanick> | How difficult is it to learn/use Shake if you use Cabal and not Stack? |
2023-07-07 04:52:57 +0200 | <talismanick> | (I prefer Cabal because it's less restrictive wrt one-off libraries that don't fit neatly into Stackage releases) |
2023-07-07 04:53:16 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
2023-07-07 04:58:02 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
2023-07-07 05:02:13 +0200 | <jackdk> | As easy as any other hackage package. I have a few internal work projects built upon shake. |
2023-07-07 05:03:10 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
2023-07-07 05:03:21 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 245 seconds) |
2023-07-07 05:05:36 +0200 | mei | (~mei@user/mei) |
2023-07-07 05:07:14 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
2023-07-07 05:11:01 +0200 | <EvanR> | in the docs for Data.Scientific I find this warning |
2023-07-07 05:11:18 +0200 | <EvanR> | WARNING: 'coefficient' and 'base10exponent' violate substantivity of 'Eq'. |
2023-07-07 05:11:40 +0200 | <EvanR> | that was close, now what does substantivity mean |
2023-07-07 05:12:55 +0200 | <EvanR> | oh, there's an example demonstrating the phenomenon |
2023-07-07 05:16:29 +0200 | <EvanR> | they observe a difference in two scientifics that might report equal according to == |
2023-07-07 05:18:53 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 246 seconds) |
2023-07-07 05:24:38 +0200 | <sm> | talismanick: I think there's no real connection.. unless you are making your shake file a cabal or stack script ? |
2023-07-07 05:25:31 +0200 | <sm> | and that doesn't affect Shake's learnability |
2023-07-07 05:30:35 +0200 | <Axman6> | EvanR: is that because it doesn't make an effort to find the minimal mantissa? |
2023-07-07 05:31:47 +0200 | <EvanR> | something about the internal representation will be normalized when pretty printed or by toDecimalDigits |
2023-07-07 05:32:11 +0200 | <EvanR> | otherwise mantissa might have trailing zeros |
2023-07-07 05:35:33 +0200 | <Axman6> | so 123*10^-3 === 12300*10^-5? (pretty sure those are bout 1.23?) |
2023-07-07 05:35:37 +0200 | <Axman6> | both* |
2023-07-07 05:36:05 +0200 | <EvanR> | they look equal to me |
2023-07-07 05:36:30 +0200 | <Axman6> | but it doesn't normalise the latter into the former right? |
2023-07-07 05:36:55 +0200 | <EvanR> | according to the docs if you're messing with the internal representation, no |
2023-07-07 05:37:19 +0200 | <EvanR> | not after every operation like Rational |
2023-07-07 05:48:48 +0200 | aniketd[m] | (~aniketdma@2001:470:69fc:105::dede) () |
2023-07-07 05:49:11 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 245 seconds) |
2023-07-07 05:49:58 +0200 | aniketd[m] | (~aniketdma@2001:470:69fc:105::dede) |
2023-07-07 05:50:04 +0200 | jargon | (~jargon@184.101.73.95) |
2023-07-07 05:53:41 +0200 | aforemny_ | (~aforemny@2001:9e8:6ce6:ca00:3bad:e307:8f54:4c53) (Ping timeout: 246 seconds) |
2023-07-07 05:54:02 +0200 | aforemny | (~aforemny@i59F516EE.versanet.de) |
2023-07-07 06:05:53 +0200 | <Axman6> | man, python's coroutines make me feel very unconfortable, they feel so hacky |
2023-07-07 06:12:32 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 250 seconds) |
2023-07-07 06:12:51 +0200 | robertm | (robertm@lattice.rojoma.com) (Quit: WeeChat 3.8) |
2023-07-07 06:14:42 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
2023-07-07 06:15:11 +0200 | robertm | (robertm@lattice.rojoma.com) |
2023-07-07 06:16:48 +0200 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) |
2023-07-07 06:32:17 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
2023-07-07 06:34:28 +0200 | hololeap | (~quassel@user/hololeap) (Quit: Bye) |
2023-07-07 06:36:47 +0200 | hololeap | (~quassel@user/hololeap) |
2023-07-07 06:48:59 +0200 | jargon | (~jargon@184.101.73.95) (Remote host closed the connection) |
2023-07-07 06:53:33 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
2023-07-07 06:59:37 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
2023-07-07 07:07:44 +0200 | jargon | (~jargon@184.101.73.95) |
2023-07-07 07:07:54 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
2023-07-07 07:08:21 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
2023-07-07 07:09:00 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) |
2023-07-07 07:09:20 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
2023-07-07 07:09:28 +0200 | michalz | (~michalz@185.246.207.203) |
2023-07-07 07:10:39 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
2023-07-07 07:14:06 +0200 | <probie> | Axman6: The "new" ones using await (e.g. asyncio), or the old ones sending values to generators (as described in PEP-342)? |
2023-07-07 07:16:35 +0200 | <maerwald[m]> | https://discourse.haskell.org/t/rfc-bumping-recommended-ghc-to-9-4-5-in-ghcup/6866 |
2023-07-07 07:16:55 +0200 | Buggys | (Buggys@shelltalk.net) (Ping timeout: 246 seconds) |
2023-07-07 07:21:31 +0200 | stilgart | (~Christoph@chezlefab.net) (Quit: leaving) |
2023-07-07 07:21:42 +0200 | stilgart | (~Christoph@chezlefab.net) |
2023-07-07 07:26:04 +0200 | Buggys | (Buggys@Buggy.shelltalk.net) |
2023-07-07 07:27:03 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
2023-07-07 07:29:46 +0200 | praknak | (~praknak@bcdcac82.skybroadband.com) |
2023-07-07 07:33:51 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds) |
2023-07-07 07:40:14 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
2023-07-07 07:43:02 +0200 | Guest5320 | (~finn@176-151-21-224.abo.bbox.fr) |
2023-07-07 08:04:32 +0200 | bilegeek | (~bilegeek@2600:1008:b092:dfba:4ead:a88d:cd60:d095) (Quit: Leaving) |
2023-07-07 08:08:06 +0200 | genieliu | (~jianshili@36.112.90.53) |
2023-07-07 08:13:51 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
2023-07-07 08:17:15 +0200 | Guest5320 | (~finn@176-151-21-224.abo.bbox.fr) (Ping timeout: 246 seconds) |
2023-07-07 08:18:18 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 246 seconds) |
2023-07-07 08:22:02 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
2023-07-07 08:22:22 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 260 seconds) |
2023-07-07 08:23:50 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 250 seconds) |
2023-07-07 08:24:07 +0200 | son0p | (~ff@181.136.122.143) |
2023-07-07 08:29:59 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 246 seconds) |
2023-07-07 08:30:11 +0200 | Guest5320 | (~finn@176-151-21-224.abo.bbox.fr) |
2023-07-07 08:37:17 +0200 | fendor | (~fendor@2a02:8388:1640:be00:821b:25b5:c8f3:73a0) |
2023-07-07 08:45:48 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
2023-07-07 08:47:54 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2023-07-07 08:57:15 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-176-237.46.114.pool.telefonica.de) |
2023-07-07 08:59:02 +0200 | falafel | (~falafel@2603-7000-a700-8710-eb2d-b2d5-726c-ab42.res6.spectrum.com) (Ping timeout: 246 seconds) |
2023-07-07 09:00:18 +0200 | alternateved | (~user@77-254-166-50.dynamic.inetia.pl) |
2023-07-07 09:02:45 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) |
2023-07-07 09:05:23 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
2023-07-07 09:14:50 +0200 | genieliu | (~jianshili@36.112.90.53) (Quit: Lost terminal) |
2023-07-07 09:17:16 +0200 | gmg | (~user@user/gehmehgeh) |
2023-07-07 09:18:33 +0200 | mbuf | (~Shakthi@49.207.178.186) |
2023-07-07 09:21:47 +0200 | actioninja6 | (~actioninj@user/actioninja) (Ping timeout: 246 seconds) |
2023-07-07 09:23:31 +0200 | titibandit | (~titibandi@user/titibandit) |
2023-07-07 09:24:55 +0200 | ft | (~ft@p508db151.dip0.t-ipconnect.de) (Quit: leaving) |
2023-07-07 09:25:26 +0200 | priesvitne_sklo | (~priesvitn@109-230-60-22.dynamic.orange.sk) |
2023-07-07 09:25:36 +0200 | actioninja6 | (~actioninj@user/actioninja) |
2023-07-07 09:25:45 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
2023-07-07 09:28:04 +0200 | <Axman6> | probie: I'm going to say both |
2023-07-07 09:34:36 +0200 | shriekingnoise | (~shrieking@186.137.175.87) (Ping timeout: 245 seconds) |
2023-07-07 09:34:58 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2023-07-07 09:36:02 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
2023-07-07 09:36:55 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-176-237.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
2023-07-07 09:38:59 +0200 | Pickchea | (~private@user/pickchea) |
2023-07-07 09:42:33 +0200 | hisa38779 | (~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) |
2023-07-07 09:44:01 +0200 | acidjnk | (~acidjnk@p200300d6e7072f0600a8e9aef9077b5f.dip0.t-ipconnect.de) |
2023-07-07 09:44:03 +0200 | hisa3877 | (~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) (Ping timeout: 246 seconds) |
2023-07-07 09:44:03 +0200 | hisa38779 | hisa3877 |
2023-07-07 09:45:50 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
2023-07-07 09:48:43 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Remote host closed the connection) |
2023-07-07 09:50:08 +0200 | misterfish | (~misterfis@87.215.131.102) |
2023-07-07 09:52:54 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
2023-07-07 10:09:32 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
2023-07-07 10:16:49 +0200 | alternateved | (~user@77-254-166-50.dynamic.inetia.pl) (Remote host closed the connection) |
2023-07-07 10:18:36 +0200 | ubert | (~Thunderbi@2a02:8109:abc0:6434:2722:db0d:9dca:9984) |
2023-07-07 10:20:00 +0200 | alternateved | (~user@77-254-166-50.dynamic.inetia.pl) |
2023-07-07 10:21:45 +0200 | Sgeo_ | (~Sgeo@user/sgeo) |
2023-07-07 10:21:52 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
2023-07-07 10:25:12 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
2023-07-07 10:25:25 +0200 | danse-nr3_ | (~francesco@151.57.190.75) |
2023-07-07 10:25:31 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
2023-07-07 10:26:01 +0200 | gmg | (~user@user/gehmehgeh) |
2023-07-07 10:27:48 +0200 | <dminuoso_> | Axman6: I finally figured out whats wrong with python coroutines. |
2023-07-07 10:28:08 +0200 | <dminuoso_> | Python coroutines are in truth just an implementation detail of green threads. |
2023-07-07 10:30:07 +0200 | priesvitne_sklo | (~priesvitn@109-230-60-22.dynamic.orange.sk) (Remote host closed the connection) |
2023-07-07 10:30:21 +0200 | <dminuoso_> | There's so many red herrings around asyncio. The core theme is to facilitate efficient green thread scheduling on things that wait on external resources. |
2023-07-07 10:31:10 +0200 | <dminuoso_> | I mean Haskell has all of python asyncio built-in to GHC RTS + STM |
2023-07-07 10:32:15 +0200 | <dminuoso_> | Well, and some of `async` library for some of the thread coordination stuff. |
2023-07-07 10:35:17 +0200 | mmhat | (~mmh@p200300f1c716433cee086bfffe095315.dip0.t-ipconnect.de) |
2023-07-07 10:39:21 +0200 | danse-nr3_ | (~francesco@151.57.190.75) (Ping timeout: 246 seconds) |
2023-07-07 10:40:09 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
2023-07-07 10:43:07 +0200 | bliminse | (~bliminse@user/bliminse) (Quit: leaving) |
2023-07-07 10:49:48 +0200 | son0p | (~ff@181.136.122.143) |
2023-07-07 10:52:40 +0200 | danse-nr3_ | (~francesco@151.57.190.75) |
2023-07-07 10:53:00 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
2023-07-07 11:00:07 +0200 | dminuoso_ | dminuoso |
2023-07-07 11:00:28 +0200 | Sgeo_ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
2023-07-07 11:02:49 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-176-237.46.114.pool.telefonica.de) |
2023-07-07 11:09:35 +0200 | DustinStiles[m] | (~duwstiles@2001:470:69fc:105::3:699b) (Remote host closed the connection) |
2023-07-07 11:11:10 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
2023-07-07 11:12:02 +0200 | polykernel[m] | (~polykerne@user/polykernel) (Remote host closed the connection) |
2023-07-07 11:12:54 +0200 | gtf | (~gideon@2a02:8012:2259:0:299:560e:70f9:4290) |
2023-07-07 11:14:56 +0200 | barcisz | (~barcisz@79.191.32.38.ipv4.supernova.orange.pl) |
2023-07-07 11:18:07 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) (Remote host closed the connection) |
2023-07-07 11:26:56 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
2023-07-07 11:27:56 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 245 seconds) |
2023-07-07 11:28:16 +0200 | Lord_of_Life_ | Lord_of_Life |
2023-07-07 11:32:58 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
2023-07-07 11:41:22 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
2023-07-07 11:42:08 +0200 | fendor | (~fendor@2a02:8388:1640:be00:821b:25b5:c8f3:73a0) (Remote host closed the connection) |
2023-07-07 11:43:49 +0200 | fendor | (~fendor@2a02:8388:1640:be00:821b:25b5:c8f3:73a0) |
2023-07-07 11:45:50 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds) |
2023-07-07 12:02:56 +0200 | xff0x_ | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 245 seconds) |
2023-07-07 12:04:39 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
2023-07-07 12:06:08 +0200 | tcard_ | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving) |
2023-07-07 12:07:47 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
2023-07-07 12:09:26 +0200 | Pickchea | (~private@user/pickchea) |
2023-07-07 12:10:07 +0200 | danse-nr3_ | (~francesco@151.57.190.75) (Remote host closed the connection) |
2023-07-07 12:13:38 +0200 | barcisz | (~barcisz@79.191.32.38.ipv4.supernova.orange.pl) (Quit: Connection closed) |
2023-07-07 12:15:27 +0200 | danse-nr3_ | (~francesco@151.57.190.75) |
2023-07-07 12:15:57 +0200 | barcisz | (~barcisz@79.191.32.38.ipv4.supernova.orange.pl) |
2023-07-07 12:16:21 +0200 | dsrt^ | (~cd@24.125.210.85) |
2023-07-07 12:18:38 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) |
2023-07-07 12:19:37 +0200 | driib | (~driib@vmi931078.contaboserver.net) (Quit: The Lounge - https://thelounge.chat) |
2023-07-07 12:20:04 +0200 | driib | (~driib@vmi931078.contaboserver.net) |
2023-07-07 12:23:05 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) (Ping timeout: 246 seconds) |
2023-07-07 12:25:35 +0200 | azr4e1 | (~azr4e1@host86-134-72-140.range86-134.btcentralplus.com) |
2023-07-07 12:25:38 +0200 | azr4e1 | (~azr4e1@host86-134-72-140.range86-134.btcentralplus.com) (Remote host closed the connection) |
2023-07-07 12:37:28 +0200 | barcisz | (~barcisz@79.191.32.38.ipv4.supernova.orange.pl) (Quit: Connection closed) |
2023-07-07 12:39:36 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 245 seconds) |
2023-07-07 12:42:26 +0200 | Lewix | (uid158496@id-158496.tinside.irccloud.com) |
2023-07-07 12:42:32 +0200 | <Lewix> | hi all |
2023-07-07 12:42:36 +0200 | <Lewix> | is free node still alive? |
2023-07-07 12:43:29 +0200 | <Lewix> | I need to learn Haskell pretty fast, any advice that point me to the right direction would be appreciated. I'm a huge fan of functional programming but have not used it for years. |
2023-07-07 12:44:56 +0200 | <danse-nr3_> | been writing haskell for years and still have not learned it |
2023-07-07 12:46:02 +0200 | <tomsmeding> | Lewix: https://www.haskell.org/documentation/ is not very opinionated but perhaps a good start |
2023-07-07 12:49:58 +0200 | <Lewix> | @danse-nr3_ that is very encouraging :) |
2023-07-07 12:49:58 +0200 | <lambdabot> | Unknown command, try @list |
2023-07-07 12:50:19 +0200 | <Lewix> | @tomsmeding thank you man |
2023-07-07 12:50:19 +0200 | <lambdabot> | Unknown command, try @list |
2023-07-07 12:50:33 +0200 | <Lewix> | danse-nr3_: that is very encouraging :) |
2023-07-07 12:50:39 +0200 | <Lewix> | tomsmeding: thank you man! |
2023-07-07 12:51:10 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
2023-07-07 12:51:52 +0200 | <danse-nr3_> | apologies, was an indirect advice about setting expectations and the "need" requirement. The value-level language, focusing on pure code, is quite consistent and in my opinion one can get a long way by approaching it |
2023-07-07 12:52:32 +0200 | <Lewix> | tomsmeding: any video lecture that you enjoyed or would recommend? |
2023-07-07 12:52:38 +0200 | <Lewix> | danse-nr3_: noted. It's all good |
2023-07-07 12:57:15 +0200 | <juri_> | Lewix: it depends how you learn. i learn by doing, so more doing works. :) |
2023-07-07 12:57:27 +0200 | tomsmeding | is same as juri_ |
2023-07-07 12:57:42 +0200 | <tomsmeding> | find something you like building, and try to do it well |
2023-07-07 12:58:13 +0200 | <tomsmeding> | depending on your level, some of the slides here are nice https://uu-afp.github.io/schedule.html |
2023-07-07 12:58:53 +0200 | <Rembane> | Lewix: Also, come back here and ask questions whenever you get stuck! |
2023-07-07 12:59:50 +0200 | <probie> | If I write something which uses backpack, and upload it to hackage, will things for users break beyond the haddock docs? |
2023-07-07 13:01:45 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
2023-07-07 13:02:34 +0200 | gmg | (~user@user/gehmehgeh) |
2023-07-07 13:02:35 +0200 | merijn | (~merijn@097-099-045-062.dynamic.caiway.nl) |
2023-07-07 13:13:36 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) |
2023-07-07 13:14:32 +0200 | <maerwald[m]> | probie: stack users won't be able to use it |
2023-07-07 13:15:08 +0200 | hpc | (~juzz@ip98-169-35-163.dc.dc.cox.net) (Ping timeout: 240 seconds) |
2023-07-07 13:17:19 +0200 | hpc | (~juzz@ip98-169-35-163.dc.dc.cox.net) |
2023-07-07 13:20:25 +0200 | <dminuoso> | And depending on how much backpack you use, it can greatly limit the people capable or willing to work on your library. |
2023-07-07 13:23:12 +0200 | <probie> | dminuoso: That doesn't bother me. If they're not interested in it, they're not interested in it. Any library I write is non-proselytising |
2023-07-07 13:26:20 +0200 | <Lewix> | Also any resources to prepare for interview with Haskell is more than welcome |
2023-07-07 13:26:23 +0200 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
2023-07-07 13:26:28 +0200 | <Lewix> | Rembane: thank you |
2023-07-07 13:28:47 +0200 | <probie> | maerwald[m]: I thought stack uses cabal under the hood. Are there any issues if the libraries depended on are the implementation of backpack signatures? |
2023-07-07 13:30:37 +0200 | slaydr | (~slaydr@2601:1c2:980:4ea0::43b3) |
2023-07-07 13:33:09 +0200 | hippoid | (~hippoid@user/hippoid) |
2023-07-07 13:33:47 +0200 | ryantrinkle | (~ryantrink@89.247.249.243) (Ping timeout: 246 seconds) |
2023-07-07 13:37:10 +0200 | <merijn> | probie: https://gist.github.com/merijn/8152d561fb8b011f9313c48d876ceb07 |
2023-07-07 13:37:50 +0200 | merijn | increases the value of his "time saved on explaining the different meanings of cabal"-counter |
2023-07-07 13:39:36 +0200 | danse-nr3_ | (~francesco@151.57.190.75) (Ping timeout: 245 seconds) |
2023-07-07 13:40:12 +0200 | hippoid | (~hippoid@user/hippoid) (Quit: WeeChat 3.8) |
2023-07-07 13:40:57 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
2023-07-07 13:42:28 +0200 | pandeyan | (~pandeyan@135-180-53-134.fiber.dynamic.sonic.net) (Quit: ZNC 1.8.2 - https://znc.in) |
2023-07-07 13:45:25 +0200 | <probie> | That failed to answer my question, probably because I'm not particularly bright |
2023-07-07 13:46:12 +0200 | <probie> | but my current guess is that if there exists package X that's a dependency, whether X uses backpack or not is irrelevant to whether or not stack can install it |
2023-07-07 13:46:24 +0200 | anpad | (~pandeyan@user/anpad) |
2023-07-07 13:46:39 +0200 | <Rembane> | probie: I know way too little about Stack + backpack, but there's a very long thread about it here: https://github.com/commercialhaskell/stack/issues/2540 |
2023-07-07 13:47:06 +0200 | <probie> | in which case "stack users won't be able to use it" seems wrong. It seems like all they won't be able to do is instantiate backpack sigs |
2023-07-07 13:50:19 +0200 | danse-nr3_ | (~francesco@151.57.190.75) |
2023-07-07 13:53:01 +0200 | notzmv | (~zmv@user/notzmv) |
2023-07-07 13:54:22 +0200 | <dminuoso> | probie: Oh its not necessarily about proselytising, but rather about maintenance and ownership. |
2023-07-07 13:54:42 +0200 | <dminuoso> | The more exotic the tools used to build the product, the less people will contribute or be able to pick it up later on. |
2023-07-07 13:54:53 +0200 | <dminuoso> | I know, in this channel this is a heretic thing to say. |
2023-07-07 13:55:41 +0200 | <dminuoso> | It's much more fun to compile to categories with dependent types, using highly undocumented cabal features.. |
2023-07-07 13:56:40 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
2023-07-07 13:57:22 +0200 | <tomsmeding> | and use TH in the process |
2023-07-07 14:09:05 +0200 | barcisz | (~barcisz@79.191.32.38.ipv4.supernova.orange.pl) |
2023-07-07 14:11:47 +0200 | xff0x_ | (~xff0x@ai086045.d.east.v6connect.net) |
2023-07-07 14:13:27 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) |
2023-07-07 14:16:14 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
2023-07-07 14:25:56 +0200 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) |
2023-07-07 14:26:38 +0200 | danse-nr3_ | (~francesco@151.57.190.75) (Read error: Connection reset by peer) |
2023-07-07 14:26:51 +0200 | danse-nr3_ | (~francesco@151.57.136.214) |
2023-07-07 14:40:04 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
2023-07-07 14:46:17 +0200 | slaydr | (~slaydr@2601:1c2:980:4ea0::43b3) (Read error: Connection reset by peer) |
2023-07-07 14:46:47 +0200 | Guest5320 | (~finn@176-151-21-224.abo.bbox.fr) (Ping timeout: 264 seconds) |
2023-07-07 14:48:22 +0200 | <jackdk> | hasn't backpack been out for yonks though? |
2023-07-07 14:49:18 +0200 | <merijn> | jackdk: Yes |
2023-07-07 14:49:24 +0200 | <merijn> | probably close to a decade or longer |
2023-07-07 14:57:34 +0200 | ft | (~ft@p508db151.dip0.t-ipconnect.de) |
2023-07-07 14:59:39 +0200 | pyooque | (~puke@user/puke) |
2023-07-07 14:59:39 +0200 | puke | Guest8530 |
2023-07-07 14:59:39 +0200 | Guest8530 | (~puke@user/puke) (Killed (platinum.libera.chat (Nickname regained by services))) |
2023-07-07 14:59:39 +0200 | pyooque | puke |
2023-07-07 15:18:07 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.1) |
2023-07-07 15:24:08 +0200 | Zambyte | (~user@c-73-114-31-74.hsd1.ma.comcast.net) |
2023-07-07 15:24:36 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
2023-07-07 15:24:36 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
2023-07-07 15:24:36 +0200 | wroathe | (~wroathe@user/wroathe) |
2023-07-07 15:24:50 +0200 | <Profpatsch> | I want to replace a bunch of allocation bracket functions with a single ResourceT block |
2023-07-07 15:26:03 +0200 | <Profpatsch> | is ResourceT.allocate forkIO killThread a viable way to wrap a thread that has a sub-task which does not need cleanup itself? |
2023-07-07 15:36:55 +0200 | comerijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
2023-07-07 15:38:28 +0200 | kimiamania6 | (~681cf57f@user/kimiamania) (Quit: PegeLinux) |
2023-07-07 15:39:09 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
2023-07-07 15:39:51 +0200 | kimiamania6 | (~681cf57f@user/kimiamania) |
2023-07-07 15:39:56 +0200 | merijn | (~merijn@097-099-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2023-07-07 15:40:15 +0200 | <Profpatsch> | Hm, seems to work |
2023-07-07 15:40:28 +0200 | <Profpatsch> | (it’s just for a dumb heartbeat log output) |
2023-07-07 15:47:58 +0200 | barcisz | (~barcisz@79.191.32.38.ipv4.supernova.orange.pl) (Quit: Connection closed) |
2023-07-07 15:55:16 +0200 | <Inst_> | bleh, going back to translating "Big Book of Small Python Projects" into Haskell |
2023-07-07 15:56:12 +0200 | <Inst_> | i'm trying to do a vigniere cipher, but via HOF instead of manual recursion |
2023-07-07 15:57:14 +0200 | <Inst_> | ehh, the probable solution is foldr |
2023-07-07 15:58:51 +0200 | barcisz | (~barcisz@79.191.32.38.ipv4.supernova.orange.pl) |
2023-07-07 16:00:05 +0200 | <int-e> | zipWith and cycle? |
2023-07-07 16:02:38 +0200 | lainon | (~textual@2601:7c0:cb00:c0a0:718c:10e2:ff4c:a39) |
2023-07-07 16:03:37 +0200 | lainon | (~textual@2601:7c0:cb00:c0a0:718c:10e2:ff4c:a39) (Client Quit) |
2023-07-07 16:08:00 +0200 | <tomsmeding> | ^ |
2023-07-07 16:14:49 +0200 | jinsl | (~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea) (Quit: ZNC - https://znc.in) |
2023-07-07 16:17:06 +0200 | juri_ | (~juri@84-19-175-187.pool.ovpn.com) (Ping timeout: 245 seconds) |
2023-07-07 16:18:01 +0200 | <Profpatsch> | Hm, is there any multiplication that can determine wraparound on Iont? |
2023-07-07 16:18:03 +0200 | <Profpatsch> | *Int? |
2023-07-07 16:18:13 +0200 | <Profpatsch> | Maybe a newtype that throws an exception? |
2023-07-07 16:19:19 +0200 | jinsl | (~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea) |
2023-07-07 16:23:15 +0200 | Midjak | (~Midjak@82.66.147.146) |
2023-07-07 16:24:41 +0200 | <c_wraith> | I suppose you could do that, but detecting it in ways that aren't architecture-specific is an incredible slowdown. |
2023-07-07 16:26:00 +0200 | <Profpatsch> | I just had to double and checked whether the result is smaller, which should be pretty easy |
2023-07-07 16:26:05 +0200 | <Profpatsch> | It’s not a tight loop anyway |
2023-07-07 16:26:37 +0200 | <Profpatsch> | Kind of a weird excercise anyway dunno why I’m spending time on this lol |
2023-07-07 16:26:44 +0200 | <Profpatsch> | Mostly out of interest I guess |
2023-07-07 16:28:15 +0200 | <c_wraith> | the most general way to detect it is look for the sign of the output being wrong. |
2023-07-07 16:28:57 +0200 | <c_wraith> | add two positive numbers and get a negative? multiply a negative number by a positive number and get a positive? |
2023-07-07 16:28:59 +0200 | juri_ | (~juri@84-19-175-187.pool.ovpn.com) |
2023-07-07 16:29:03 +0200 | thegeekinside | (~thegeekin@189.217.90.138) |
2023-07-07 16:33:19 +0200 | Arima_Kun | (~Arima_Kun@45.124.5.97) |
2023-07-07 16:33:57 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 245 seconds) |
2023-07-07 16:36:34 +0200 | misterfish | (~misterfis@87.215.131.102) (Ping timeout: 260 seconds) |
2023-07-07 16:36:44 +0200 | Arima_Kun | (~Arima_Kun@45.124.5.97) (Client Quit) |
2023-07-07 16:37:02 +0200 | ripspin | (~chatzilla@1.145.156.103) |
2023-07-07 16:41:52 +0200 | <Inst_> | int-e: i'm trying to skip non-alphanumerical characters |
2023-07-07 16:47:33 +0200 | juri_ | (~juri@84-19-175-187.pool.ovpn.com) (Ping timeout: 246 seconds) |
2023-07-07 16:52:09 +0200 | jinsl | (~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea) (Quit: ZNC - https://znc.in) |
2023-07-07 16:54:01 +0200 | jinsl | (~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea) |
2023-07-07 16:57:57 +0200 | jinsl | (~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea) (Client Quit) |
2023-07-07 16:59:27 +0200 | juri_ | (~juri@84-19-175-187.pool.ovpn.com) |
2023-07-07 17:00:25 +0200 | shriekingnoise | (~shrieking@186.137.175.87) |
2023-07-07 17:02:20 +0200 | <EvanR> | perform the operation on an intermediate Integer and check the "actual result" for overflow xD |
2023-07-07 17:04:14 +0200 | <EvanR> | Inst_, span and break? |
2023-07-07 17:09:01 +0200 | <janus> | anybody at munihac? i landed a bit late, not sure where people are now |
2023-07-07 17:11:18 +0200 | barcisz | (~barcisz@79.191.32.38.ipv4.supernova.orange.pl) (Quit: Connection closed) |
2023-07-07 17:13:12 +0200 | barcisz | (~barcisz@79.191.32.38.ipv4.supernova.orange.pl) |
2023-07-07 17:17:12 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
2023-07-07 17:21:29 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) (Remote host closed the connection) |
2023-07-07 17:21:46 +0200 | <Inst_> | is there a better way to do it? |
2023-07-07 17:22:11 +0200 | <Inst_> | i mean, i'm pretty satisfied with using foldr on the cycled key |
2023-07-07 17:22:33 +0200 | <EvanR> | in a sense foldr can do anything |
2023-07-07 17:22:37 +0200 | <Inst_> | and using right fold as left fold |
2023-07-07 17:23:14 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) |
2023-07-07 17:23:15 +0200 | acidjnk | (~acidjnk@p200300d6e7072f0600a8e9aef9077b5f.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
2023-07-07 17:23:20 +0200 | alternateved | (~user@77-254-166-50.dynamic.inetia.pl) (Ping timeout: 250 seconds) |
2023-07-07 17:23:50 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
2023-07-07 17:23:55 +0200 | <Inst_> | so you have an outside accumulator that's the actual text, and the cycled key as what's being folded over, with the lambda being keyed to process the accumulator |
2023-07-07 17:24:05 +0200 | <Inst_> | mildly annoyed that foldr1 doesn't work with this |
2023-07-07 17:25:32 +0200 | <EvanR> | if you're talking about accumulators then you probably (a form of) foldl |
2023-07-07 17:25:39 +0200 | <EvanR> | probably want* |
2023-07-07 17:25:52 +0200 | <Inst_> | iirc you can't use an outside accumulator... |
2023-07-07 17:26:03 +0200 | <EvanR> | what does that mean |
2023-07-07 17:26:26 +0200 | <Inst_> | well, i think you can do it that way |
2023-07-07 17:27:15 +0200 | <Inst_> | you know the foldr trick wherein you have (foldr fun (const foo) list1 list2), right? |
2023-07-07 17:27:27 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) (Ping timeout: 246 seconds) |
2023-07-07 17:27:50 +0200 | <Inst_> | well tbh maybe i can exploit laziness and the fact that seq won't force the evaluation beneath a tuple |
2023-07-07 17:27:53 +0200 | <EvanR> | no but that's looks groovy before I've had coffee |
2023-07-07 17:28:25 +0200 | nick4 | (~nick@2600:8807:9084:7800:6937:8c50:52d4:31ba) |
2023-07-07 17:28:51 +0200 | <Inst_> | so i can still have an infinite list with seq, just it can't be on the top level, right? |
2023-07-07 17:28:51 +0200 | <EvanR> | if you have 2 parallel accumulators that's just a foldl using a tuple |
2023-07-07 17:29:35 +0200 | <Inst_> | iirc even if you seq a list, it won't trigger a bottom, right? You'd need force from deepseq to trigger a bottom from an infinite list? |
2023-07-07 17:29:44 +0200 | <geekosaur> | yes |
2023-07-07 17:29:51 +0200 | <geekosaur> | `seq` is only to WHNF |
2023-07-07 17:30:14 +0200 | <EvanR> | > [undefined] `seq` '👍' |
2023-07-07 17:30:16 +0200 | <lambdabot> | '\128077' |
2023-07-07 17:32:34 +0200 | <Inst_> | but tbh foldr stil lworks better if i'm working with lists, no? |
2023-07-07 17:33:01 +0200 | <Inst_> | since the foldr can lazily generate the list, whereas foldl' will have to complete the list before it can produce any output? |
2023-07-07 17:33:03 +0200 | <EvanR> | foldr is pretty bad when adding up a list for example |
2023-07-07 17:33:15 +0200 | <EvanR> | unless you're scanning for all intermediate sums |
2023-07-07 17:33:22 +0200 | <Inst_> | i mean foldr (:) is performant, no? |
2023-07-07 17:33:30 +0200 | <Inst_> | foldr (:) [] |
2023-07-07 17:33:36 +0200 | <EvanR> | that's lazy |
2023-07-07 17:33:47 +0200 | <EvanR> | which is good |
2023-07-07 17:34:49 +0200 | <EvanR> | foldl and foldl' don't work on infinite lists |
2023-07-07 17:35:15 +0200 | <Inst_> | the problem is that i don't feel like map is powerful enough for it, i.e, there's an implicitly mutating accumulator here |
2023-07-07 17:35:26 +0200 | <EvanR> | :t mapAccum |
2023-07-07 17:35:26 +0200 | <Inst_> | was looking at map accum, but not familiar with it, was thinking scanr / scanl, but not used to it |
2023-07-07 17:35:27 +0200 | <lambdabot> | error: |
2023-07-07 17:35:27 +0200 | <lambdabot> | • Variable not in scope: mapAccum |
2023-07-07 17:35:27 +0200 | <lambdabot> | • Perhaps you meant one of these: |
2023-07-07 17:35:31 +0200 | <EvanR> | :t mapAccumR |
2023-07-07 17:35:32 +0200 | <lambdabot> | Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
2023-07-07 17:35:50 +0200 | <EvanR> | :t mapAccumL |
2023-07-07 17:35:51 +0200 | <lambdabot> | Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
2023-07-07 17:36:18 +0200 | <EvanR> | it's map with an accumulator |
2023-07-07 17:36:47 +0200 | <Inst_> | maybe mapaccum is the best solution here |
2023-07-07 17:37:27 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
2023-07-07 17:38:58 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) |
2023-07-07 17:39:59 +0200 | mmhat | (~mmh@p200300f1c716433cee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 4.0.1) |
2023-07-07 17:40:20 +0200 | titibandit | (~titibandi@user/titibandit) (Remote host closed the connection) |
2023-07-07 17:41:27 +0200 | juri_ | (~juri@84-19-175-187.pool.ovpn.com) (Ping timeout: 246 seconds) |
2023-07-07 17:42:28 +0200 | Sgeo | (~Sgeo@user/sgeo) |
2023-07-07 17:49:14 +0200 | JanusTroelsen[m] | (~janustmat@2001:470:69fc:105::3:7e89) |
2023-07-07 17:53:18 +0200 | juri_ | (~juri@84-19-175-187.pool.ovpn.com) |
2023-07-07 17:54:13 +0200 | danse-nr3_ | (~francesco@151.57.136.214) (Read error: Connection reset by peer) |
2023-07-07 18:00:29 +0200 | nick4 | (~nick@2600:8807:9084:7800:6937:8c50:52d4:31ba) (Ping timeout: 246 seconds) |
2023-07-07 18:00:51 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 245 seconds) |
2023-07-07 18:00:56 +0200 | <ski> | Inst_ : why accumulator ? |
2023-07-07 18:02:44 +0200 | jinsl | (~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea) |
2023-07-07 18:04:24 +0200 | Ross[m] | (~zhichuche@2001:470:69fc:105::3:584b) (Remote host closed the connection) |
2023-07-07 18:07:23 +0200 | <Inst_> | let's say you're doing a vigenere cipher |
2023-07-07 18:07:32 +0200 | <Inst_> | the way i'm doing it is that i'm encoding the key as a list of ints (offsets) |
2023-07-07 18:08:38 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) |
2023-07-07 18:09:09 +0200 | <Inst_> | bleh, my brain is dead |
2023-07-07 18:10:27 +0200 | <ski> | sounds reasonable, so far |
2023-07-07 18:11:10 +0200 | <Inst_> | maybe there's an easier way to do it |
2023-07-07 18:11:17 +0200 | <Inst_> | i need zip to be able to skip whitespace and symbols, etc |
2023-07-07 18:11:44 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
2023-07-07 18:11:50 +0200 | <ski> | hm, i see |
2023-07-07 18:12:06 +0200 | <ski> | so you're keeping the key as the accumulator, yes ? |
2023-07-07 18:12:54 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
2023-07-07 18:13:02 +0200 | <Inst_> | yeah |
2023-07-07 18:13:08 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
2023-07-07 18:13:25 +0200 | <Inst_> | anyways, moved onto a different problem, which is figuring out how to get haskell win32 to replicate the clipboard copy function |
2023-07-07 18:14:10 +0200 | mei | (~mei@user/mei) |
2023-07-07 18:14:38 +0200 | <EvanR> | are you using win32 bindings or something |
2023-07-07 18:15:12 +0200 | <Inst_> | should I be using something else? |
2023-07-07 18:15:22 +0200 | <EvanR> | no just wondering |
2023-07-07 18:15:22 +0200 | <Inst_> | "type HANDLE = Ptr ()" |
2023-07-07 18:19:38 +0200 | nick4 | (~nick@50.86.118.19) |
2023-07-07 18:22:49 +0200 | <Inst_> | https://hackage.haskell.org/package/Clipboard |
2023-07-07 18:22:51 +0200 | <Inst_> | this is just a better idea |
2023-07-07 18:24:51 +0200 | <Inst_> | okay, does not support Wayland |
2023-07-07 18:24:52 +0200 | <Inst_> | doip |
2023-07-07 18:25:01 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 245 seconds) |
2023-07-07 18:26:31 +0200 | <Inst_> | provisionally: |
2023-07-07 18:26:32 +0200 | <Inst_> | https://paste.tomsmeding.com/RLzR9DHm |
2023-07-07 18:26:46 +0200 | barcisz | (~barcisz@79.191.32.38.ipv4.supernova.orange.pl) (Quit: Connection closed) |
2023-07-07 18:28:55 +0200 | <Inst_> | okay, and it works, with some typos |
2023-07-07 18:30:48 +0200 | dtman34 | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) (Ping timeout: 240 seconds) |
2023-07-07 18:30:53 +0200 | <EvanR> | \o/ |
2023-07-07 18:31:57 +0200 | <Inst_> | btw why is there only mapAccumL not mapAccumL'? |
2023-07-07 18:32:06 +0200 | nick4 | (~nick@50.86.118.19) (Ping timeout: 245 seconds) |
2023-07-07 18:32:16 +0200 | dtman34 | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) |
2023-07-07 18:37:39 +0200 | <int-e> | because the result of the accumulator function is forced? (the pair has to be deconstructed) |
2023-07-07 18:38:09 +0200 | <EvanR> | I see a 10 year old mailing list thread on the topic and it seems to be an episode in the debate on why sum should be foldl and not foldl' |
2023-07-07 18:38:18 +0200 | <int-e> | s/accumulator/step/ |
2023-07-07 18:38:40 +0200 | <EvanR> | deconstruct a pair doesn't force the accumulator though |
2023-07-07 18:39:47 +0200 | <int-e> | But you have the power to do so inside the step function. |
2023-07-07 18:40:05 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
2023-07-07 18:40:08 +0200 | <int-e> | a `seq` c `seq` (a,c) |
2023-07-07 18:41:01 +0200 | <int-e> | With foldl, you don't have that ability. |
2023-07-07 18:41:10 +0200 | <EvanR> | I was about to say |
2023-07-07 18:41:36 +0200 | <int-e> | So having `foldl'` is practically a necessity. |
2023-07-07 18:43:04 +0200 | <int-e> | (Also, there are two elements in that pair so if you start offering strict versions of mapAccumL, do you force both or only one of them, or do you provide four variants? And how do you name them?) |
2023-07-07 18:43:26 +0200 | <EvanR> | I see, foldl immediately recurses to the end of the list before doing anything else, mapAccumL sets up a chain of (non-lazy) tuples |
2023-07-07 18:43:48 +0200 | <EvanR> | so your code is running at each step |
2023-07-07 18:44:23 +0200 | <EvanR> | or... |
2023-07-07 18:45:25 +0200 | <Inst_> | ffff |
2023-07-07 18:45:54 +0200 | <Inst_> | jesus christ, someone talked me into using if then else for when you only have two alternatives, but even though it's more terse, i somehow feel that guards are still more readable overall |
2023-07-07 18:45:56 +0200 | <int-e> | ffffine? |
2023-07-07 18:46:20 +0200 | <int-e> | (too slow) |
2023-07-07 18:46:55 +0200 | <dolio> | I usually prefer guards, I think. |
2023-07-07 18:47:11 +0200 | <dolio> | Unless it's in the middle of some other expression. |
2023-07-07 18:48:30 +0200 | <int-e> | yeah it's situational |
2023-07-07 18:48:34 +0200 | <EvanR> | ok like scanl mapAccumL on list works as long as you carefully consume the result, and via magic of update frames, you don't hold on to old accumulators |
2023-07-07 18:55:07 +0200 | <Inst_> | is it really smelly to immediately map into an IO action before binding it? |
2023-07-07 18:55:26 +0200 | <Inst_> | say, transform <$> getLine |
2023-07-07 18:55:39 +0200 | <EvanR> | miranda guards ftw https://paste.tomsmeding.com/LABOLtZy |
2023-07-07 18:57:40 +0200 | <tomsmeding> | Inst_: that's a common pattern |
2023-07-07 18:57:50 +0200 | fendor | (~fendor@2a02:8388:1640:be00:821b:25b5:c8f3:73a0) (Remote host closed the connection) |
2023-07-07 18:59:59 +0200 | <EvanR> | lines <$> getContents -- 😎 |
2023-07-07 19:01:51 +0200 | <[exa]> | Inst_: is it really "before" binding it? |
2023-07-07 19:02:25 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
2023-07-07 19:02:45 +0200 | <EvanR> | stuff <- getLine <&> transform -- there you go |
2023-07-07 19:03:48 +0200 | <Inst_> | afaik IO is strict, no? |
2023-07-07 19:04:02 +0200 | <Inst_> | it's only lazy when you unsafeInterleaveIO it, and some IO functions have built-ins, no? |
2023-07-07 19:04:08 +0200 | <[exa]> | it is, with respect to other IO actions |
2023-07-07 19:04:09 +0200 | <Inst_> | erm, built-in unsafeInterleaveIO? |
2023-07-07 19:06:38 +0200 | <[exa]> | but binding doesn't technically "do" anything so it's pretty hard to say "when" (or even if) it happens |
2023-07-07 19:07:07 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
2023-07-07 19:08:36 +0200 | <tomsmeding> | Inst_: if X is a normal IO action, then f <$> X will first fully complete X, and then apply f to the result |
2023-07-07 19:09:01 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
2023-07-07 19:09:17 +0200 | <tomsmeding> | indeed for things that implement "lazy IO", like getContents, readFile, and perhaps also getLine, there is some unsafeInterleaveIO happening so that the IO is happening on-demand as consumers need its result |
2023-07-07 19:09:50 +0200 | <tomsmeding> | but f doesn't demand X's result -- if f's result is unused, still nothing happens |
2023-07-07 19:10:13 +0200 | <tomsmeding> | or, well, IO's (>>=) evaluates the result of the LHS to WHNF, so something might happen, but probably not much |
2023-07-07 19:10:23 +0200 | ripspin | (~chatzilla@1.145.156.103) (Remote host closed the connection) |
2023-07-07 19:10:52 +0200 | <tomsmeding> | but there's little difference between 'do { tmp <- getLine ; let stuff = transform tmp ; ...}' and 'do { stuff <- transform <$> getLine ; ... }' |
2023-07-07 19:11:11 +0200 | <EvanR> | getLine from System.IO at least blocks until it gets a whole line |
2023-07-07 19:11:15 +0200 | <tomsmeding> | I think not even a WHNF laziness difference, if IO's fmap is consistent with its (>>=) |
2023-07-07 19:11:18 +0200 | <tomsmeding> | ah |
2023-07-07 19:12:44 +0200 | <EvanR> | in some languages there's a style convention to put I/O statements like getLine on their own line, resulting in an increase in variable names |
2023-07-07 19:12:56 +0200 | <EvanR> | instead of doing a lot on one line |
2023-07-07 19:14:10 +0200 | <Inst_> | Some or most? |
2023-07-07 19:14:38 +0200 | perrierjouet | (~perrierjo@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 4.0.0) |
2023-07-07 19:14:43 +0200 | <EvanR> | no I'm going to chalk that one up to bizarre cult-like behavior |
2023-07-07 19:15:35 +0200 | <EvanR> | chaining operations together reduces variable naming |
2023-07-07 19:17:53 +0200 | <Inst_> | but isn't variable naming useful? Like, some programmers don't believe in anonymous lambdas |
2023-07-07 19:18:15 +0200 | <dolio> | Sometimes. Sometimes not. |
2023-07-07 19:18:36 +0200 | <Inst_> | Going into Python, I get chortles when I insist on keeping the Haskell idiom of named lambdas and actually assigning them before I use them. |
2023-07-07 19:18:40 +0200 | <dolio> | Just like parentheses. Sometimes they make things clearer. Sometimes they make things less clear. |
2023-07-07 19:19:11 +0200 | <EvanR> | yeah you can't go into python acting like it's haskell |
2023-07-07 19:19:27 +0200 | mbuf | (~Shakthi@49.207.178.186) (Quit: Leaving) |
2023-07-07 19:19:41 +0200 | <Inst_> | I've read in places actually naming your lambdas somehow improves performance |
2023-07-07 19:19:55 +0200 | <EvanR> | that's annoying |
2023-07-07 19:20:05 +0200 | <Inst_> | Python is annoying, what else is new? |
2023-07-07 19:20:40 +0200 | <EvanR> | they should introduce an internal name on your behalf then xD |
2023-07-07 19:21:07 +0200 | <EvanR> | make it two for good measure |
2023-07-07 19:21:25 +0200 | jinsun | (~jinsun@user/jinsun) |
2023-07-07 19:21:38 +0200 | ubert | (~Thunderbi@2a02:8109:abc0:6434:2722:db0d:9dca:9984) (Read error: Connection reset by peer) |
2023-07-07 19:22:52 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2023-07-07 19:25:24 +0200 | captnemo | (~captnemo@193.32.127.239) |
2023-07-07 19:31:17 +0200 | nick4 | (~nick@2600:8807:9084:7800:dc97:418d:c7fc:117f) |
2023-07-07 19:36:52 +0200 | <EvanR> | int-e, https://mail.haskell.org/pipermail/libraries/2012-November/018766.html 🤔 |
2023-07-07 19:36:57 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 246 seconds) |
2023-07-07 19:39:29 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2023-07-07 19:41:52 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 245 seconds) |
2023-07-07 19:43:49 +0200 | comerijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 240 seconds) |
2023-07-07 19:46:29 +0200 | danse-nr3 | (~francesco@151.43.173.33) |
2023-07-07 19:46:45 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 246 seconds) |
2023-07-07 19:49:33 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 246 seconds) |
2023-07-07 19:49:53 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
2023-07-07 19:49:53 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
2023-07-07 19:49:53 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
2023-07-07 19:50:05 +0200 | <int-e> | EvanR: oh hmm. I guess the issue then is that let !(x,y) = mapAccumL (\a b -> let !x = a+b in (x, ())) 0 [1..1000000 :: Int] gives you a big unevaluated thunk for x. |
2023-07-07 19:51:14 +0200 | <int-e> | But if you evaluate the resulting `y` to the end, that will also evaluate x. |
2023-07-07 19:51:24 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
2023-07-07 19:51:37 +0200 | <EvanR> | aiui it depends on what you do next, look at x first and you're screwed. Process all of y you're not |
2023-07-07 19:51:41 +0200 | Lewix | (uid158496@id-158496.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
2023-07-07 19:52:16 +0200 | <int-e> | yeah as I was trying to say |
2023-07-07 19:52:29 +0200 | <EvanR> | that bang(x,y) doesn't do anything right |
2023-07-07 19:52:41 +0200 | <dolio> | Right. |
2023-07-07 19:52:56 +0200 | <dolio> | Oh wait, no, it does. |
2023-07-07 19:52:59 +0200 | <int-e> | EvanR: well, it does *something*; it overrides the default laziness of `let`. |
2023-07-07 19:53:23 +0200 | <EvanR> | default laziness? |
2023-07-07 19:53:25 +0200 | <dolio> | It only does something with respect to code that wasn't written, though. |
2023-07-07 19:53:28 +0200 | <int-e> | EvanR: but it doesn't do much in this context because `mapAccumL` is using a lazy-in-state state monad. |
2023-07-07 19:53:40 +0200 | <int-e> | > let (x,y) = undefined in () |
2023-07-07 19:53:41 +0200 | <lambdabot> | () |
2023-07-07 19:53:43 +0200 | <int-e> | > let !(x,y) = undefined in () |
2023-07-07 19:53:44 +0200 | <lambdabot> | *Exception: Prelude.undefined |
2023-07-07 19:54:28 +0200 | <int-e> | So there's room for a mapAccumL variant that uses a strict-in-state state monad. |
2023-07-07 19:55:12 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 245 seconds) |
2023-07-07 19:56:23 +0200 | <EvanR> | would that hypothetically mean you don't have to be as careful with the results? |
2023-07-07 19:58:42 +0200 | <dolio> | If mapAccumL gets inlined, does GHC just figure out the strictness? |
2023-07-07 19:59:34 +0200 | <dolio> | Similar to sum on particular types. |
2023-07-07 20:00:09 +0200 | nurupo | (~nurupo.ga@user/nurupo) (Quit: nurupo.ga) |
2023-07-07 20:00:20 +0200 | <int-e> | @where L.hs |
2023-07-07 20:00:20 +0200 | <lambdabot> | what lambdabot has in scope is at https://silicon.int-e.eu/lambdabot/State/Pristine.hs |
2023-07-07 20:00:24 +0200 | nurupo | (~nurupo.ga@user/nurupo) |
2023-07-07 20:01:05 +0200 | <int-e> | @let import Control.Monad.State.Strict as S' |
2023-07-07 20:01:07 +0200 | <lambdabot> | Defined. |
2023-07-07 20:01:56 +0200 | <dolio> | Strict State isn't strict in the state value. It just forces the tuple in (>>=) or something. |
2023-07-07 20:02:08 +0200 | <EvanR> | let (x,y) = undefined in () ==> (), case undefined of (x,y) -> () ==> CRASH, case undefined of ~(x,y) -> () ==> (), ..... |
2023-07-07 20:02:25 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
2023-07-07 20:02:37 +0200 | <int-e> | > fst $ S'.runState (traverse (\a -> S'.modify (+a) >> get) [1,2,undefined]) 0 |
2023-07-07 20:02:39 +0200 | <lambdabot> | [1,3,*Exception: Prelude.undefined |
2023-07-07 20:02:54 +0200 | <int-e> | > fst $ S'.runState (traverse (\a -> S'.modify' (+a) >> get) [1,2,undefined]) 0 |
2023-07-07 20:02:55 +0200 | <lambdabot> | *Exception: Prelude.undefined |
2023-07-07 20:03:15 +0200 | int-e | is confused |
2023-07-07 20:04:18 +0200 | <int-e> | Oh, wait, the lazy state monad is lazy in the (s,a) pairs produced by the intermediate actions. |
2023-07-07 20:04:19 +0200 | <EvanR> | the last one is most strict |
2023-07-07 20:04:42 +0200 | <EvanR> | yeah |
2023-07-07 20:05:03 +0200 | <EvanR> | that's what I was originally looking at but didn't realize the "default laziness of let" |
2023-07-07 20:05:06 +0200 | <int-e> | (It has been a while since I needed that information.) |
2023-07-07 20:05:35 +0200 | <dminuoso> | jackdk: Yes, and largely undocumented. You have to refer to the original PhD thesis and Edwards repositories to know how to use backpack. |
2023-07-07 20:05:36 +0200 | <int-e> | > runState (undefined >> put 2) 0 |
2023-07-07 20:05:37 +0200 | <lambdabot> | error: |
2023-07-07 20:05:38 +0200 | <lambdabot> | Ambiguous occurrence ‘runState’ |
2023-07-07 20:05:38 +0200 | <lambdabot> | It could refer to |
2023-07-07 20:05:46 +0200 | <int-e> | ah |
2023-07-07 20:05:47 +0200 | <int-e> | @undef |
2023-07-07 20:05:47 +0200 | <lambdabot> | Undefined. |
2023-07-07 20:05:59 +0200 | <int-e> | @let import qualified Control.Monad.State.Strict as S' |
2023-07-07 20:06:00 +0200 | <lambdabot> | Defined. |
2023-07-07 20:06:05 +0200 | <int-e> | > runState (undefined >> put 2) 0 |
2023-07-07 20:06:07 +0200 | <lambdabot> | ((),2) |
2023-07-07 20:06:14 +0200 | <int-e> | > S'.runState (undefined >> S'.put 2) 0 |
2023-07-07 20:06:15 +0200 | <lambdabot> | *Exception: Prelude.undefined |
2023-07-07 20:06:44 +0200 | <EvanR> | I really need to upgrade my visual reasoning of evaluating chains of let (a,b) = ... |
2023-07-07 20:07:38 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 240 seconds) |
2023-07-07 20:07:40 +0200 | <int-e> | are you aware of selector thunks? |
2023-07-07 20:07:46 +0200 | <EvanR> | nope |
2023-07-07 20:09:59 +0200 | <int-e> | (They're obscure. Basically, functions like `fst` and `snd` have a special heap representation. The point is, if you have lots of chained let (a,b) = f (...) where f is lazy (like in the state monad), then `a` becomes, effectively, `fst (f (...))` so you could easily end up with thunks of the shape `fst (fst (...),...)` |
2023-07-07 20:11:00 +0200 | <int-e> | When proceeding with lazy evaluation. That's not good. So the garbage collector has code to recognize that case and evaluate those selectors when their argument is a value (not a thunk). |
2023-07-07 20:11:04 +0200 | acarrico | (~acarrico@dhcp-68-142-49-163.greenmountainaccess.net) (Quit: Leaving.) |
2023-07-07 20:11:27 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
2023-07-07 20:11:39 +0200 | reio | (~reio@86-90-81-176.fixed.kpn.net) |
2023-07-07 20:11:51 +0200 | <int-e> | To do that, it has to know when a function is a selector, so selectors like `fst` have a special closure type in the RTS for that purpose. |
2023-07-07 20:12:13 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6) |
2023-07-07 20:13:04 +0200 | <int-e> | And it's somewhat brittle... inlining and let-floating can turn what would be selectors into more complicate closures that are no longer selectors and then the garbage collector can no longer evaluate them on the spot and that can cause space leaks that are really hard to understand :) |
2023-07-07 20:13:17 +0200 | <int-e> | (this is basically how I learned about selector thunks) |
2023-07-07 20:15:34 +0200 | <EvanR> | so a = fst(some thunk) and b = snd(SAME thunk), but at some point the argument may become a value, and even though no one demanding a, it can be simplified |
2023-07-07 20:15:47 +0200 | <int-e> | yep |
2023-07-07 20:16:14 +0200 | <int-e> | and b too |
2023-07-07 20:16:46 +0200 | <EvanR> | and if that is compounded by recursion like in scanl, the gc can repeatedly come in to stop a from building up |
2023-07-07 20:17:11 +0200 | <EvanR> | then what's an update frame? xD |
2023-07-07 20:17:30 +0200 | acarrico | (~acarrico@dhcp-68-142-49-163.greenmountainaccess.net) |
2023-07-07 20:17:52 +0200 | <int-e> | That's something on the stack, not on the heap, keeping track of where to put return values of closures. |
2023-07-07 20:17:55 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) (Remote host closed the connection) |
2023-07-07 20:18:02 +0200 | <int-e> | I understand those less well than selector thunks. |
2023-07-07 20:18:29 +0200 | <hololeap> | I'm looking for some in-depth info on how to profile a data structure for unwanted laziness |
2023-07-07 20:19:25 +0200 | captnemo | (~captnemo@193.32.127.239) (Quit: WeeChat 3.8) |
2023-07-07 20:20:03 +0200 | <int-e> | But there is an optimization (during GC I think?) that collapses update frames on the stack if there are several for the same thunk (which are, IIRC, easy to detect because they'll always be consecutive update frames). |
2023-07-07 20:20:26 +0200 | <EvanR> | wow the GC is doing a lot |
2023-07-07 20:22:06 +0200 | <EvanR> | why would there be many update frames for the same thunk |
2023-07-07 20:22:18 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) |
2023-07-07 20:23:18 +0200 | <geekosaur> | "accumulator" for a fold? |
2023-07-07 20:24:20 +0200 | notzmv | (~zmv@user/notzmv) |
2023-07-07 20:25:15 +0200 | <EvanR> | well I think my main confusion was coming from the selector thunks anyway, thanks for that |
2023-07-07 20:26:48 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2023-07-07 20:32:44 +0200 | <EvanR> | > let Just () = Nothing in () |
2023-07-07 20:32:46 +0200 | <lambdabot> | () |
2023-07-07 20:33:12 +0200 | <EvanR> | is there a selector thunk which checks the sum type's tag too |
2023-07-07 20:33:25 +0200 | <int-e> | no |
2023-07-07 20:33:46 +0200 | <EvanR> | let Just a = Nothing in something something a something something, now what would a be |
2023-07-07 20:34:33 +0200 | biberu | (~biberu@user/biberu) (Read error: Connection reset by peer) |
2023-07-07 20:35:14 +0200 | <EvanR> | whatever it is, defensively evaluating it would be bad right |
2023-07-07 20:35:19 +0200 | <int-e> | (It's not *overly* useful because it would basically only work when you know which constructor the return value will have... I mean we're talking about functions like `fromJust`. In which case, you can and arguably should refactor the code to not produce the constructor in the first place.) |
2023-07-07 20:35:46 +0200 | <EvanR> | yeah but that code does something |
2023-07-07 20:36:34 +0200 | <int-e> | While the chained selectors-on-tuples is actually common when writing loops-as-recursion |
2023-07-07 20:36:48 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2023-07-07 20:37:35 +0200 | <EvanR> | > let Just a = Nothing in [1,2,a,4,5] |
2023-07-07 20:37:37 +0200 | <lambdabot> | [1,2,*Exception: <interactive>:3:5-20: Non-exhaustive patterns in Just a |
2023-07-07 20:37:50 +0200 | <EvanR> | > fromJust Nothing |
2023-07-07 20:37:52 +0200 | <lambdabot> | *Exception: Maybe.fromJust: Nothing |
2023-07-07 20:38:11 +0200 | <int-e> | it's just an ordinary thunk |
2023-07-07 20:38:18 +0200 | biberu | (~biberu@user/biberu) |
2023-07-07 20:38:24 +0200 | <EvanR> | containing what, a case |
2023-07-07 20:39:05 +0200 | <int-e> | It's more or less `let a = case Nothing of Just a => a in ...` |
2023-07-07 20:39:28 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 240 seconds) |
2023-07-07 20:39:33 +0200 | <EvanR> | groovy |
2023-07-07 20:40:13 +0200 | <EvanR> | so selectors are specifically for data types with 1 constructor |
2023-07-07 20:40:20 +0200 | <int-e> | IIRC the Haskell report actually has desugarings for this stuff (pattern matches, including irrefutable ones). |
2023-07-07 20:40:53 +0200 | <int-e> | "irrefutable" being the report's term for what we call "lazy matching" |
2023-07-07 20:42:44 +0200 | <geekosaur> | EvanR, don't forget field selectors |
2023-07-07 20:43:10 +0200 | <int-e> | EvanR: selector thunks, yes. |
2023-07-07 20:43:24 +0200 | <EvanR> | explicit use of field selectors produces a selector thunk too? |
2023-07-07 20:43:41 +0200 | <int-e> | not if there is more than one data constructor |
2023-07-07 20:43:48 +0200 | <EvanR> | got it |
2023-07-07 20:44:19 +0200 | <int-e> | obviously this is a deep implementation detail of ghc |
2023-07-07 20:44:48 +0200 | <int-e> | (though hugs also did thise kind of thing... and probably everybody else too, at least for pairs) |
2023-07-07 20:48:48 +0200 | k`` | (~user@152.7.255.193) |
2023-07-07 20:49:26 +0200 | <k``> | Is there an easy way to do a reverse dependency search for packages? |
2023-07-07 20:49:55 +0200 | <ncf> | https://packdeps.haskellers.com/reverse |
2023-07-07 20:50:06 +0200 | <k``> | Thanks! |
2023-07-07 20:50:11 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
2023-07-07 20:50:45 +0200 | acidjnk | (~acidjnk@p200300d6e7072f0600a8e9aef9077b5f.dip0.t-ipconnect.de) |
2023-07-07 20:50:51 +0200 | danse-nr3 | (~francesco@151.43.173.33) (Ping timeout: 245 seconds) |
2023-07-07 20:51:17 +0200 | <k``> | Now I just need to figure out how much of the API they depend on... |
2023-07-07 20:54:47 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2023-07-07 20:55:13 +0200 | trev | (~trev@user/trev) (Quit: trev) |
2023-07-07 21:02:03 +0200 | __monty__ | (~toonn@user/toonn) |
2023-07-07 21:05:48 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
2023-07-07 21:06:38 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 240 seconds) |
2023-07-07 21:08:53 +0200 | falafel | (~falafel@2603-7000-a700-8710-770e-b4b3-5186-ab58.res6.spectrum.com) |
2023-07-07 21:10:45 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2023-07-07 21:17:46 +0200 | <EvanR> | > if 4 > 9000; then "over 9000!"; else "" |
2023-07-07 21:17:47 +0200 | <lambdabot> | "" |
2023-07-07 21:17:51 +0200 | <EvanR> | > if 4 > 9000; then "over 9000!"; else ""; |
2023-07-07 21:17:52 +0200 | <lambdabot> | <hint>:1:40: error: parse error on input ‘;’ |
2023-07-07 21:19:48 +0200 | <geekosaur> | you don't actually need those, do you? |
2023-07-07 21:20:02 +0200 | <geekosaur> | > if 4 > 9000 then "over 9000!" else "" |
2023-07-07 21:20:04 +0200 | <lambdabot> | "" |
2023-07-07 21:20:09 +0200 | <geekosaur> | that's what I thought |
2023-07-07 21:20:26 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
2023-07-07 21:20:37 +0200 | <monochrom> | But they are allowed because of DoIfThenElse which is now part of Haskell2010. |
2023-07-07 21:20:38 +0200 | <mauke> | the semicola are optionally allowed in an if-then-else expression to make do-notation slightly less annoying |
2023-07-07 21:20:56 +0200 | <geekosaur> | yeh |
2023-07-07 21:21:25 +0200 | <EvanR> | DoIfThenElse? |
2023-07-07 21:21:29 +0200 | <mauke> | did you know import lists allow trailing commata? |
2023-07-07 21:21:55 +0200 | <monochrom> | In fact, DoIfThenElse is defined to just mean allowing ; so that it is a minimal change to the grammar. :) |
2023-07-07 21:21:56 +0200 | <geekosaur> | EvanR, that alters indentation rules |
2023-07-07 21:22:03 +0200 | <geekosaur> | iirc |
2023-07-07 21:22:16 +0200 | <monochrom> | I have only tried export list trailing commas. |
2023-07-07 21:22:36 +0200 | <monochrom> | Also I will raise the endiar war between "commata" and "commae" >:D |
2023-07-07 21:22:36 +0200 | <geekosaur> | since it's an expression, `then` and `else` should be indented, but iirc `DoAndIfThenElse` relaxes that? |
2023-07-07 21:22:48 +0200 | <monochrom> | raise? rage? wage? |
2023-07-07 21:23:20 +0200 | <geekosaur> | "commoi" |
2023-07-07 21:23:48 +0200 | geekosaur | greekosaur |
2023-07-07 21:23:55 +0200 | <monochrom> | Yes, if you don't indent "then" and "else", then layout processing adds ";". Then DoAndIfThenElse just needs to say ";" is OK. |
2023-07-07 21:24:17 +0200 | <monochrom> | It's an ingenious life hack. |
2023-07-07 21:24:21 +0200 | greekosaur | geekosaur |
2023-07-07 21:25:35 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
2023-07-07 21:26:26 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-176-237.46.114.pool.telefonica.de) (Ping timeout: 250 seconds) |
2023-07-07 21:26:36 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
2023-07-07 21:28:35 +0200 | <EvanR> | wow that is sneaky as hell |
2023-07-07 21:28:53 +0200 | <monochrom> | :) |
2023-07-07 21:29:10 +0200 | <monochrom> | My thought when I first saw it. |
2023-07-07 21:30:02 +0200 | <EvanR> | but no 3rd ; is needed? |
2023-07-07 21:30:06 +0200 | <monochrom> | You don't even need to change the layout rules. |
2023-07-07 21:30:07 +0200 | <EvanR> | (or allowed) |
2023-07-07 21:30:23 +0200 | <monochrom> | You can have the 3rd ; in a do-block. |
2023-07-07 21:30:54 +0200 | <mauke> | you don't want the statement after if-then-else to be swallowed by the else part |
2023-07-07 21:31:00 +0200 | <monochrom> | > do if 4 > 9000; then "over 9000!"; else ""; |
2023-07-07 21:31:01 +0200 | <lambdabot> | "" |
2023-07-07 21:31:20 +0200 | <monochrom> | Your life is complete. :) |
2023-07-07 21:31:32 +0200 | <EvanR> | and this is a haskell2010 thing |
2023-07-07 21:31:36 +0200 | <monochrom> | Yes. |
2023-07-07 21:32:04 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 250 seconds) |
2023-07-07 21:32:07 +0200 | <mauke> | > do if do 4 > do 9000; then do "over 9000!"; else do ""; |
2023-07-07 21:32:09 +0200 | <lambdabot> | "" |
2023-07-07 21:32:25 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
2023-07-07 21:32:39 +0200 | <EvanR> | > do do do do do "batman!" |
2023-07-07 21:32:40 +0200 | <monochrom> | deep dodo |
2023-07-07 21:32:40 +0200 | <lambdabot> | "batman!" |
2023-07-07 21:32:52 +0200 | <mauke> | I don't know if you can fit any extra semicola in there now |
2023-07-07 21:32:58 +0200 | <monochrom> | batmonad |
2023-07-07 21:34:06 +0200 | <monochrom> | > do if do 4 > do 9000;;;;;; then do "over 9000!";;;;; else do "";;;;; |
2023-07-07 21:34:07 +0200 | <lambdabot> | "" |
2023-07-07 21:34:19 +0200 | <monochrom> | Beethoven Virus but semicolons. |
2023-07-07 21:34:25 +0200 | mei | (~mei@user/mei) |
2023-07-07 21:35:31 +0200 | <mauke> | > do;; if do 4;; > do 9000;; then do "over 9000!";; else do;; do "";; |
2023-07-07 21:35:32 +0200 | <lambdabot> | "" |
2023-07-07 21:36:53 +0200 | <hololeap> | so, here you can see the flamegraph output of my command: https://eidetic.codes/hackport.html |
2023-07-07 21:37:20 +0200 | <hololeap> | the actual command is: ./dist-newstyle/build/x86_64-linux/ghc-9.2.8/hackport-0.8.4.0/x/hackport/build/hackport/hackport --bash-completion-index 2 --bash-completion-word hackport --bash-completion-word merge --bash-completion-word Cabal +RTS -I0 -A128M -N -pj -hc -l |
2023-07-07 21:38:46 +0200 | <hololeap> | the main block of relevant code is here: https://github.com/gentoo-haskell/hackport/blob/master/src/Hackport/Completion.hs#L82-L129 |
2023-07-07 21:39:29 +0200 | <hololeap> | it seems like that's an excessive amount of GC.GC and IDLE.IDLE, but I don't really know |
2023-07-07 21:41:31 +0200 | <hololeap> | and when I've asked in here before I either get "I don't know" or crickets, but surely there must be some information out there on how to investigate why there is so much garbage being generated |
2023-07-07 21:45:03 +0200 | <hololeap> | in this case, it is reading a Trie from a binary file and running Trie.lookup on it |
2023-07-07 21:45:19 +0200 | <hololeap> | https://github.com/gentoo-haskell/hackport/blob/master/src/Data/Trie.hs |
2023-07-07 21:53:17 +0200 | <EvanR> | a lot of garbage *generated* seems par for the course |
2023-07-07 21:53:34 +0200 | perrierjouet | (~perrierjo@modemcable048.127-56-74.mc.videotron.ca) |
2023-07-07 21:53:36 +0200 | <EvanR> | if it's not being collected soon then it's potentially a problem |
2023-07-07 21:55:36 +0200 | Pickchea | (~private@user/pickchea) |
2023-07-07 21:57:19 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
2023-07-07 21:57:28 +0200 | <hololeap> | is the GC.GC and IDLE.IDLE at the beginning some sort of unavoidable startup for the runtime? |
2023-07-07 21:59:13 +0200 | jrm | (~jrm@user/jrm) (Quit: ciao) |
2023-07-07 22:00:34 +0200 | jrm | (~jrm@user/jrm) |
2023-07-07 22:01:11 +0200 | <int-e> | hololeap: hmm the idling may be waiting for external commands? |
2023-07-07 22:01:20 +0200 | lainon | (~textual@2601:7c0:cb00:c0a0:718c:10e2:ff4c:a39) |
2023-07-07 22:01:39 +0200 | <int-e> | you could try +RTS -I0 -RTS to disable the idle GC and see if that reduces the proportion of GC time |
2023-07-07 22:02:01 +0200 | <int-e> | ("-I<sec> Perform full GC after <sec> idle time (default: 0.3, 0 == off)") |
2023-07-07 22:02:21 +0200 | <hololeap> | hm, well it already is running with +RTS -I0 |
2023-07-07 22:02:39 +0200 | <int-e> | ah, I missed that. |
2023-07-07 22:03:02 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
2023-07-07 22:04:40 +0200 | <int-e> | hmm, -N, how many cores will that end up using? |
2023-07-07 22:06:31 +0200 | lainon | (~textual@2601:7c0:cb00:c0a0:718c:10e2:ff4c:a39) (Quit: Textual IRC Client: www.textualapp.com) |
2023-07-07 22:06:35 +0200 | <hololeap> | 4 in this case, is that going to be a problem? -N is actually set in ghc-options: ... -with-rtsopts=-N |
2023-07-07 22:07:33 +0200 | <int-e> | Well it might explain the idle thing... expecially if the actuaal work load has only one thread |
2023-07-07 22:07:54 +0200 | <int-e> | So trying with -N1 seems to be a worthwhile experiment at least? |
2023-07-07 22:08:02 +0200 | <hololeap> | yeah, I'll try that |
2023-07-07 22:08:19 +0200 | <int-e> | It shouldn't dramatically affect the GC time though which is your real question |
2023-07-07 22:08:44 +0200 | <int-e> | (I think) |
2023-07-07 22:08:47 +0200 | <EvanR> | whoa https://github.com/sdiehl/write-you-a-haskell (not necessarily in 24 hours) |
2023-07-07 22:10:17 +0200 | <int-e> | Hmm, 2+ years, unfinished? |
2023-07-07 22:10:29 +0200 | <hololeap> | so the whole point of this is to add bash completion to the `hackport merge` command, which takes a package/version that exists in the hackage database. the list of package/versions is cached in a trie which is serialized via binary to a file. on subsequent runs, it should deserialize the cache file and run a lookup on the trie. |
2023-07-07 22:10:59 +0200 | <hololeap> | with bash completion, adding a second or two feels really sluggish, so I was trying to squeeze a bit more speed out of it |
2023-07-07 22:11:31 +0200 | <hololeap> | (just some background) |
2023-07-07 22:11:32 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 240 seconds) |
2023-07-07 22:12:07 +0200 | <int-e> | hmm, a second or two... did you say how big the serialized data is? |
2023-07-07 22:12:25 +0200 | <hololeap> | I think it's around 150,000 entries? |
2023-07-07 22:13:01 +0200 | <hololeap> | but you can see from that flamegraph thing that quite a bit of time is spent at the beginning before it even enters main |
2023-07-07 22:13:33 +0200 | <int-e> | I don't think you see that |
2023-07-07 22:13:51 +0200 | <int-e> | I think you're seeing *total* times spent in various parts of the program |
2023-07-07 22:14:02 +0200 | <hololeap> | oh, ok |
2023-07-07 22:14:08 +0200 | alternateved | (~user@77-254-166-50.dynamic.inetia.pl) |
2023-07-07 22:14:09 +0200 | <int-e> | and GC.GC is first only because it's the biggest chunk |
2023-07-07 22:14:53 +0200 | <hololeap> | I'm also interested in this because the understanding I gain will really help me in the future projects |
2023-07-07 22:16:03 +0200 | <hololeap> | for instance, I was told adding `LANGUAGE Strict` to my Data.Trie is clumsy and may not do what I expect, but I wasn't told what the _proper_ solution there is either |
2023-07-07 22:16:14 +0200 | <int-e> | I guess the generic recipe for reducing GC times without modifying the program is to increase heap size (both -A and -H may be relevant) |
2023-07-07 22:17:18 +0200 | <davean> | hololeap: you can profile allocations. Also including what closures, etc allocates them - have you done such? Also I see comments above about -N, but have you tried disabling parallel GC? |
2023-07-07 22:17:22 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: jdvkjb) |
2023-07-07 22:17:54 +0200 | <hololeap> | davean: I'm not sure how to do any of this |
2023-07-07 22:18:56 +0200 | <hololeap> | I see the -pa runtime argument in the chapter on profiling |
2023-07-07 22:19:01 +0200 | acidjnk | (~acidjnk@p200300d6e7072f0600a8e9aef9077b5f.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
2023-07-07 22:19:03 +0200 | <davean> | add "+RTS -?" to your commend to get options (build with profiling enabled, and RTS options enabled) |
2023-07-07 22:19:17 +0200 | <int-e> | why is the top user of runtime somewhere in hackage-security |
2023-07-07 22:19:21 +0200 | <davean> | ps are about time, you want heap, which is h |
2023-07-07 22:19:33 +0200 | <int-e> | (if the flame graph is to be trusted) |
2023-07-07 22:20:23 +0200 | <davean> | int-e: I would expect that if not much was being done in the program at all. |
2023-07-07 22:20:49 +0200 | <hololeap> | int-e: that's a good question and has to do with the way the program was originally structured |
2023-07-07 22:21:22 +0200 | <int-e> | hololeap: the reason I'm asking is really that I'm wondering whether you're blaming the right thing for taking so much time |
2023-07-07 22:21:54 +0200 | <hololeap> | int-e: I would love to know how to find out |
2023-07-07 22:22:28 +0200 | acidjnk | (~acidjnk@p200300d6e7072f06a5c472a3c7963a83.dip0.t-ipconnect.de) |
2023-07-07 22:22:32 +0200 | <hololeap> | from the profiling data, rather than start chopping parts off until it goes fast |
2023-07-07 22:22:41 +0200 | <int-e> | (and often, time correlates with allocations, and allocations trigger GCs, so it's all related to the high GC activity) |
2023-07-07 22:22:51 +0200 | <int-e> | (well, potentially related) |
2023-07-07 22:23:06 +0200 | <davean> | Is the GC activity high? Its a flame graph so i can't tell |
2023-07-07 22:23:14 +0200 | <davean> | I'd kill for an actual graph |
2023-07-07 22:23:24 +0200 | <hololeap> | davean: I can provide other files, what do you want |
2023-07-07 22:23:25 +0200 | <int-e> | well the graph suggests 40%+ GC time |
2023-07-07 22:23:28 +0200 | <jade[m]> | davean: pls don't |
2023-07-07 22:23:55 +0200 | <davean> | hololeap: I mean the actual profile file would be great, but I'm not going to spend much time on this ATM |
2023-07-07 22:24:28 +0200 | <hololeap> | davean: the .prof in json or what format? |
2023-07-07 22:24:42 +0200 | <davean> | the .prof in standard format |
2023-07-07 22:24:49 +0200 | <int-e> | tbh I'd like to see the percentages from `+RTS -s` just to support or refute the flame graph |
2023-07-07 22:26:00 +0200 | reio | (~reio@86-90-81-176.fixed.kpn.net) (Ping timeout: 246 seconds) |
2023-07-07 22:27:59 +0200 | <davean> | actually I can generate all this myself unless its a quirk of your system - whats the repo, do you have a nix file for it, and what do you want profiled? I might do it between stuff tonight |
2023-07-07 22:28:44 +0200 | <hololeap> | here's the output with +RTS -s: http://sprunge.us/VJ9cxA |
2023-07-07 22:28:52 +0200 | <hololeap> | here's the .prof file: http://sprunge.us/3h8TNy |
2023-07-07 22:29:29 +0200 | <hololeap> | davean, I don't have a nix file, but I'm using master from here: https://github.com/gentoo-haskell/hackport |
2023-07-07 22:29:31 +0200 | <int-e> | so that confirms 40%-50% GC time |
2023-07-07 22:29:42 +0200 | <geekosaur> | if this turns out to be in hackage-security then #hackage will want to hear about it |
2023-07-07 22:30:07 +0200 | <davean> | Its only allocating like 357MiB, how long is this taking? |
2023-07-07 22:31:12 +0200 | <hololeap> | well, +RTS -N1 -qg -RTS seemed to speed it up quite a bit: total time = 1.15 secs |
2023-07-07 22:31:30 +0200 | <int-e> | "227MB copied during GC" is what makes GC expensive |
2023-07-07 22:32:01 +0200 | <davean> | Yah but even that means this is a VERY slow system it is on - how big is the datafile? We can look at how it is parsed. |
2023-07-07 22:32:13 +0200 | <davean> | You don't happen to be using lazy IO by any chance? |
2023-07-07 22:32:47 +0200 | <hololeap> | I'm using encodeFile from Data.Binary |
2023-07-07 22:33:00 +0200 | <hololeap> | encodeFile/decodeFile |
2023-07-07 22:34:56 +0200 | <hololeap> | https://github.com/gentoo-haskell/hackport/blob/master/src/Hackport/Completion.hs#L115-L118 |
2023-07-07 22:35:45 +0200 | <hololeap> | I forgot I put this into a compact region as an experiment, which doesn't seem to affect anything |
2023-07-07 22:37:01 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
2023-07-07 22:37:06 +0200 | <davean> | hololeap: and what is the actual command you're running that should be profiled? |
2023-07-07 22:37:19 +0200 | <hololeap> | it's in the .prof file I just pasted |
2023-07-07 22:37:25 +0200 | <davean> | If it isn't too much of a pain to get build I probably can look at it in a few hours. |
2023-07-07 22:37:51 +0200 | <davean> | Ok, are any of the RTS options important? |
2023-07-07 22:38:02 +0200 | <davean> | You have both -N and -N1 for example |
2023-07-07 22:38:25 +0200 | <EvanR> | haskell report section on the context-free grammar doesn't mention whitespace at all. Is the idea that whitespace is dropped in the process of doing the layout algorithm |
2023-07-07 22:38:27 +0200 | <hololeap> | -N is added in the cabal file via --with-rtsopts |
2023-07-07 22:38:41 +0200 | <hololeap> | it was suggested that I turn it off for this |
2023-07-07 22:39:13 +0200 | <hololeap> | I think that optparse-applicative is adding the -I0 -A128M |
2023-07-07 22:39:19 +0200 | <geekosaur> | EvanR, it's typically removed during lexing, as it's either layout or a way to separate tokens |
2023-07-07 22:39:20 +0200 | <mauke> | whitespace is the lexer's problem |
2023-07-07 22:39:34 +0200 | <darkling> | Depends on your lexer rules. :) |
2023-07-07 22:39:39 +0200 | <mauke> | which is why most grammars are useless for finding polyglots |
2023-07-07 22:39:45 +0200 | <EvanR> | ok but the layout algorithm requires knowing all about whitespace to do its thing |
2023-07-07 22:39:55 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) |
2023-07-07 22:40:09 +0200 | <mauke> | I don't think layout cares about whitespace, really |
2023-07-07 22:40:15 +0200 | <mauke> | just columns |
2023-07-07 22:40:23 +0200 | <geekosaur> | right, but you'll note the layout algorithm is in terms of inserting special tokens, which means it happens during lexing for the most part |
2023-07-07 22:40:28 +0200 | fgaz_ | (1ff9197ed6@2604:bf00:561:2000::11ea) |
2023-07-07 22:40:51 +0200 | <EvanR> | alright |
2023-07-07 22:40:52 +0200 | <geekosaur> | remember the {n} asnd <n> tokens? |
2023-07-07 22:41:01 +0200 | <int-e> | hololeap: Hmm, "trieFile >>= decodeFile >>= compact" ... GHC.Compact.compact is not going to pay off for you I think. |
2023-07-07 22:41:24 +0200 | <hololeap> | int-e: yeah I found that out, but apparently left it in the commit |
2023-07-07 22:41:24 +0200 | <EvanR> | yeah, it says they exist. I guess whitespace turned into {n} and <n> tokens prior to layout |
2023-07-07 22:41:32 +0200 | <geekosaur> | yep |
2023-07-07 22:42:51 +0200 | <EvanR> | though you might want to attach line and column numbers to tokens for reasons? |
2023-07-07 22:43:07 +0200 | <dolio> | EvanR: BTW, you might be interested in the references here: https://github.com/haskell/happy/issues/235 |
2023-07-07 22:43:10 +0200 | <geekosaur> | yes, and ghc for example does that |
2023-07-07 22:43:27 +0200 | <int-e> | hololeap: I'm still confused though... shouldn't the whole cabal-install/hackage-security code path be skipped if the cache exists? |
2023-07-07 22:44:58 +0200 | <hololeap> | int-e: yes it should, I haven't gotten to that yet. I was really just trying to understand the GC usage |
2023-07-07 22:45:27 +0200 | <int-e> | hololeap: so, tentatively, I suspect `choice` may not be as lazy as you expect |
2023-07-07 22:51:02 +0200 | <int-e> | > runWriter $ runMaybeT $ asum [lift (tell [1]) >> pure "Ok", lift (tell [2]) >> fail "Nope"] |
2023-07-07 22:51:03 +0200 | <lambdabot> | (Just "Ok",[1]) |
2023-07-07 22:51:15 +0200 | <int-e> | This... suggests that it's lazy enough. |
2023-07-07 22:51:39 +0200 | <int-e> | (`choice` is defined as `asum`) |
2023-07-07 22:52:15 +0200 | nick4 | (~nick@2600:8807:9084:7800:dc97:418d:c7fc:117f) (Ping timeout: 246 seconds) |
2023-07-07 22:52:40 +0200 | gry | (quasselcor@botters/gry) (Ping timeout: 250 seconds) |
2023-07-07 22:53:16 +0200 | <EvanR> | the final section of that chapter on syntax is about disambiguating infix expressions by using fixity and precedence. It is explained in terms of a "list of tokens" which are either infixexps from the grammar (which includes operators already), operators, and negative signs |
2023-07-07 22:53:17 +0200 | <dolio> | > runWriter . runMaybeT $ fail "Nope" |
2023-07-07 22:53:18 +0200 | <lambdabot> | (Nothing,()) |
2023-07-07 22:53:31 +0200 | <int-e> | hmmmm. what does `optional` do here |
2023-07-07 22:53:41 +0200 | <EvanR> | is the idea to use first get a parse tree however you can, then flatten infixexps into a list, and rearrange them? |
2023-07-07 22:54:42 +0200 | <dolio> | EvanR: I think so. As I recall, fixity is handled as a post-pass, not during parsing. |
2023-07-07 22:55:02 +0200 | <dolio> | Because you have to parse to find fixity declarations. |
2023-07-07 22:55:13 +0200 | <EvanR> | interesting |
2023-07-07 22:56:32 +0200 | <EvanR> | that adds another level to the common expectation for recursive modules to "just work" |
2023-07-07 22:57:00 +0200 | <EvanR> | operators defined in module A used in module B which uses operators defined in module A |
2023-07-07 22:57:22 +0200 | <int-e> | hololeap: maybe `decodeFile` fails? You'd never seen an error from that because `optional` suppresses it |
2023-07-07 22:57:40 +0200 | <hololeap> | that's intentional |
2023-07-07 22:58:06 +0200 | <int-e> | But it would cause you to go down the slow path. |
2023-07-07 22:58:28 +0200 | <hololeap> | well, the slow path is like 20 seconds, so it's pretty noticable :3 |
2023-07-07 22:58:31 +0200 | <int-e> | So in the interest of debugging, a message would be helpful there. |
2023-07-07 22:58:35 +0200 | <hololeap> | fair |
2023-07-07 22:59:34 +0200 | <hololeap> | also, outputting to stderr on tab completion can be pretty annoying |
2023-07-07 23:00:12 +0200 | <hololeap> | but in the interest of debugging, that's fine, or outputting somewhere in /tmp |
2023-07-07 23:00:20 +0200 | <int-e> | that's fair... |
2023-07-07 23:00:51 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
2023-07-07 23:01:13 +0200 | kimiamania6 | (~681cf57f@user/kimiamania) (Quit: PegeLinux) |
2023-07-07 23:01:17 +0200 | infinity0 | (~infinity0@pwned.gg) (Remote host closed the connection) |
2023-07-07 23:01:24 +0200 | <int-e> | I just still don't understand why cabal-install/hackage-security show up in the flame graph here, if you're just reading that trie and then traversing it |
2023-07-07 23:01:45 +0200 | kimiamania6 | (~681cf57f@user/kimiamania) |
2023-07-07 23:02:58 +0200 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 260 seconds) |
2023-07-07 23:03:11 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-176-237.46.114.pool.telefonica.de) |
2023-07-07 23:03:24 +0200 | infinity0 | (~infinity0@pwned.gg) |
2023-07-07 23:05:45 +0200 | <hololeap> | int-e, I refactored and there's no more hackage-security when it reads from the cache: https://eidetic.codes/hackport.html |
2023-07-07 23:06:15 +0200 | <int-e> | No more IDLE.IDLE either? |
2023-07-07 23:06:34 +0200 | <hololeap> | yeah I guess not... |
2023-07-07 23:08:16 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
2023-07-07 23:09:00 +0200 | <int-e> | Of course the fact that it attributes anything to mkCompleter is dubious (it's a plain newtype data constructor) |
2023-07-07 23:09:03 +0200 | drdo6 | (~drdo@bl5-28-156.dsl.telepac.pt) |
2023-07-07 23:11:23 +0200 | drdo | (~drdo@bl8-153-185.dsl.telepac.pt) (Ping timeout: 264 seconds) |
2023-07-07 23:11:23 +0200 | drdo6 | drdo |
2023-07-07 23:11:44 +0200 | pavonia | (~user@user/siracusa) |
2023-07-07 23:11:51 +0200 | k`` | (~user@152.7.255.193) (Ping timeout: 246 seconds) |
2023-07-07 23:13:46 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 245 seconds) |
2023-07-07 23:14:18 +0200 | merijn | (~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2023-07-07 23:16:35 +0200 | <int-e> | hololeap: That said I'm prepared to believe that the deserialization is just that slow. A standalone program that just replicates the Trie data type and does the trieFile >>= decodeFile part could confirm. |
2023-07-07 23:18:44 +0200 | <int-e> | Ah, with some care to force the result. |
2023-07-07 23:20:15 +0200 | <int-e> | which, I guess, `compact` would do for you |
2023-07-07 23:22:14 +0200 | <hololeap> | yeah, that sounds like a good idea, and with it isolated I could probably ask a better question in the haskell discourse or reddit |
2023-07-07 23:22:50 +0200 | <hololeap> | in any case, just the suggestions I've received today sped it up quite a bit, so thanks everyone |
2023-07-07 23:23:04 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
2023-07-07 23:24:31 +0200 | <EvanR> | haskell reddit? |
2023-07-07 23:25:48 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2023-07-07 23:25:52 +0200 | <EvanR> | yep there it is |
2023-07-07 23:26:10 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
2023-07-07 23:26:11 +0200 | <int-e> | is there a haskell lemmy too? |
2023-07-07 23:26:43 +0200 | <EvanR> | so the moderators quit |
2023-07-07 23:32:58 +0200 | <Hecate> | int-e: kbin.social/m/haskell |
2023-07-07 23:33:36 +0200 | <EvanR> | the minus sign, which means subtraction or negation (or comments) depending on who knows what, including whitespace. Seems like a lexical thing but random stackoverflow says it's more convenient to do in the parser, what a mess |
2023-07-07 23:34:01 +0200 | <int-e> | Hecate: ah that looks a bit more lively than https://programming.dev/c/haskell (unavoidably there are several, hmm, let's call it seeds) |
2023-07-07 23:35:05 +0200 | <EvanR> | it's cool that LexicalNegation did something... like make sections always work the way you think. But it's not in the haskell report here |
2023-07-07 23:37:11 +0200 | <monochrom> | If you write "- 5" with spaces between - and 5, it is pretty difficult for lexers, easier for lexer to just output [Minus, Num 5] and let the CFG stage deal with it. |
2023-07-07 23:43:01 +0200 | m21it | (~m21it@2800:ac:8012:135a:9aa8:aa:24dc:5f7a) |
2023-07-07 23:43:13 +0200 | <EvanR> | right, if I'm in the chinese room and see Minus then 5, then I could output negative 5. But if I see x then Minus then y, then x subtract y? Or x(negative y) |
2023-07-07 23:43:46 +0200 | <EvanR> | how did haskell's ancestors do it |
2023-07-07 23:44:48 +0200 | <EvanR> | who the heck came up with this notation |
2023-07-07 23:45:21 +0200 | <dolio> | Distinguishing subtraction from negation isn't usually lexing. |
2023-07-07 23:45:23 +0200 | cyphase | (~cyphase@user/cyphase) |
2023-07-07 23:45:36 +0200 | caryhartline | (~caryhartl@168.182.58.169) |
2023-07-07 23:46:09 +0200 | <EvanR> | it seems to depend on whitespace |
2023-07-07 23:46:37 +0200 | <m21it> | Hello! Does anyone have an idea why 2 expressions here are giving the different results? I was sure they should be equivalent for the case where key is missing, and both should insert the value 321 with the key "WORLD" https://paste.tomsmeding.com/zVIswWjv |
2023-07-07 23:49:17 +0200 | <dolio> | It is with LexicalNegation on, but I think it isn't in the report. |
2023-07-07 23:49:18 +0200 | EvanR | (~EvanR@user/evanr) (Remote host closed the connection) |
2023-07-07 23:50:23 +0200 | EvanR | (~EvanR@user/evanr) |
2023-07-07 23:53:53 +0200 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |
2023-07-07 23:53:58 +0200 | ryantrinkle | (~ryantrink@89.247.249.243) |
2023-07-07 23:57:13 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.1) |