Logs on 2025-09-11 (liberachat/#haskell)
| 00:01:06 | → | mikess joins (~sam@user/mikess) |
| 00:02:14 | × | acidjnk quits (~acidjnk@p200300d6e717192649d3cadc2eaa05e5.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 00:03:19 | → | itaipu joins (~itaipu@168.121.97.28) |
| 00:04:57 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 00:05:04 | → | Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915) |
| 00:08:59 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 00:10:39 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
| 00:14:05 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 00:15:16 | × | Lycurgus quits (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 00:21:10 | × | otto_s quits (~user@p5b0442fa.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 00:22:49 | → | otto_s joins (~user@p5de2f433.dip0.t-ipconnect.de) |
| 00:24:18 | → | robobub joins (uid248673@id-248673.uxbridge.irccloud.com) |
| 00:24:46 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 00:31:29 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 00:31:42 | → | mange joins (~mange@user/mange) |
| 00:35:25 | → | karenw_ joins (~karenw@user/karenw) |
| 00:36:19 | Axma39609 | is now known as Axman6 |
| 00:37:43 | × | karenw quits (~karenw@user/karenw) (Ping timeout: 265 seconds) |
| 00:38:54 | → | szkl joins (uid110435@id-110435.uxbridge.irccloud.com) |
| 00:40:37 | × | xff0x quits (~xff0x@2405:6580:b080:900:c68c:683e:9c65:6f0a) (Ping timeout: 265 seconds) |
| 00:41:27 | × | mikess quits (~sam@user/mikess) (Ping timeout: 258 seconds) |
| 00:46:03 | → | jmcantrell_ joins (~weechat@user/jmcantrell) |
| 00:57:07 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 00:58:17 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Remote host closed the connection) |
| 01:13:01 | × | jmcantrell_ quits (~weechat@user/jmcantrell) (Quit: WeeChat 4.7.1) |
| 01:18:38 | × | vetkat quits (~vetkat@user/vetkat) (Ping timeout: 258 seconds) |
| 01:19:22 | → | vetkat joins (~vetkat@user/vetkat) |
| 01:22:25 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 01:34:15 | → | EvanR joins (~EvanR@user/evanr) |
| 01:40:22 | → | xff0x joins (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 01:42:03 | <L29Ah> | https://bpa.st/RAGA how can this sad state of affairs be helped, except perhaps putting every record type in its own module? |
| 01:56:09 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 01:59:27 | × | karenw_ quits (~karenw@user/karenw) (Quit: Deep into that darkness peering...) |
| 02:00:54 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 02:02:38 | <pavonia> | Wasn't there an extension for that purpose? |
| 02:03:00 | <jackdk> | Try enabling `{-# LANGUAGE DisambiguateRecordFields #-}` |
| 02:03:26 | <pavonia> | Yeah https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/disambiguate_record_fields.html |
| 02:07:21 | <L29Ah> | jackdk: i did |
| 02:07:33 | <L29Ah> | this is the result |
| 02:07:45 | <jackdk> | It might be `DuplicateRecordFields` that you need |
| 02:07:49 | <L29Ah> | jackdk: i did |
| 02:08:28 | <pavonia> | The ambiguity cannot be resolved in all cases, adding type annotations should help in those cases |
| 02:08:31 | <L29Ah> | apparently it can't do anything when it doesn't see the constructor right at the record mutation |
| 02:08:31 | <jackdk> | Then, respectfully, why did you not open with this information? |
| 02:08:40 | <L29Ah> | i added the type annotation as you can see |
| 02:08:59 | <Leary> | I don't believe there's any extension that allows this out-of-the-box. Technically, I think you can do it with OverloadedRecordUpdate and some boilerplate, but I wouldn't say it's better than the alternative. |
| 02:09:02 | <L29Ah> | jackdk: because i thought it is obvious |
| 02:09:41 | <L29Ah> | Leary: the current boilerplate is crazy and seems like it will go on like that for a while -- https://gitlab.haskell.org/ghc/ghc/-/issues/16232 |
| 02:09:58 | <jackdk> | I just noticed the record update is applied to the `def` and then you do the type application. You may have luck with `def @LlamaRequest` because then GHC may figure out the type of the record being updated |
| 02:10:41 | <glguy> | that isn't enough (I tried earlier) |
| 02:11:31 | <glguy> | in the case the work around is to use the named default value for that type and avoid def |
| 02:11:56 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 02:13:17 | <L29Ah> | glguy: named default value doesn't seem to change anything |
| 02:13:34 | <L29Ah> | deff :: LlamaRequest |
| 02:13:34 | <L29Ah> | defined at the top level, that is |
| 02:14:03 | <glguy> | Oh, I forgot which issue you were running into. sorry. your original separate module solution seems best if you have to use duplicate record fields |
| 02:15:19 | <L29Ah> | i don't strictly have to but aeson's generics work the best without mangling the field names |
| 02:16:46 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 02:17:25 | <jackdk> | L29Ah: GHC 9.8.4 accepts this code but warns that type-directed record updates will be eventually deprecated and removed. The key difference is using a type annotation on `def` instead of a type application (either before or after the record update) https://www.irccloud.com/pastebin/kc8TPwKu/Encode.hs |
| 02:18:41 | <L29Ah> | jackdk: it is already removed in 9.12 IIRC |
| 02:18:49 | <glguy> | that file loads in 9.12 |
| 02:19:22 | <L29Ah> | nvm thanks |
| 02:19:31 | <glguy> | but it doesn't seem great to rely on it sticking around in any case |
| 02:20:41 | <L29Ah> | i have a gut feeling that it won't be purged before 16232 gets in |
| 02:22:22 | <L29Ah> | https://gitlab.haskell.org/ghc/ghc/-/issues/25075#note_576241 |
| 02:23:55 | <L29Ah> | https://github.com/ghc-proposals/ghc-proposals/pull/366 me pushe dislike so very hard!! |
| 02:23:59 | <jackdk> | https://github.com/ghc-proposals/ghc-proposals/pull/537#issuecomment-1327646670 there is an open proposal around having some form of type-signature-directed record updates stick around |
| 02:26:00 | <jackdk> | Remark: I generally recommend against using `class Default` because it's got no laws, and so it's very difficult to write a function that usefully generalises over `Default` instances, which to me is one of the two main points of having a typeclass (the other being to have GHC build a function in a type-directed manner, which also doesn't apply here). |
| 02:26:54 | <jackdk> | I tend to use generic-lens or generic-optics to do record updates unless I'm building a library where I need to not blow out the dependency footprint, which can look pretty nice with OverloadedLabels |
| 02:27:43 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 02:32:45 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 02:33:52 | <geekosaur> | Default can also bite you with unexpected types having Default instances |
| 02:34:06 | <geekosaur> | xmonad has already had a bug caused by it |
| 02:36:37 | <L29Ah> | could be argued about Monoid/mempty likewise |
| 02:37:11 | <L29Ah> | i try not to forget toplevel function signatures and decomposition to help with that |
| 02:38:57 | <jackdk> | Hard disagree re: Monoid because `mempty` has sensible behavior because of the laws that describe its interactions with `(<>)` |
| 02:39:15 | <geekosaur> | ^ |
| 02:39:38 | <geekosaur> | Default just does whatever whoever added the instance wanted… but defaults depend on context |
| 02:40:06 | <geekosaur> | like, arguments could be made that the Default instance for Int should be 1 (think the addition vs. multiplication divide) |
| 02:40:28 | <monochrom> | I just cite the PHP example. Call it a strawman or anecdotal or whatever. There is a time type in PHP, then someone decreed that it has a default value and it is 0. Fortunately, someone else has the sanity to point out what's wrong with it. |
| 02:40:34 | <L29Ah> | oh Int has Default, great |
| 02:41:06 | <jackdk> | https://hackage.haskell.org/package/acme-default has much better instances |
| 02:41:11 | <geekosaur> | (->) e has a default |
| 02:41:20 | <geekosaur> | (which is what bit us) |
| 02:41:43 | <geekosaur> | _lots_ of things have defaults. are they useful in all cases? not a chance |
| 02:43:02 | <monochrom> | I am OK with Default as long as you don't inflict your personalized idea of "default Int" on me. |
| 02:43:27 | <monochrom> | But then that's just another way to say that I accept Monoid not Default. |
| 02:43:30 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 02:44:00 | <monochrom> | (Int, (+)) has a default. (Int, (*)) has a default. There are others. Int alone has no default. |
| 02:44:01 | <geekosaur> | there's no way to not inflict a personalized idea if it's a typeclass |
| 02:44:51 | <geekosaur> | the typeclass police should arrest Default |
| 02:45:28 | <mauke> | (->) e had a default |
| 02:46:26 | <monochrom> | Actually, isn't (->)e the wrong kind for Default? |
| 02:46:53 | <mauke> | implied (Default a) => Default ((->) e a) |
| 02:47:00 | <monochrom> | Oh, that. |
| 02:47:03 | <dibblego> | every time I look at Default, it is worse than my imagination approximates, but I assume it is ((->) e e) |
| 02:47:09 | <dibblego> | oh |
| 02:47:39 | <monochrom> | Hey at least it's palatable to math "pointwise extension" :) |
| 02:48:00 | <geekosaur> | hint: const |
| 02:48:00 | <dibblego> | :) |
| 02:48:27 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 02:48:27 | <jackdk> | monochrom: I think "(Int, (+)) has a default" muddies the waters. I would say "(Int, (+)) has an identity element" or "... a neutral element" |
| 02:48:57 | × | haritz quits (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 02:49:01 | <mauke> | because what I really wanted was (Default a, Applicative f) => Default (f a), but that's not legal |
| 02:49:08 | <geekosaur> | I took the point as "that's a better notion of "default" than Default is |
| 02:49:10 | <geekosaur> | " |
| 02:49:11 | <monochrom> | I want to muddle the water so much it wraps around and clarifies to "why not do it properly and make a Monoid". |
| 02:49:27 | <jackdk> | OK |
| 02:50:24 | <monochrom> | Alternatively or equivalently I want to hijack the "plain English" word "default" and re-define it to be monoid identity. |
| 02:51:40 | <mauke> | anyway, the controversial (e -> a) and (IO a) instances have been removed |
| 02:51:52 | <mauke> | and the controversial Bool instance added |
| 02:52:00 | <dibblego> | alternatively, s/Default/Hyperfault |
| 02:52:17 | <geekosaur> | how about just "Fault" |
| 02:52:53 | <monochrom> | I thought people knew better than a default Bool. |
| 02:53:08 | <monochrom> | You have like 50% chance of being wrong. |
| 02:53:13 | <mauke> | I do, but it was a user request |
| 02:53:44 | <monochrom> | But OK, there is a selection bias. The Default library is doomed to attract a certain kind of people... |
| 02:54:01 | <mauke> | by Neil Mitchell, possibly? |
| 02:59:17 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 03:05:53 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 03:10:38 | → | LainIwakura joins (~LainIwaku@user/LainIwakura) |
| 03:17:07 | → | aforemny_ joins (~aforemny@i59F4C711.versanet.de) |
| 03:17:20 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 03:17:24 | × | aforemny quits (~aforemny@i59F4C7D6.versanet.de) (Ping timeout: 256 seconds) |
| 03:22:03 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 03:33:06 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 03:38:22 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 03:48:11 | Googulator61 | is now known as Googulator |
| 03:48:53 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 03:49:30 | <probie> | monochrom: the default Bool should be `False`. I flipped a coin and that was the result (also, just having false and implication gives us everything in classical logic, so maybe it is a slightly better choice than true) |
| 03:52:26 | → | Square2 joins (~Square@user/square) |
| 03:52:30 | <L29Ah> | i did an anonymous mmap and that was the result of unsafeCoerce |
| 03:53:40 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 03:56:34 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds) |
| 04:04:46 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 04:10:52 | → | Unicorn_Princess joins (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 04:11:29 | <monochrom> | probie: That is just not true. (pun! don't take it seriously >:) ) |
| 04:12:03 | → | hjj123 joins (~hjj123@178.155.115.231) |
| 04:13:03 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 04:23:40 | × | hjj123 quits (~hjj123@178.155.115.231) (Quit: Client closed) |
| 04:24:20 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 04:26:14 | × | trickard quits (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 04:26:27 | → | trickard_ joins (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 04:29:43 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 04:30:42 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 04:33:45 | × | simplystuart quits (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 258 seconds) |
| 04:34:59 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
| 04:39:27 | × | trickard_ quits (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 04:39:40 | → | trickard_ joins (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 04:40:11 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 04:42:26 | → | takuan joins (~takuan@d8D86B9E9.access.telenet.be) |
| 04:45:39 | → | michalz joins (~michalz@185.246.207.201) |
| 04:46:56 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 04:58:12 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 05:03:34 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 05:11:43 | × | mulk quits (~mulk@p5b2dc694.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 05:13:06 | → | mulk joins (~mulk@pd95144c3.dip0.t-ipconnect.de) |
| 05:14:01 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 05:14:05 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 05:18:36 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds) |
| 05:18:59 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 05:19:08 | → | karenw_ joins (~karenw@user/karenw) |
| 05:21:09 | × | trickard_ quits (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 05:21:23 | → | trickard_ joins (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 05:29:54 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 05:34:42 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 05:37:28 | × | Pixi quits (~Pixi@user/pixi) (Ping timeout: 248 seconds) |
| 05:45:33 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 05:46:43 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 05:47:24 | → | Sgeo_ joins (~Sgeo@user/sgeo) |
| 05:50:24 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 05:50:25 | × | Sgeo quits (~Sgeo@user/sgeo) (Ping timeout: 258 seconds) |
| 05:51:13 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
| 05:56:43 | → | Pixi joins (~Pixi@user/pixi) |
| 05:57:44 | × | kaskal quits (~kaskal@84-115-230-9.cable.dynamic.surfer.at) (Ping timeout: 248 seconds) |
| 05:58:11 | → | kaskal joins (~kaskal@2a02:8388:15bf:c200:3edd:e10d:d41e:f619) |
| 06:01:16 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 06:02:59 | × | chexum quits (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 272 seconds) |
| 06:03:17 | → | chexum joins (~quassel@gateway/tor-sasl/chexum) |
| 06:06:12 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 06:07:24 | × | Square2 quits (~Square@user/square) (Ping timeout: 256 seconds) |
| 06:09:32 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 06:10:45 | × | m1dnight_ quits (~m1dnight@109.236.62.133) (Read error: Connection reset by peer) |
| 06:11:52 | × | trickard_ quits (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 06:12:06 | → | trickard_ joins (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 06:14:16 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 06:16:35 | → | m1dnight_ joins (~m1dnight@109.236.62.134) |
| 06:23:46 | × | trickard_ quits (~trickard@cpe-54-98-47-163.wireline.com.au) (Ping timeout: 255 seconds) |
| 06:23:52 | × | ridcully quits (~ridcully@p508ac996.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 06:24:05 | → | trickard_ joins (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 06:25:41 | → | Guest59 joins (~Guest59@205.254.174.179) |
| 06:29:18 | × | jcarpenter2 quits (~lol@96.78.87.197) (Ping timeout: 260 seconds) |
| 06:32:36 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 06:36:54 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 06:42:47 | → | posixlycorrect joins (~posixlyco@user/posixlycorrect) |
| 06:43:19 | × | hiredman quits (~hiredman@frontier1.downey.family) (Ping timeout: 258 seconds) |
| 06:45:14 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Ping timeout: 258 seconds) |
| 06:45:30 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 06:45:41 | → | hiredman joins (~hiredman@frontier1.downey.family) |
| 06:45:52 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 06:46:15 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 06:49:45 | → | jcarpenter2 joins (~lol@2603:3016:1e01:b980:50d7:d756:5d4d:269d) |
| 06:50:53 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 06:51:13 | × | Guest59 quits (~Guest59@205.254.174.179) (Quit: Client closed) |
| 06:51:39 | <kqr> | tomsmeding, you know, I might be able to un-duplicate a few of the duplicate cards by adding spurious information that doesn't affect the game. however, it's still going to be over 100 cards, so 64 bits are not enough. |
| 06:53:00 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Ping timeout: 256 seconds) |
| 06:53:42 | × | ft quits (~ft@p4fc2a25a.dip0.t-ipconnect.de) (Quit: leaving) |
| 06:54:03 | <kqr> | tomsmeding, I'm thinking of two possible avenues forward, both representing a card with a Word8. either keeping the possibility of duplicates and storing hands as short bytestrings... or setting some extra bits, making the conditionals more complicated, and trying to store them in an intset |
| 06:54:31 | → | peterbecich joins (~Thunderbi@syn-172-222-149-049.res.spectrum.com) |
| 06:58:45 | → | tromp joins (~textual@2001:1c00:3487:1b00:4ca2:8197:56e4:708) |
| 06:59:57 | × | karenw_ quits (~karenw@user/karenw) (Quit: Deep into that darkness peering...) |
| 07:00:03 | × | caconym747 quits (~caconym@user/caconym) (Quit: bye) |
| 07:00:44 | → | caconym747 joins (~caconym@user/caconym) |
| 07:02:24 | → | sord937 joins (~sord937@gateway/tor-sasl/sord937) |
| 07:03:24 | → | merijn joins (~merijn@77.242.116.146) |
| 07:07:55 | <probie> | kqr: What is the maximum number of cards in a hand, the maximum number of distinct cards and that maximum number of duplicates? |
| 07:08:05 | <probie> | s/that maximum/the maximum/ |
| 07:27:22 | → | ubert joins (~Thunderbi@178.165.191.145.wireless.dyn.drei.com) |
| 07:28:56 | → | acidjnk joins (~acidjnk@p200300d6e7171926a81168b3bd2506b7.dip0.t-ipconnect.de) |
| 07:32:53 | × | robobub quits (uid248673@id-248673.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 07:33:15 | → | mari-estel joins (~mari-este@user/mari-estel) |
| 07:38:34 | → | gmg joins (~user@user/gehmehgeh) |
| 07:42:48 | <kqr> | probie, maximum number of cards in a hand is theoretically just over 50, but that rarely happens in practice. just over half of them can be duplicates (almost all cards exist in pairs, some in quadruples). but all 50 in a hand could also be distinct. |
| 07:43:11 | → | chele joins (~chele@user/chele) |
| 07:44:06 | × | emmanuelux quits (~emmanuelu@user/emmanuelux) (Read error: Connection reset by peer) |
| 07:45:14 | → | m1dnight joins (~m1dnight@d8D861A17.access.telenet.be) |
| 07:47:09 | <probie> | So unique cards held in hand is storable in a Word64. |
| 07:48:49 | × | m1dnight_ quits (~m1dnight@109.236.62.134) (Ping timeout: 255 seconds) |
| 07:49:52 | × | tzh quits (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 07:51:16 | <probie> | If we assume 52 distinct cards with maximally 4 copies of each, there is a pretty naive representation that fits into 4 `Word64`s |
| 07:52:35 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
| 07:53:22 | <tomsmeding> | at that point you're 4*8 = 32 bytes in though, and it's not fully clear whether that's better than a ShortByteString of length ~15 (one byte per card in hand) |
| 07:53:41 | <kqr> | I agree |
| 07:53:49 | <tomsmeding> | (be sure to use ShortByteString, not ByteString, because the latter is pinned and that is complete overkill in this situation) |
| 07:55:11 | × | peterbecich quits (~Thunderbi@syn-172-222-149-049.res.spectrum.com) (Ping timeout: 250 seconds) |
| 07:55:46 | <tomsmeding> | also the 4-Word64 representation is not naturally canonical; if you remove a card from the hand, either you now have to deal with duplicates living in unpredictable Word64s, or you have to explicitly normalise the bits to the left-most Word64s or something |
| 07:55:52 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 07:56:11 | <tomsmeding> | the solution is clearly to just model a different game where duplicates are not a thing and use a single Word64 |
| 07:56:32 | → | lortabac joins (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 07:59:10 | → | CiaoSen joins (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) |
| 08:00:29 | <dminuoso> | Oh my. I found something that Python genuinely got right compared to Haskell: They have 1-tuples. |
| 08:00:47 | <dminuoso> | Very happy about it, too. |
| 08:01:11 | <dminuoso> | (Except the moments you accidentally create them, they they are annoying due to lack of a functional type system, but hey you cant have everything) |
| 08:02:36 | <probie> | doesn't `Solo` exist? |
| 08:06:14 | <tomsmeding> | dminuoso: a friend of mine has somehow accidentally ended up with a comma at the end of a line multiple times |
| 08:06:29 | <tomsmeding> | the resulting bugs were interesting |
| 08:07:04 | <tomsmeding> | also, what do you use 1-tuples for? |
| 08:07:19 | <[exa]> | tuplic consistency!!1 |
| 08:07:55 | → | merijn joins (~merijn@77.242.116.146) |
| 08:08:17 | <[exa]> | the only good use I found for tuples was with DB-ish and CSV-ish frontends, there it nicely says that the thing is a row not just a piece of data |
| 08:08:24 | <[exa]> | *1-tuples |
| 08:08:46 | <tomsmeding> | right |
| 08:08:59 | <tomsmeding> | % import qualified Language.Haskell.TH as TH |
| 08:08:59 | <yahb2> | <no output> |
| 08:09:04 | <tomsmeding> | % :seti -XTemplateHaskell |
| 08:09:04 | <yahb2> | <no output> |
| 08:09:05 | <[exa]> | also I recall it was called Only instd of Solo, kinda wondering what's the difference there |
| 08:09:16 | <tomsmeding> | % $(pure $ TH.TupE [Just (TH.LitE (TH.IntegerL 42))]) |
| 08:09:16 | <yahb2> | MkSolo 42 |
| 08:09:17 | → | tremon joins (~tremon@83.80.159.219) |
| 08:09:17 | × | lbseale quits (~quassel@user/ep1ctetus) (Ping timeout: 260 seconds) |
| 08:09:23 | <tomsmeding> | [exa]: Only was a library |
| 08:09:25 | <tomsmeding> | @hackage only |
| 08:09:25 | <lambdabot> | https://hackage.haskell.org/package/only |
| 08:09:29 | <tomsmeding> | oh |
| 08:09:39 | <tomsmeding> | bastards |
| 08:09:41 | <tomsmeding> | @hackage Only |
| 08:09:41 | <lambdabot> | https://hackage.haskell.org/package/Only |
| 08:10:09 | <[exa]> | O_o |
| 08:10:29 | <[exa]> | ^ lexical form of wtfface very relevant in this situation |
| 08:10:47 | <tomsmeding> | :D |
| 08:12:14 | <[exa]> | interestingly all Only definitions in the packages are newtypes but Solo from base is `data` |
| 08:13:41 | <[exa]> | which kinda makes sense for more consistency with tuples I guess, the actual workalike of the newtypish Only in base would rather be `Identity` then |
| 08:13:46 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 08:13:52 | <tomsmeding> | [exa]: this one isn't https://hackage.haskell.org/package/OneTuple-0.4.1.1/docs/Data-Tuple-Solo.html |
| 08:14:03 | <tomsmeding> | I had this one in mind actually but forgot that it wasn't called Only |
| 08:15:17 | → | merijn joins (~merijn@77.242.116.146) |
| 08:15:22 | <[exa]> | that looks kinda isomorphic to the one from base actually |
| 08:16:27 | <tomsmeding> | it's meant to, it's a compatibility package |
| 08:17:23 | → | Square3 joins (~Square4@user/square) |
| 08:17:37 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 08:17:41 | <[exa]> | ok tuplic consistency has been reached |
| 08:21:50 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds) |
| 08:34:08 | × | Sgeo_ quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 08:35:10 | × | img quits (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 08:36:26 | → | img joins (~img@user/img) |
| 08:39:05 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 258 seconds) |
| 08:45:35 | → | merijn joins (~merijn@77.242.116.146) |
| 08:51:20 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 08:55:45 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
| 09:05:03 | → | haritz joins (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) |
| 09:05:03 | × | haritz quits (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host) |
| 09:05:03 | → | haritz joins (~hrtz@user/haritz) |
| 09:07:36 | <Square3> | I'm thinking I could generate .proto files from a big domain model using template haskell. But I wonder 1) is this a sane usecase for TH 2) Are there some best practice / support for generating things other than haskell code with TH? |
| 09:18:11 | <dminuoso> | tomsmeding: Well what do people use 1-element lists for? |
| 09:18:48 | <dminuoso> | probie: Sure I mean there is things isomorphic to it, but thats not quite the same. |
| 09:18:58 | <dminuoso> | Say you have some typeclass machinery that works over n-tuples. |
| 09:19:13 | <dminuoso> | If you want to tap into that, you need to special case the 1-tuple and it looks awkward |
| 09:19:25 | <dminuoso> | (), Solo 1, (1, 2), (1, 2, 3) |
| 09:19:27 | <dminuoso> | Just not pleasant. |
| 09:19:43 | <dminuoso> | Besides, that Solo will not have sufficient instances across the ecosystem |
| 09:21:03 | <lortabac> | overloaded parenthesis for both grouping and tuples is not ideal |
| 09:21:41 | <dminuoso> | lortabac: python gets away syntactically by just having (1,) a 1-tuple |
| 09:21:43 | <lortabac> | but it looks nice |
| 09:21:58 | <dminuoso> | And since a trailing comma is allowed in general, it fits nicely in |
| 09:22:12 | <lortabac> | dminuoso: that would be inconsistent with sections |
| 09:22:20 | <dminuoso> | Indeed |
| 09:22:20 | <lortabac> | (in Haskell) |
| 09:22:26 | × | Rain quits (\@user/Rain-:22721) (Quit: ZNC 1.9.1 - https://znc.in) |
| 09:22:32 | → | Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) |
| 09:23:01 | <dminuoso> | Personally I would have preferred an underscore for a section |
| 09:23:07 | <dminuoso> | i.e. (1,_) |
| 09:23:24 | <lortabac> | yes it's clearer |
| 09:23:42 | <lortabac> | but at the same time things like (+ 1) are nice |
| 09:24:04 | <lortabac> | tuple sections are good for consistency but probably not the best choice indeed |
| 09:24:45 | <dminuoso> | Its always easy to critize these things in hindsight *after* 37 additional extensions have developed. |
| 09:25:21 | <dminuoso> | Which underlines again the need for a time machine. |
| 09:27:05 | <lortabac> | also, TBH the lack of singleton tuple is a very minor problem |
| 09:27:09 | × | trickard_ quits (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 09:27:22 | → | trickard_ joins (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 09:27:42 | <dminuoso> | Dunno, I like the consistency in these things. Im also a fan of having nullary typeclasses. |
| 09:27:51 | × | Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 09:29:01 | <dminuoso> | When working with things like postgresql-simple a singleton tuple would feel nice |
| 09:30:55 | <tomsmeding> | dminuoso: typeclass machinery doesn't generalise over n-tuples at all |
| 09:31:06 | <tomsmeding> | TemplateHaskell does, but as I showed above, that is aware of Solo |
| 09:31:11 | <tomsmeding> | % $(pure $ TH.TupE [Just (TH.LitE (TH.IntegerL 42))]) |
| 09:31:11 | <yahb2> | MkSolo 42 |
| 09:31:54 | <tomsmeding> | and what people use 1-element lists for is cases where you want a list in the first place, i.e. you have a dynamically sized vector (that you don't want to put in an array for some reason) |
| 09:32:07 | <tomsmeding> | tuples are not dynamically sized so that use case doesn't apply |
| 09:33:07 | <tomsmeding> | "looks awkward" I can get on board with, but I think tuple sections are also nice, and I don't think the consistency in "(), Solo 1, (1, 2), (1, 2, 3)" is worth enough to not have tuple sections |
| 09:33:42 | <dminuoso> | tomsmeding: Like I said, I would have preferred (1, _) as tuple section syntax anyway. |
| 09:33:44 | <dminuoso> | :p |
| 09:33:44 | <tomsmeding> | Solo not having sufficient instances across the ecosystem is also fair |
| 09:33:53 | <tomsmeding> | ah I missed that bit |
| 09:34:11 | <tomsmeding> | Agda does something like that |
| 09:34:22 | <tomsmeding> | _+ 3 :: Int -> Int |
| 09:34:35 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 09:34:57 | <dminuoso> | yeah and more crazily you can declare arbitrary mixfix things with that. |
| 09:35:01 | <tomsmeding> | yes |
| 09:35:11 | <dminuoso> | Even if then else is user definable this way, its crazy. |
| 09:35:12 | <tomsmeding> | if_then_else_ : Bool -> a -> a -> a |
| 09:35:20 | <dminuoso> | I dont even want to know how that parser is written. |
| 09:35:40 | ski | would like "composite sections", like `(1 + 2 *)' (being `\x -> 1 + 2 * x') |
| 09:35:41 | <tomsmeding> | I hear that it's not actually that terrible, but I've never looked at it |
| 09:36:00 | <tomsmeding> | ski: they already work if the precedence works out; `(1 * 2 +)' does work |
| 09:36:07 | <tomsmeding> | % :t (1 * 2 +) |
| 09:36:07 | <yahb2> | (1 * 2 +) :: Num a => a -> a |
| 09:36:30 | <ski> | yes, but this is specifically for the other way around, with precedence & associativity |
| 09:36:47 | <tomsmeding> | at that point I'd feel more for dminuoso's syntax |
| 09:36:49 | <tomsmeding> | (1 + 2 * _) |
| 09:36:52 | <ski> | @type (?f . ?g .) |
| 09:36:53 | <lambdabot> | error: |
| 09:36:53 | <lambdabot> | The operator ‘.’ [infixr 9] of a section |
| 09:36:53 | <lambdabot> | must have lower precedence than that of the operand, |
| 09:36:58 | <ski> | this is annoying |
| 09:37:02 | <tomsmeding> | fair |
| 09:37:44 | <tomsmeding> | because (.) is defined infixr |
| 09:38:02 | <tomsmeding> | in general though, GHC doesn't know anything about actual associativity of operators |
| 09:38:13 | ski | also would not be a fan of `_' for sections |
| 09:39:21 | <tomsmeding> | dminuoso: have you thought about combining mixfix with precedence and associativity |
| 09:39:36 | <tomsmeding> | if not, then yes agda does that too |
| 09:40:26 | <ski> | people might start wanting `(0,(1,_),3)' to mean `\x -> (0,(1,x),3)' (rather than `(0,\x -> (1,x),3)'). the problem is one of delimitation, how far out does it "extend". if you insist on a missing operand at the start, or the end, with no extra syntax before/after those, that solves that issue |
| 09:41:12 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
| 09:41:14 | <tomsmeding> | but then you're drawing an arbitrary line where \x -> (1,2,x) can be a section and \x -> (1,x,2) cannot |
| 09:41:20 | <tomsmeding> | er, s/,/+/g |
| 09:41:27 | <ski> | yes |
| 09:41:47 | <ski> | i consider tuple sections to be a different animal than operator sections |
| 09:41:49 | <tomsmeding> | currently there is also an arbitrary line: the partially-applied operator must be at the top level |
| 09:41:58 | <tomsmeding> | I'm not sure your arbitrary line is better |
| 09:42:11 | <tomsmeding> | neither is fully general |
| 09:42:15 | <ski> | mm |
| 09:42:39 | <tomsmeding> | yours is more general than the current one, granted |
| 09:42:48 | <ski> | "where \x -> (1,2,x) can be a section" -- not with non-tuple sections |
| 09:42:50 | × | tromp quits (~textual@2001:1c00:3487:1b00:4ca2:8197:56e4:708) (Ping timeout: 245 seconds) |
| 09:43:00 | <tomsmeding> | yeah sorry I wrote tuples but I meant + |
| 09:43:08 | <tomsmeding> | with TupleSections both are already possible |
| 09:43:15 | <tomsmeding> | and I presume they would remain possible with your proposal |
| 09:43:18 | <ski> | ah, so `\x -> 1 + 2 + x' ? |
| 09:43:21 | → | ridcully joins (~ridcully@p57b5234b.dip0.t-ipconnect.de) |
| 09:43:26 | <tomsmeding> | yes, versus `\x -> 1 + x + 2' |
| 09:43:50 | <tomsmeding> | and if you say + is commutative, sure, some other non-commutative operator :p |
| 09:43:50 | <ski> | having non-numeric precedences would also be nice |
| 09:44:03 | <tomsmeding> | Agda has fractional precedences |
| 09:44:12 | → | petrichor joins (~jez@user/petrichor) |
| 09:44:23 | <ski> | but you'd want to be able to declare precedence groups, and after-the-fact include more operators into existing groups |
| 09:44:28 | × | petrichor quits (~jez@user/petrichor) (Remote host closed the connection) |
| 09:44:43 | <tomsmeding> | that sounds equivalent to numeric precedences, except for less names? |
| 09:44:58 | <tomsmeding> | an actual serious generalisation would be a precedence lattice |
| 09:45:14 | <tomsmeding> | but then that feels hard to usably accomplish in practice |
| 09:45:43 | <tomsmeding> | and usefully -- you get the same problem as we currently have with needing to depend on half of hackage just to give all the instances for your new fancy data type |
| 09:46:49 | × | LainIwakura quits (~LainIwaku@user/LainIwakura) (Quit: Client closed) |
| 09:46:49 | → | petrichor joins (~jez@user/petrichor) |
| 09:47:35 | <ski> | also, if `A o B p C q D' is legal, where `o',`p',`q' are infix operators, and `A',`B',`C',`D' are atomic expressions (or expressions of less precedence than the respective adjacent operators), a useful rule to ponder having, would be that `A o B q D' and `A o C q D' also (ignoring types) ought to be legal |
| 09:48:20 | <ski> | this is a kind of abstract transitivity of precedences & associativity |
| 09:49:39 | <ski> | having a prefix/suffix version of `(...)' (grouping) would violate this, btw, so that probably still ought to be an exception |
| 09:50:12 | <ski> | (note that `A o' there is basically a prefix operator, and `q D' a suffix operator) |
| 09:50:15 | × | petrichor quits (~jez@user/petrichor) (Client Quit) |
| 09:51:02 | <tomsmeding> | % 1 == 2 && 3 == 4 |
| 09:51:02 | <yahb2> | False |
| 09:51:07 | <tomsmeding> | % 1 == 3 == 4 |
| 09:51:08 | <yahb2> | <interactive>:89:1: error: [GHC-88747] ; Precedence parsing error ; cannot mix ‘==’ [infix 4] and ‘==’ [infix 4] in the same infix expression |
| 09:51:17 | <tomsmeding> | this rule is currently false in haskell |
| 09:51:37 | <tomsmeding> | (if I'm reading you correctly) |
| 09:52:15 | <tomsmeding> | (this is not about types, while the types differ here you could define operators with these precedences where all the types are the same) |
| 09:52:22 | <ski> | so, more generally, you could say `o B p C q' (where `o' is prefix and `q' suffix), then also `o B q' and `o C q' (assuming the associativity of both `B' and `C' is below that of `q' resp. `o') |
| 09:53:40 | <ski> | mm yes, i should express that `p' is the intermediate operator, inbetween `o' and `q', here .. hmm |
| 09:56:06 | <ski> | the idea is that if you have an AST, left-leaning, or right-leaning, not requiring explicit grouping, then removing the intermediate node (and its side-subtree, not on the path), that should not suddenly cause you to require grouping being inserted, to cope with the two nodes/operators now being directly in contact to each other |
| 09:56:41 | <ski> | i suppose s/AST/CST/ |
| 09:57:46 | <ski> | the point, is that if you have abstract precedences, then it would be too much work, to specify every possible interaction between pairs of operators |
| 09:58:34 | → | petrichor joins (~jez@user/petrichor) |
| 09:58:58 | <ski> | you'd want some notion of transitivity, to be able to infer that if `+' binds more loosely than `*', and `*' binds more loosely than `^', then `+' binds more loosely than `^' |
| 10:00:19 | <ski> | (so, the question is how to tractably, modularly, specify the partial order of precedence) |
| 10:01:04 | → | fp joins (~Thunderbi@2001-14ba-6e24-3000--198.rev.dnainternet.fi) |
| 10:01:06 | <ski> | (btw, `if ... then ... else' would be a prefix operator, here, as well) |
| 10:01:15 | <ski> | (or, at least, could be) |
| 10:01:43 | → | LainIwakura joins (~LainIwaku@user/LainIwakura) |
| 10:03:49 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 255 seconds) |
| 10:04:08 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 10:04:16 | <ski> | oh .. right. i kinda started thinking about this, when reading some papers by Annika Aasa, about parsing. and also then looking a bit at Agda parsing |
| 10:05:20 | × | fp quits (~Thunderbi@2001-14ba-6e24-3000--198.rev.dnainternet.fi) (Ping timeout: 245 seconds) |
| 10:08:55 | × | petrichor quits (~jez@user/petrichor) (Quit: ZNC 1.10.1 - https://znc.in) |
| 10:10:35 | trickard_ | is now known as trickard |
| 10:11:19 | × | LainIwakura quits (~LainIwaku@user/LainIwakura) (Ping timeout: 250 seconds) |
| 10:13:57 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 10:14:09 | → | petrichor joins (~jez@user/petrichor) |
| 10:14:41 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 10:15:31 | × | CiaoSen quits (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 255 seconds) |
| 10:16:52 | × | petrichor quits (~jez@user/petrichor) (Client Quit) |
| 10:18:11 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
| 10:21:17 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 10:23:34 | → | LainIwakura joins (~LainIwaku@user/LainIwakura) |
| 10:24:40 | → | lortabac joins (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 10:26:20 | → | merijn joins (~merijn@77.242.116.146) |
| 10:35:26 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 10:37:17 | → | poscat joins (~poscat@user/poscat) |
| 10:38:58 | × | poscat0x04 quits (~poscat@user/poscat) (Ping timeout: 260 seconds) |
| 10:39:01 | <ski> | "Parsing as Deduction" by Fernando C. N. Pereira,David H. D. Warren in 1983-06-15 at <https://dl.acm.org/doi/pdf/10.3115/981311.981338> |
| 10:39:06 | × | mari-estel quits (~mari-este@user/mari-estel) () |
| 10:39:08 | <ski> | "Metamorphosis Grammar" (by Alain Colmerauer in 1978-05 ?) at <https://www.site.uottawa.ca/~szpak/pub/P4P/P4P_03_Metamorphosis_grammars.pdf> |
| 10:39:19 | <ski> | "Concrete Syntax for Data Objects in Functional Languages" by Annika Aasa,Kent Petersson,Dan Synek in 1988-07 at <https://web.archive.org/web/20070207110810/http://www.cs.chalmers.se/~kentp/conc.ps> |
| 10:39:29 | <ski> | "Recursive descent parsing of user defined distfix operators" (Lic. th.) by Annika Aasa in 1989 (at ?) |
| 10:39:37 | <ski> | "Precedences in Specifications and Implementations of Programming Languages" by ibid in 1991 at <https://web.archive.org/web/20070701130745/http://www.cs.chalmers.se/~annika/plilp91.ps>,<https://link.springer.com/content/pdf/10.1007/3-540-54444-5_98.pdf> |
| 10:39:44 | <ski> | "User Defined Syntax" (Ph. D. diss.) by ibid in 1992 at <https://web.archive.org/web/20050424185150/http://www.cs.chalmers.se/~annika/aasa-thesis.ps> |
| 10:39:50 | <ski> | "Precedences in Specifications and Implementations of Programming Languages" by ibid in 1995 at <https://web.archive.org/web/20070701130745/http://www.cs.chalmers.se/~annika/tcs95.ps> |
| 10:39:58 | <ski> | cf. <https://web.archive.org/web/20070701130745/http://www.cs.chalmers.se/~annika/> |
| 10:40:01 | <ski> | "Parsing Mixfix Operators" by Nils Anders Danielsson,Ulf Norell in 2008-09 at <https://www.cse.chalmers.se/~nad/publications/danielsson-norell-mixfix.pdf> |
| 10:41:06 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 256 seconds) |
| 10:41:33 | → | lortabac joins (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 10:42:10 | → | Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) |
| 10:47:47 | → | merijn joins (~merijn@77.242.116.146) |
| 10:48:34 | × | tremon quits (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 10:54:19 | × | xff0x quits (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 248 seconds) |
| 10:56:02 | → | __monty__ joins (~toonn@user/toonn) |
| 11:00:04 | × | caconym747 quits (~caconym@user/caconym) (Quit: bye) |
| 11:01:15 | × | ubert quits (~Thunderbi@178.165.191.145.wireless.dyn.drei.com) (Quit: ubert) |
| 11:02:14 | → | caconym747 joins (~caconym@user/caconym) |
| 11:03:07 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 11:03:35 | → | fp joins (~Thunderbi@wireless-86-50-140-161.open.aalto.fi) |
| 11:08:40 | × | [exa] quits (~exa@user/exa/x-3587197) (Remote host closed the connection) |
| 11:12:17 | → | merijn joins (~merijn@77.242.116.146) |
| 11:20:41 | × | Googulator quits (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
| 11:20:58 | → | Googulator joins (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
| 11:25:04 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds) |
| 11:27:43 | → | [exa] joins (~exa@user/exa/x-3587197) |
| 11:28:15 | × | Alleria_ quits (~Alleria@user/alleria) (Read error: Connection reset by peer) |
| 11:28:47 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 11:28:49 | × | Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 250 seconds) |
| 11:30:31 | → | SlackCoder joins (~SlackCode@208.26.70.132) |
| 11:33:01 | × | Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 11:35:08 | → | Alleria joins (~Alleria@user/alleria) |
| 11:38:20 | × | jbalint quits (~jbalint@2600:6c44:117f:e98a:40bb:52ad:62b8:5122) (Read error: Connection reset by peer) |
| 11:42:16 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
| 11:44:29 | × | LainIwakura quits (~LainIwaku@user/LainIwakura) (Ping timeout: 250 seconds) |
| 11:46:39 | → | Guest56 joins (~Guest56@37.111.214.210) |
| 11:47:39 | → | Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915) |
| 11:49:49 | × | Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 11:50:44 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 11:54:03 | → | Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915) |
| 11:54:30 | → | jbalint joins (~jbalint@syn-071-090-116-115.res.spectrum.com) |
| 11:56:25 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 11:58:27 | → | vanishingideal joins (~vanishing@user/vanishingideal) |
| 11:59:27 | × | Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine) |
| 12:02:37 | × | SlackCoder quits (~SlackCode@208.26.70.132) (Quit: Leaving) |
| 12:02:43 | → | Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915) |
| 12:05:06 | × | inline quits (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) (Quit: Leaving) |
| 12:05:07 | × | Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 12:05:28 | × | Guest56 quits (~Guest56@37.111.214.210) (Quit: Client closed) |
| 12:11:24 | → | xff0x joins (~xff0x@2405:6580:b080:900:4d35:2673:a36a:250b) |
| 12:19:37 | → | tremon joins (~tremon@83.80.159.219) |
| 12:20:45 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Ping timeout: 245 seconds) |
| 12:21:06 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 12:26:59 | → | Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915) |
| 12:27:59 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 12:28:18 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 12:37:42 | → | petrichor joins (~jez@user/petrichor) |
| 12:38:16 | × | trickard quits (~trickard@cpe-54-98-47-163.wireline.com.au) (Ping timeout: 248 seconds) |
| 12:42:07 | × | jreicher quits (~user@user/jreicher) (Ping timeout: 258 seconds) |
| 12:42:07 | → | trickard_ joins (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 12:42:34 | → | jreicher joins (~user@user/jreicher) |
| 12:43:35 | × | petrichor quits (~jez@user/petrichor) (Quit: ZNC 1.10.1 - https://znc.in) |
| 12:45:14 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 12:46:07 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 12:48:02 | <kqr> | I have a CPU bound loop that is embarassingly parallel. What would be the modern way to split that up into equal chunks and run each of them on a separate core? I tried naïvely using forConcurrently from the async library, but that seemed like it ended up causing more contention and context switches because the evaluation went a lot slower with it. |
| 12:48:17 | <kqr> | (I did compile with -threaded and run with -N2 to test.) |
| 12:49:25 | <merijn> | kqr: Yeah, forConcurrently for CPU bound tasks spawns a lot more threads than useful |
| 12:51:04 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 248 seconds) |
| 12:51:08 | <merijn> | kqr: Fortunately for you, I had exactly this issue, approximately a decade ago and I got so tired of reinventing the wheel for myself that this exists: https://hackage-content.haskell.org/package/broadcast-chan-0.3.0/docs/BroadcastChan.html#g:4 |
| 12:51:29 | <kqr> | Since these are very short-lived tasks I also suspect it'd benefit from setting up the plumbing first and then using light operations to throw tasks at workers. |
| 12:51:59 | <merijn> | kqr: That's pretty much what the linked code does :p |
| 12:52:14 | → | lbseale joins (~quassel@user/ep1ctetus) |
| 12:52:42 | <L29Ah> | kqr: https://hackage.haskell.org/package/parallel-io-0.3.5/docs/Control-Concurrent-ParallelIO-Local.html maybe |
| 12:52:48 | <merijn> | Ignore the large dependency list shown by hackage, it's not great at showing dependencies for multi-lib packages. The core library I linked has a transitive dependency tree of 3 (including base and transformers) |
| 12:55:37 | <kqr> | merijn, if I understand it correctly, the parFoldMap would be setting up the plumbing afresh each time it is called, so if I use that I would want it to wrap a larger piece of work. Alternatively I could spawn a few workers and hand them BroadcastChan handles to receive work from if I want to schedule smaller pieces of work at a time? |
| 12:59:23 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
| 12:59:26 | → | simplystuart joins (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) |
| 13:02:20 | → | petrichor joins (~jez@user/petrichor) |
| 13:05:58 | × | mange quits (~mange@user/mange) (Quit: Zzz...) |
| 13:06:13 | → | AndreiDuma joins (~AndreiDum@user/AndreiDuma) |
| 13:08:26 | <kqr> | L29Ah, I tested that first because it was easiest to adapt the code to. Takes 2.5× longer than single-threaded when I run it with two threads. It seems like it doesn't pin the processes to threads and just go with it, but swap them around or something, because none of the cores are particularly utilised while it runs in parallel. |
| 13:09:28 | <L29Ah> | sounds strange, it worked well for me |
| 13:10:12 | <L29Ah> | -O2 -threaded -rtsopts "-with-rtsopts -N" |
| 13:10:57 | <kqr> | https://entropicthoughts.com/pastes/Main-e34639.hs.html That's the code, compiled -threaded and run +RTS -N2. I don't think I'm using it wrong. |
| 13:11:37 | × | AndreiDuma quits (~AndreiDum@user/AndreiDuma) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 13:12:59 | × | vanishingideal quits (~vanishing@user/vanishingideal) (Ping timeout: 248 seconds) |
| 13:13:27 | → | Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) |
| 13:20:06 | <merijn> | kqr: the conduit library lets you stream jobs into parallel workers |
| 13:20:48 | <merijn> | kqr: That's what I did, use conduit to stream task descriptions into workers, then reassemble after processing in parallel |
| 13:28:43 | <merijn> | kqr: For large inputs I'm not at all surprised it's slower |
| 13:29:07 | <merijn> | Since it just immediately forks of N (where N is your input size) forkIO threads, then has them fighting over the available RTS capabilities to finish |
| 13:29:19 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 13:29:23 | <merijn> | Which is fine if they're largely blocking, but pointless for CPU bound work |
| 13:30:27 | <merijn> | kqr: The parMapM/parMapM_ in the conduit library are pretty nice if you want to stream a large number of jobs: https://hackage-content.haskell.org/package/broadcast-chan-0.3.0/docs/BroadcastChan-Conduit.html#v:parMapM |
| 13:42:05 | <L29Ah> | kqr: lgtm, i use it similarily in hyborg |
| 13:42:51 | <L29Ah> | merijn: are you sure you don't have funny thread-blocking things like unsafePerformIO in your workload? |
| 13:43:07 | <L29Ah> | or those "safe" FFI calls |
| 13:43:26 | <L29Ah> | er kqr |
| 13:43:47 | <merijn> | unsafePerformIO itself should be fine |
| 13:43:51 | <merijn> | and safe FFI calls too |
| 13:44:21 | <L29Ah> | unsafePerformIO stops all the other threads until finished IIRC |
| 13:44:33 | <merijn> | That's definitely not true |
| 13:45:24 | <merijn> | The closest thing to that that is true is unsafe foreign calls block garbage collection (and can thus block other capabilities if they need to GC) |
| 13:46:03 | <merijn> | but unsafe foreign calls are a far cry from unsafePerformIO |
| 13:47:59 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 13:48:18 | <tomsmeding> | IIRC parallel evaluation of a thunk that is an unsafePerformIO will lock |
| 13:48:42 | <tomsmeding> | but that is redundant parallel evaluation of _one_ thunk, which is not helpful anyway |
| 13:48:50 | <merijn> | tomsmeding: Yes |
| 13:49:14 | <merijn> | something with blackholing/grey holing |
| 13:49:19 | <merijn> | And I always forget which is which |
| 13:49:24 | <tomsmeding> | ¯\_(ツ)_/¯ |
| 13:50:17 | <tomsmeding> | merijn: unsafePerformIO does something more special than normal blackholing though, which is what all thunks do to catch <<loop>> |
| 13:50:22 | <L29Ah> | it is helpful if it is a thing like a static array read |
| 13:50:27 | <tomsmeding> | there is this noDuplicate# call where I don't know what it does |
| 13:50:34 | <L29Ah> | while waiting for a lock is very expensive compared to the read |
| 13:50:41 | <merijn> | tomsmeding: Yeah, <<loop>> is blackholing, I think the parallel evaluation thing is greyholing |
| 13:50:43 | → | CiaoSen joins (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) |
| 13:50:48 | <tomsmeding> | L29Ah: a static array read should probably use unsafeDupablePerformIO if you care about parallel efficiency |
| 13:50:58 | <tomsmeding> | because that doesn't do the additional noDuplicate stuff |
| 13:51:01 | <tomsmeding> | ah |
| 13:51:19 | <L29Ah> | https://github.com/haskell/unix/issues/157 yes but people don't believe |
| 13:51:28 | <L29Ah> | anyway that's just my guess re kqr's lack of performance |
| 13:52:07 | <merijn> | L29Ah: I mean, the "forces the program to run single-threaded" is still wrong |
| 13:52:08 | <L29Ah> | mayhaps lock trashing would result in worse-than-single-thread performance |
| 13:52:21 | <L29Ah> | yes it is imprecise, sorry :] |
| 13:52:25 | <merijn> | L29Ah: And tbh, I don't think unsafePerformIO has any meaningful impact on any of the operations that unix does |
| 13:52:49 | <L29Ah> | it does when you have millions of files to poke in your backup program |
| 13:53:48 | <tomsmeding> | L29Ah: I think the unix maintainers will be more eager to make the changes you request if you come with an actual benchmark :) |
| 13:54:18 | <tomsmeding> | because "unsafePerformIO makes your code run single-threaded" is simply false, but it may well be that due to some other effects, that ends up being the case in your particular use-case |
| 14:06:50 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 14:08:22 | <EvanR> | not all IO actions even do I/O |
| 14:10:28 | <EvanR> | or access shared resources |
| 14:13:26 | → | SlackCoder joins (~SlackCode@remote.nationalgallery.org.ky) |
| 14:15:13 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 250 seconds) |
| 14:16:57 | → | Sgeo joins (~Sgeo@user/sgeo) |
| 14:17:19 | → | mari-estel joins (~mari-este@user/mari-estel) |
| 14:33:06 | → | inline joins (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) |
| 14:35:23 | × | jbalint quits (~jbalint@syn-071-090-116-115.res.spectrum.com) (Quit: Bye!) |
| 14:39:10 | × | CiaoSen quits (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds) |
| 14:39:20 | → | emperori joins (~emperori@223.187.122.81) |
| 14:43:54 | × | inline quits (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) (Read error: Connection reset by peer) |
| 14:43:57 | × | emperori quits (~emperori@223.187.122.81) (Read error: Connection reset by peer) |
| 14:44:21 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 14:45:24 | → | Guest56 joins (~Guest56@140.235.141.169) |
| 14:45:31 | × | Guest56 quits (~Guest56@140.235.141.169) (Client Quit) |
| 14:45:55 | → | afu1101 joins (~afu1101@140.235.141.167) |
| 14:46:29 | × | afu1101 quits (~afu1101@140.235.141.167) (Client Quit) |
| 14:46:59 | → | mari81549 joins (~mari-este@user/mari-estel) |
| 14:47:28 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.5.2) |
| 14:47:49 | → | inline joins (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) |
| 14:48:37 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 258 seconds) |
| 14:48:52 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 14:48:58 | × | mari-estel quits (~mari-este@user/mari-estel) (Read error: Connection reset by peer) |
| 14:49:50 | → | merijn joins (~merijn@77.242.116.146) |
| 14:59:47 | → | Lycurgus joins (~juan@user/Lycurgus) |
| 15:00:53 | × | califax quits (~califax@user/califx) (Remote host closed the connection) |
| 15:01:08 | → | califax joins (~califax@user/califx) |
| 15:06:57 | × | fp quits (~Thunderbi@wireless-86-50-140-161.open.aalto.fi) (Ping timeout: 248 seconds) |
| 15:07:13 | × | petrichor quits (~jez@user/petrichor) (Ping timeout: 250 seconds) |
| 15:07:55 | → | Tuplanolla joins (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 15:09:20 | → | petrichor joins (~jez@user/petrichor) |
| 15:13:36 | × | SlackCoder quits (~SlackCode@remote.nationalgallery.org.ky) (Remote host closed the connection) |
| 15:18:48 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 15:23:07 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 258 seconds) |
| 15:23:41 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 250 seconds) |
| 15:27:00 | trickard_ | is now known as trickard |
| 15:27:11 | × | inline quits (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) (Remote host closed the connection) |
| 15:27:45 | → | inline joins (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) |
| 15:33:05 | <geekosaur> | there is one sense in which it may have that effect: the difference between `unsafePerformIO` and `unsafeDupablePerformIO` |
| 15:35:21 | → | merijn joins (~merijn@77.242.116.146) |
| 15:37:40 | → | NucleusBiffBot joins (~nucleusbi@user/NucleusBiffBot) |
| 15:37:41 | ← | NucleusBiffBot parts (~nucleusbi@user/NucleusBiffBot) () |
| 15:41:10 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 15:45:44 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 258 seconds) |
| 15:46:03 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 15:46:13 | → | marinelli joins (~weechat@gateway/tor-sasl/marinelli) |
| 15:47:50 | × | Googulator quits (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
| 15:48:00 | → | Googulator joins (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
| 15:50:10 | → | MelodyOwO joins (~MelodyOwO@user/MelodyOwO) |
| 16:03:43 | × | pavonia quits (~user@user/siracusa) (Quit: Bye!) |
| 16:08:04 | × | Square3 quits (~Square4@user/square) (Ping timeout: 256 seconds) |
| 16:13:16 | → | LainIwakura joins (~LainIwaku@user/LainIwakura) |
| 16:14:03 | × | Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 16:15:10 | → | AndreiDuma joins (~AndreiDum@user/AndreiDuma) |
| 16:15:51 | × | AndreiDuma quits (~AndreiDum@user/AndreiDuma) (Client Quit) |
| 16:15:58 | → | Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) |
| 16:18:36 | × | inline quits (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) (Remote host closed the connection) |
| 16:18:49 | → | humodz joins (~humodz@user/humodz) |
| 16:19:09 | → | inline joins (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) |
| 16:20:57 | × | LainIwakura quits (~LainIwaku@user/LainIwakura) (Ping timeout: 250 seconds) |
| 16:25:58 | → | wootehfoot joins (~wootehfoo@user/wootehfoot) |
| 16:27:46 | → | emperori joins (~emperori@223.187.127.81) |
| 16:39:54 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 16:40:12 | × | hellwolf quits (~user@2f26-cc5a-24cf-d632-0f00-4d40-07d0-2001.sta.estpak.ee) (Ping timeout: 252 seconds) |
| 16:45:09 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 16:45:25 | <EvanR> | and accursedUnutterablePerformIO? |
| 16:46:07 | → | hellwolf joins (~user@9629-38e7-765b-6e41-0f00-4d40-07d0-2001.sta.estpak.ee) |
| 16:46:42 | <geekosaur> | only if you want to share your address space with an imp 🙂 |
| 16:53:32 | → | ft joins (~ft@p4fc2a25a.dip0.t-ipconnect.de) |
| 16:54:02 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 16:54:16 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 16:54:44 | × | Lycurgus quits (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 16:56:03 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 16:56:55 | × | marinelli quits (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 16:57:15 | → | marinelli joins (~weechat@gateway/tor-sasl/marinelli) |
| 16:58:32 | → | sprotte24 joins (~sprotte24@p5dd5d928.dip0.t-ipconnect.de) |
| 17:02:47 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 17:14:14 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 17:16:03 | × | mari81549 quits (~mari-este@user/mari-estel) (Ping timeout: 256 seconds) |
| 17:16:17 | × | inline quits (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) (Remote host closed the connection) |
| 17:16:49 | → | inline joins (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) |
| 17:19:11 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 17:19:15 | → | tzh joins (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 17:21:44 | × | simplystuart quits (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 256 seconds) |
| 17:22:18 | → | simplystuart joins (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) |
| 17:25:07 | → | peterbecich joins (~Thunderbi@syn-172-222-149-049.res.spectrum.com) |
| 17:30:17 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 17:33:41 | × | krei-se quits (~krei-se@p200300f1cfff1648915f43887404f7ca.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 17:35:06 | → | V joins (~v@ircpuzzles/2022/april/winner/V) |
| 17:35:22 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 17:38:16 | × | chele quits (~chele@user/chele) (Remote host closed the connection) |
| 17:38:27 | → | krei-se joins (~krei-se@p200300f1cf342301915f43887404f7ca.dip0.t-ipconnect.de) |
| 17:39:50 | × | vetkat quits (~vetkat@user/vetkat) (Quit: So long, and thanks for all the fish) |
| 17:43:20 | × | emperori quits (~emperori@223.187.127.81) (Read error: Connection reset by peer) |
| 17:43:44 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 17:44:34 | → | vetkat joins (~vetkat@user/vetkat) |
| 17:46:18 | danso_o | is now known as danso |
| 17:47:48 | × | peterbecich quits (~Thunderbi@syn-172-222-149-049.res.spectrum.com) (Ping timeout: 256 seconds) |
| 17:48:08 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 17:55:44 | × | MelodyOwO quits (~MelodyOwO@user/MelodyOwO) (Quit: Leaving.) |
| 17:56:33 | × | comonad quits (~comonad@p200300d027244d00edac481148480656.dip0.t-ipconnect.de) (Quit: WeeChat 4.7.0-dev) |
| 17:59:18 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 18:04:07 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 18:08:58 | × | inline quits (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) (Remote host closed the connection) |
| 18:09:32 | → | inline joins (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) |
| 18:15:10 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 18:20:13 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 18:22:01 | × | Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 18:24:27 | × | divlamir quits (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 18:24:40 | → | divlamir joins (~divlamir@user/divlamir) |
| 18:33:11 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 18:40:09 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 18:44:39 | → | emperori joins (~emperori@2401:4900:6299:772f:dc20:49b3:341f:d3e3) |
| 18:48:16 | × | Beowulf quits (florian@gabilgathol.bandrate.org) (Quit: = "") |
| 18:50:00 | <tomsmeding> | geekosaur: wouldn't that only be if you evaluate the same thunk from multiple threads? |
| 18:50:10 | <tomsmeding> | (which is not particularly useful in the first place) |
| 18:54:39 | → | Beowulf joins (florian@gabilgathol.bandrate.org) |
| 18:57:51 | <geekosaur> | consider launching multiple threads running the same function: if they all call the same inner function with the same parameters, this may end up being the same thunk (couldn't happen in IO, I think, but pure code allows lifting which is part of why unsafe*PerformIO is unsafe and accursed… is *really* unsafe) |
| 18:58:09 | × | inline quits (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) (Remote host closed the connection) |
| 18:59:47 | <tomsmeding> | geekosaur: I'd guess in that situation, either 1. GHC doesn't realise it's the same call, so they will be separate calls at runtime anyway and thus be separate thunks, or 2. GHC did lift out the inner call and it will only be evaluated once, so subsequent calls to the same function will not evaluate the sequential part again |
| 19:00:00 | × | caconym747 quits (~caconym@user/caconym) (Quit: bye) |
| 19:00:07 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 19:00:20 | <tomsmeding> | and in case 2, if that deduplicated call takes much of the runtime that was supposed to be parallel, why are you running it in parallel -- it's the same call multiple times |
| 19:00:41 | → | caconym747 joins (~caconym@user/caconym) |
| 19:02:15 | → | inline joins (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) |
| 19:02:51 | × | Googulator quits (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
| 19:03:03 | → | Googulator joins (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
| 19:04:44 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 19:05:11 | <dminuoso> | ski: Regarding the question of how far that hypothetical section syntax would extend, the answer is simple: not at all, just like current sections dont extend at all. |
| 19:06:06 | <dminuoso> | The type system will cover practically all uses, and for non-trivial ideas of a section expression you can always just degrade to an explicit lambda - just like with current operator sections. |
| 19:08:24 | → | Lycurgus joins (~juan@user/Lycurgus) |
| 19:09:02 | × | byorgey quits (~byorgey@user/byorgey) (Ping timeout: 260 seconds) |
| 19:09:20 | → | byorgey joins (~byorgey@user/byorgey) |
| 19:11:29 | → | sprotte24_ joins (~sprotte24@p5dd5d928.dip0.t-ipconnect.de) |
| 19:12:36 | × | Alleria quits (~Alleria@user/alleria) (Read error: Connection reset by peer) |
| 19:12:38 | × | trickard quits (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 19:12:51 | → | trickard_ joins (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 19:13:53 | × | Beowulf quits (florian@gabilgathol.bandrate.org) (Quit: = "") |
| 19:14:52 | × | sprotte24 quits (~sprotte24@p5dd5d928.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 19:15:54 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 19:16:24 | → | gehmehgeh joins (~user@user/gehmehgeh) |
| 19:16:32 | × | gmg quits (~user@user/gehmehgeh) (Ping timeout: 272 seconds) |
| 19:16:38 | gehmehgeh | is now known as gmg |
| 19:16:48 | × | wootehfoot quits (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 19:19:39 | → | Beowulf joins (florian@gabilgathol.bandrate.org) |
| 19:19:42 | → | Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) |
| 19:20:44 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 19:22:36 | → | Alleria joins (~Alleria@user/alleria) |
| 19:25:16 | × | emperori quits (~emperori@2401:4900:6299:772f:dc20:49b3:341f:d3e3) (Ping timeout: 256 seconds) |
| 19:31:44 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 19:33:14 | → | target_i joins (~target_i@user/target-i/x-6023099) |
| 19:36:27 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 19:45:44 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 19:46:23 | × | ec quits (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 19:46:57 | → | ec joins (~ec@gateway/tor-sasl/ec) |
| 19:50:11 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 20:01:10 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 20:05:59 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 20:06:01 | × | Vq quits (~vq@90-224-37-169-no600.tbcn.telia.com) (Ping timeout: 258 seconds) |
| 20:07:58 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 20:12:29 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 20:12:55 | × | ChaiTRex quits (~ChaiTRex@user/chaitrex) (Ping timeout: 272 seconds) |
| 20:12:59 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 260 seconds) |
| 20:13:07 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 20:14:47 | → | ChaiTRex joins (~ChaiTRex@user/chaitrex) |
| 20:16:56 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 20:18:04 | × | fgarcia quits (~lei@user/fgarcia) (Quit: Remote host closed the connection) |
| 20:20:22 | × | Googulator quits (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
| 20:20:35 | → | Googulator joins (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
| 20:23:38 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 20:23:53 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 20:27:12 | × | myme quits (~myme@2a01:799:d5e:5f00:a615:4b08:208e:f085) (Ping timeout: 265 seconds) |
| 20:27:54 | → | myme joins (~myme@2a01:799:d5e:5f00:e0b2:6c10:9733:ecc) |
| 20:31:28 | × | sord937 quits (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 20:32:13 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 250 seconds) |
| 20:34:58 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 20:36:33 | × | V quits (~v@ircpuzzles/2022/april/winner/V) (Ping timeout: 248 seconds) |
| 20:36:35 | × | takuan quits (~takuan@d8D86B9E9.access.telenet.be) (Remote host closed the connection) |
| 20:38:24 | → | peterbecich joins (~Thunderbi@syn-172-222-149-049.res.spectrum.com) |
| 20:40:03 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 20:41:05 | × | target_i quits (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 20:42:27 | → | V joins (~v@ircpuzzles/2022/april/winner/V) |
| 20:50:46 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 20:54:22 | × | Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 20:55:25 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 20:56:38 | × | Googulator quits (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
| 20:56:51 | × | img quits (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 20:56:52 | → | Googulator joins (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
| 20:58:09 | → | img joins (~img@user/img) |
| 20:59:29 | × | michalz quits (~michalz@185.246.207.201) (Remote host closed the connection) |
| 20:59:39 | → | segfaultfizzbuzz joins (~segfaultf@c-73-93-227-157.hsd1.ca.comcast.net) |
| 21:06:16 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 21:06:49 | → | Sunny joins (19541d7ff8@irc.cheogram.com) |
| 21:07:27 | Sunny | is now known as _test |
| 21:07:36 | _test | is now known as _testytest |
| 21:09:49 | × | peterbecich quits (~Thunderbi@syn-172-222-149-049.res.spectrum.com) (Ping timeout: 255 seconds) |
| 21:11:11 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 21:22:03 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 21:22:08 | → | pavonia joins (~user@user/siracusa) |
| 21:27:06 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 21:36:24 | × | segfaultfizzbuzz quits (~segfaultf@c-73-93-227-157.hsd1.ca.comcast.net) (Ping timeout: 260 seconds) |
| 21:37:49 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 21:42:25 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 21:43:58 | → | weary-traveler joins (~user@user/user363627) |
| 21:49:40 | → | emmanuelux joins (~emmanuelu@user/emmanuelux) |
| 21:53:37 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 21:59:50 | × | Googulator quits (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
| 22:00:03 | → | Googulator joins (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
| 22:00:31 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 22:02:27 | → | ld86 joins (~ld86@mort-07-b2-v4wan-169474-cust3363.vm24.cable.virginm.net) |
| 22:02:54 | × | ld86 quits (~ld86@mort-07-b2-v4wan-169474-cust3363.vm24.cable.virginm.net) (Client Quit) |
| 22:05:08 | × | __monty__ quits (~toonn@user/toonn) (Quit: leaving) |
| 22:07:31 | → | tzh_ joins (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 22:07:42 | × | tzh quits (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Read error: Connection reset by peer) |
| 22:09:18 | × | gmg quits (~user@user/gehmehgeh) (Remote host closed the connection) |
| 22:10:53 | → | karenw_ joins (~karenw@user/karenw) |
| 22:11:40 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 22:16:52 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 22:19:43 | × | weary-traveler quits (~user@user/user363627) (Quit: Konversation terminated!) |
| 22:19:59 | → | weary-traveler joins (~user@user/user363627) |
| 22:25:19 | → | user363627 joins (~user@user/user363627) |
| 22:27:27 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 22:29:13 | × | weary-traveler quits (~user@user/user363627) (Ping timeout: 250 seconds) |
| 22:30:16 | × | humodz quits (~humodz@user/humodz) (Quit: The Lounge - https://thelounge.chat) |
| 22:32:16 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 22:33:39 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 22:38:07 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 244 seconds) |
| 22:39:33 | × | Tuplanolla quits (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 22:42:16 | <monochrom> | Heh I wished section syntax to be more general too, but I can see that it could easily get out of hand. |
| 22:43:15 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 22:44:38 | × | karenw_ quits (~karenw@user/karenw) (Quit: Deep into that darkness peering...) |
| 22:45:19 | <monochrom> | Tangentially, Python has this if-then-else syntax: "expr1 if cond else expr0", it's like C's "cond ? expr1 : expr0". Python doesn't allow cond itself to be another "e1 if c else e0" for simplicity, but I don't see why not, so in my course I gave a parser assignment that included it. |
| 22:46:12 | × | sprotte24_ quits (~sprotte24@p5dd5d928.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 22:46:20 | → | segfaultfizzbuzz joins (~segfaultf@c-73-202-118-116.hsd1.ca.comcast.net) |
| 22:47:31 | × | Lycurgus quits (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 22:47:33 | → | sprotte24_ joins (~sprotte24@p5dd5d928.dip0.t-ipconnect.de) |
| 22:48:17 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 22:48:54 | <monochrom> | I also allowed expr0 to be its own if-else. (But not expr1, unless parenthesized.) So, overall, there is simple solution: Imagine the "if cond else" chunk as a right-associating infix operator! It's just chainr1 ifelse expr. |
| 22:48:59 | → | sprotte24___ joins (~sprotte24@p5dd5d928.dip0.t-ipconnect.de) |
| 22:52:11 | × | sprotte24_ quits (~sprotte24@p5dd5d928.dip0.t-ipconnect.de) (Ping timeout: 250 seconds) |
| 22:52:38 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 22:57:31 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 22:58:17 | → | peterbecich joins (~Thunderbi@syn-172-222-149-049.res.spectrum.com) |
| 23:09:40 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 23:11:55 | × | xff0x quits (~xff0x@2405:6580:b080:900:4d35:2673:a36a:250b) (Ping timeout: 248 seconds) |
| 23:14:12 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 23:15:20 | × | acidjnk quits (~acidjnk@p200300d6e7171926a81168b3bd2506b7.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 23:19:19 | → | xff0x joins (~xff0x@2405:6580:b080:900:4d35:2673:a36a:250b) |
| 23:23:14 | → | mange joins (~mange@user/mange) |
| 23:25:03 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 23:26:00 | × | sprotte24___ quits (~sprotte24@p5dd5d928.dip0.t-ipconnect.de) (Quit: Leaving) |
| 23:29:55 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 23:34:20 | × | Googulator quits (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
| 23:34:32 | → | Googulator joins (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
| 23:40:51 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 23:43:06 | × | peterbecich quits (~Thunderbi@syn-172-222-149-049.res.spectrum.com) (Ping timeout: 256 seconds) |
| 23:43:44 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 23:47:38 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 23:51:07 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 250 seconds) |
| 23:58:54 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
All times are in UTC on 2025-09-11.