2024-09-21 00:02:32 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 00:04:07 +0200 | weary-traveler | (~user@user/user363627) |
2024-09-21 00:07:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
2024-09-21 00:09:19 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
2024-09-21 00:10:22 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 00:10:24 +0200 | libertyprime | (~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz) |
2024-09-21 00:11:03 +0200 | weary-traveler | (~user@user/user363627) |
2024-09-21 00:12:26 +0200 | talismanick | (~user@2601:644:937c:ed10::ae5) |
2024-09-21 00:13:51 +0200 | neuroevolutus | (~neuroevol@37.19.200.139) (Ping timeout: 256 seconds) |
2024-09-21 00:16:39 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
2024-09-21 00:18:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 00:19:06 +0200 | mikess | (~mikess@user/mikess) |
2024-09-21 00:20:31 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
2024-09-21 00:23:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 00:24:56 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) |
2024-09-21 00:31:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 00:35:43 +0200 | ell | (~ellie@user/ellie) (Quit: Ping timeout (120 seconds)) |
2024-09-21 00:36:05 +0200 | ell | (~ellie@user/ellie) |
2024-09-21 00:36:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
2024-09-21 00:37:40 +0200 | mjrosenb | (~mjrosenb@pool-96-232-177-77.nycmny.fios.verizon.net) (Ping timeout: 252 seconds) |
2024-09-21 00:39:05 +0200 | mjrosenb | (~mjrosenb@pool-96-232-177-77.nycmny.fios.verizon.net) |
2024-09-21 00:42:45 +0200 | mikess | (~mikess@user/mikess) (Quit: mikess) |
2024-09-21 00:46:25 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 00:47:24 +0200 | mikess | (~mikess@user/mikess) |
2024-09-21 00:47:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 00:52:33 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds) |
2024-09-21 00:52:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 00:54:16 +0200 | <Inst> | monochrom: |
2024-09-21 00:54:23 +0200 | <Inst> | sorry, here's how to show the behavior |
2024-09-21 00:54:26 +0200 | <Inst> | import Debug.Trace |
2024-09-21 00:55:37 +0200 | <Inst> | x <|>> y = traceWith (\u -> show u <> " was evaluated on the left") x <|> y |
2024-09-21 00:55:46 +0200 | <Inst> | Just 3 <|>> Nothing <|>> Nothing |
2024-09-21 00:56:30 +0200 | <Inst> | also, I just discovered you can declare operators in function arguments |
2024-09-21 00:57:49 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 01:03:06 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 246 seconds) |
2024-09-21 01:03:29 +0200 | <Inst> | > with (****) a b = a **** b |
2024-09-21 01:03:31 +0200 | <lambdabot> | <hint>:1:17: error: parse error on input ‘=’ |
2024-09-21 01:03:31 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 01:03:54 +0200 | <Inst> | well, it works in 9.10 ghci :( |
2024-09-21 01:08:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2024-09-21 01:08:45 +0200 | Oxf1ac | (~0xf1ac@62.4.42.168) |
2024-09-21 01:09:00 +0200 | <Inst> | tomsmeding: you CAN stylistically decide to use >>= to make the data flow more obvious, afaik everyone decided to just write functional python with do and <- instead |
2024-09-21 01:09:27 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 01:09:52 +0200 | <monochrom> | do-notation still desugars to right-associative uses of >>= |
2024-09-21 01:12:47 +0200 | Oxf1ac | (~0xf1ac@62.4.42.168) (Remote host closed the connection) |
2024-09-21 01:12:55 +0200 | <monochrom> | It is fair to say that infixr is better for >>, <|>, >=> in most use cases, and the standard library made the wrong choice. |
2024-09-21 01:13:07 +0200 | <monochrom> | But this is getting blown out of proportion. |
2024-09-21 01:13:11 +0200 | Oxf1ac | (~0xf1ac@62.4.42.168) |
2024-09-21 01:13:57 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds) |
2024-09-21 01:18:07 +0200 | <monochrom> | Not to mention that "foo <|> (bar <|> x)" is not that hard to write if you find the infixl unsatisfactory. |
2024-09-21 01:18:38 +0200 | <Inst> | ehhh, just pointing out infelicities, it's not a big deal tbh |
2024-09-21 01:18:47 +0200 | <Inst> | it's a good reason not to abuse >>= and =<< for golfing |
2024-09-21 01:19:01 +0200 | <monochrom> | "Does >>= leak?" is not making a big fuzz? |
2024-09-21 01:19:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 01:19:52 +0200 | <Inst> | i suppose i should apologize for "baby's first exposure to thinking space and spaceleaks with laziness", but it would do no good |
2024-09-21 01:20:27 +0200 | <Inst> | that said, just out of curiosity, when do you introduce Debug.Trace, monochrom? |
2024-09-21 01:24:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
2024-09-21 01:25:18 +0200 | <monochrom> | Being novice in technical matters is not the issue I'm complaining about. |
2024-09-21 01:25:57 +0200 | <monochrom> | The dark pattern of always going hyperbole is. |
2024-09-21 01:26:35 +0200 | <Inst> | criticism acknowledged |
2024-09-21 01:32:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 01:36:14 +0200 | Squared | (~Square@user/square) |
2024-09-21 01:37:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 01:43:16 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 01:43:39 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb13044e7157fd3ef949.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
2024-09-21 01:46:32 +0200 | Oxf1ac | (~0xf1ac@62.4.42.168) (Quit: WeeChat 4.4.2) |
2024-09-21 01:48:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 01:49:18 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 246 seconds) |
2024-09-21 01:50:07 +0200 | <Inst> | monochrom: I should have been more careful in wording and asked whether >>= leaks in direct use, i'm still pouring over GHC core output to check whether or not it does on O2 or higher optimizations |
2024-09-21 01:50:23 +0200 | <Inst> | and yeah i'm aware of the () desugaring of do |
2024-09-21 01:52:17 +0200 | <Inst> | the other realistic issue is, that from what i've seen, thinking lazily isn't prioritized in most haskell books i've seen, and there's been commercial users of haskell that've dropped Haskell because they weren't proficient in laziness |
2024-09-21 01:53:27 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 01:53:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
2024-09-21 01:58:08 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds) |
2024-09-21 01:58:10 +0200 | <Inst> | also, another question |
2024-09-21 01:58:36 +0200 | <Inst> | actually, forget it, maybe another time |
2024-09-21 02:04:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 02:04:40 +0200 | <probie> | You can evaluate that question thunk at a later time |
2024-09-21 02:06:35 +0200 | <Inst> | it's more like weirdness with GHCI, possibly not an issue with ghc |
2024-09-21 02:07:13 +0200 | <Inst> | if i bang a let declaration in a do block, do traceShowId over a number, it doesn't evaluate, if I traceShowId something else, it evaluates |
2024-09-21 02:07:53 +0200 | <Inst> | it looks like it's wonkiness related to default types, because if I affix a type annotation, it evaluates |
2024-09-21 02:09:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-09-21 02:10:09 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 02:15:52 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
2024-09-21 02:20:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 02:22:56 +0200 | ZharMeny | (~ZharMeny@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
2024-09-21 02:25:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
2024-09-21 02:32:20 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
2024-09-21 02:33:59 +0200 | califax | (~califax@user/califx) |
2024-09-21 02:36:07 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 02:40:52 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 02:51:51 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 02:53:19 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
2024-09-21 02:55:07 +0200 | troojg | (~troojg@user/troojg) |
2024-09-21 02:56:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 03:04:01 +0200 | <cheater> | what |
2024-09-21 03:07:40 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 03:12:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
2024-09-21 03:21:40 +0200 | pavonia | (~user@user/siracusa) |
2024-09-21 03:22:55 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
2024-09-21 03:23:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 03:24:54 +0200 | Oxf1ac | (~Oxf1ac@62.4.42.168) |
2024-09-21 03:27:36 +0200 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
2024-09-21 03:28:31 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
2024-09-21 03:30:16 +0200 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) |
2024-09-21 03:35:38 +0200 | Oxf1ac | (~Oxf1ac@62.4.42.168) (WeeChat 4.4.2) |
2024-09-21 03:35:54 +0200 | gvg_ | (~dcd@user/gvg) |
2024-09-21 03:36:58 +0200 | gvg | (~dcd@user/gvg) (Ping timeout: 252 seconds) |
2024-09-21 03:39:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 03:44:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-09-21 03:44:57 +0200 | Fijxu_ | (~Fijxu@user/fijxu) (Ping timeout: 252 seconds) |
2024-09-21 03:48:37 +0200 | <probie> | % do{let {!x=trace "Hello" 42}; putStrLn "World"} |
2024-09-21 03:48:37 +0200 | <yahb2> | World |
2024-09-21 03:48:45 +0200 | <probie> | % do{let {!x=trace "Hello" (42 :: Int)}; putStrLn "World"} |
2024-09-21 03:48:45 +0200 | <yahb2> | Hello ; World |
2024-09-21 03:48:59 +0200 | Fijxu | (~Fijxu@user/fijxu) |
2024-09-21 03:49:00 +0200 | <probie> | That isn't type defaulting |
2024-09-21 03:49:20 +0200 | <probie> | % do{let {x=trace "Hello" (42 :: Int)}; x `seq` putStrLn "World"} |
2024-09-21 03:49:20 +0200 | <yahb2> | Hello ; World |
2024-09-21 03:49:30 +0200 | <probie> | % do{let {x=trace "Hello" 42}; x `seq` putStrLn "World"} |
2024-09-21 03:49:30 +0200 | <yahb2> | Hello ; World |
2024-09-21 03:51:12 +0200 | <probie> | It's that `x` has type `Num a => a`, which is "pretty much" a function, and therefore already in WHNF since it's a lambda |
2024-09-21 03:54:12 +0200 | Squared | (~Square@user/square) (Ping timeout: 252 seconds) |
2024-09-21 03:54:20 +0200 | <Inst> | thanks probie |
2024-09-21 03:54:33 +0200 | <Inst> | but if you do this on ghc, it works |
2024-09-21 03:55:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 03:55:17 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
2024-09-21 03:55:19 +0200 | <geekosaur> | in a sense that is defaulting |
2024-09-21 03:56:27 +0200 | <geekosaur> | ghci has NoMonomorphismRestriction, so it doesn't resolve things like (Num a => a) immediately. ghc doesn't, so it gets defaulted to Int and is no longer a function taking a Num dictionary |
2024-09-21 03:56:30 +0200 | Guest19 | (~Guest57@syn-075-131-084-201.res.spectrum.com) |
2024-09-21 03:57:14 +0200 | <geekosaur> | if you compile with -XNoMonomorphismRestriction, you should get the same behavior as ghci |
2024-09-21 03:58:03 +0200 | <geekosaur> | if you run it in "ghci -XMonomorphismRestriction", you should get the same behavior as ghc |
2024-09-21 03:59:57 +0200 | Guest19 | (~Guest57@syn-075-131-084-201.res.spectrum.com) (Client Quit) |
2024-09-21 03:59:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
2024-09-21 04:02:33 +0200 | <Inst> | thanks geekosaur |
2024-09-21 04:03:42 +0200 | <geekosaur> | this kind of confusion is more or less why the monomorphism restriction exists and is the default; x there "looks like" a value, but without the MMR it's actually a function |
2024-09-21 04:04:15 +0200 | <Inst> | also, curious, can you still get unsafePerformIO to segfault with the example code? |
2024-09-21 04:04:38 +0200 | <geekosaur> | I saw you bring that up in #ghc but I haven't lookmed |
2024-09-21 04:05:01 +0200 | <Inst> | it's weird, but probably why it's just unsafe, i.e, might be platform specific |
2024-09-21 04:05:49 +0200 | <Inst> | thanks anyways |
2024-09-21 04:06:00 +0200 | <Inst> | I used to get it to crash, but I guess that's why it's unsafe |
2024-09-21 04:06:08 +0200 | <Inst> | undefined behavior depending on platform and kernel version |
2024-09-21 04:07:25 +0200 | <geekosaur> | I think the example code was "broken" by ghc's runtime representations changing in 8.10.5+ to support Apple AArch64 |
2024-09-21 04:07:40 +0200 | <geekosaur> | but that's just a suspicion |
2024-09-21 04:07:46 +0200 | <geekosaur> | (it didn't core here) |
2024-09-21 04:07:52 +0200 | <Inst> | i swapped to 8.x via ghcup |
2024-09-21 04:08:55 +0200 | <Inst> | still fails to crash, I suspect it's something to do with linux kernel updates |
2024-09-21 04:09:25 +0200 | <geekosaur> | keep in mind that I'm on Ubuntu 22.04, so my kernel is practically ancient |
2024-09-21 04:11:59 +0200 | <Inst> | iirc it does crash in windows, but i sort of lost my windows drive :( |
2024-09-21 04:12:41 +0200 | <geekosaur> | the problem they're talking about can't be fixed as such (it might be made slightly less likely to happen in certain specific cases, but the general problem is not fixable) |
2024-09-21 04:13:05 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Remote host closed the connection) |
2024-09-21 04:13:35 +0200 | <geekosaur> | as the discussion says, if you have unsafePerformIO, you have unsafeCoerce and what happens if you use it as such will be up to the whim of the RTS |
2024-09-21 04:15:27 +0200 | <geekosaur> | the example code may now be too simplistic to demonstrate the problem, but I'm sure it won't need much tweaking to reveal it again |
2024-09-21 04:17:03 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 04:19:23 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
2024-09-21 04:26:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 04:31:55 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
2024-09-21 04:34:30 +0200 | td_ | (~td@i53870926.versanet.de) (Ping timeout: 246 seconds) |
2024-09-21 04:36:21 +0200 | td_ | (~td@i5387092D.versanet.de) |
2024-09-21 04:40:48 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) (Ping timeout: 246 seconds) |
2024-09-21 04:42:23 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 04:43:13 +0200 | <Inst> | this is weird |
2024-09-21 04:43:43 +0200 | <Inst> | 234288 unsafeCoerce-ed to System.IO.Handle gets you the crash I'm looking for |
2024-09-21 04:43:50 +0200 | <Inst> | but other integers don't produce the same effects |
2024-09-21 04:44:08 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Remote host closed the connection) |
2024-09-21 04:44:43 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
2024-09-21 04:45:08 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 04:45:20 +0200 | terrorjack4 | (~terrorjac@2a01:4f8:c17:dc9f::) (Quit: The Lounge - https://thelounge.chat) |
2024-09-21 04:46:01 +0200 | <Inst> | okay, Integers (mostly) seem to produce the desired crash on unsafeCoerce to System.IO.Handle (using unsafePerformIO) |
2024-09-21 04:47:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
2024-09-21 04:47:36 +0200 | terrorjack4 | (~terrorjac@static.48.15.202.116.clients.your-server.de) |
2024-09-21 04:49:43 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds) |
2024-09-21 04:53:12 +0200 | <geekosaur> | that's not too surprising, it very likely depends on the internal GMP representation |
2024-09-21 04:53:33 +0200 | <geekosaur> | that's more or less what you're inviting with unsafeCoerce in any form |
2024-09-21 04:54:05 +0200 | <Inst> | iirc it should be safe to use unsafePerformIO for read-only operations, right? as long as you ensure the write is done beforehand |
2024-09-21 04:54:26 +0200 | <Inst> | i'm more trying to figure out when it's safe to use unsafeCoerce |
2024-09-21 04:54:54 +0200 | <geekosaur> | even read-only is unsafe if you coerced an unboxed value into a boxed one |
2024-09-21 04:55:24 +0200 | <geekosaur> | because reading it will follow what it thinks is a pointer |
2024-09-21 04:55:50 +0200 | <geekosaur> | @quote monochrom unsafeCoerce.*Either |
2024-09-21 04:55:50 +0200 | <lambdabot> | monochrom says: isTrue = (unsafeCoerce :: Either a b -> Bool) . (unsafeCoerce :: Maybe c -> Either a b) . (unsafeCoerce :: Bool -> Maybe c) |
2024-09-21 04:56:50 +0200 | <geekosaur> | if (a) all types are boxed (b) all types have at least as many constructors as the starting type does, you can generally get away with it |
2024-09-21 04:56:51 +0200 | <Inst> | i mean without coercion in unsafePerformIO, i.e, a way to avoid passing large parameters around |
2024-09-21 04:57:34 +0200 | <geekosaur> | unsafePerformIO only matters insofar as it can give you a polymorphic IORef, which implicitly unsafeCoerces anything taken out of it |
2024-09-21 04:57:56 +0200 | <Inst> | iirc i used unsafePerformIO as an optimization pass |
2024-09-21 04:58:09 +0200 | <geekosaur> | it's the unsafeCoerce part, however you got it, that is problematic |
2024-09-21 04:58:10 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 04:58:44 +0200 | <Inst> | i thought the main reason unsafePerformIO was considered unsafe was because Haskell gives very weak guarantees on evaluation order of pure functions? |
2024-09-21 04:58:56 +0200 | <geekosaur> | and re "large parameters", if they are boxed, you're passing a pointer |
2024-09-21 04:59:08 +0200 | <geekosaur> | if they're unboxed, you need to rethink your design |
2024-09-21 04:59:36 +0200 | <Inst> | weird because it was boxed, and I was using monomorphic IORef and got a performance improvement |
2024-09-21 05:00:00 +0200 | <geekosaur> | not really. if you want that level of unsafety, you want accursedUnutterablePerformIO (that is, inlining runRW#) |
2024-09-21 05:02:06 +0200 | <geekosaur> | unsafePerformIO will reveal to you when things are evaluated (on demand aka "lazily") but won't in general cause evaluation order issues otherwise |
2024-09-21 05:02:32 +0200 | <geekosaur> | at least, not any more than multithreaded access to the same resource will |
2024-09-21 05:03:14 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
2024-09-21 05:03:47 +0200 | <geekosaur> | con template Debug.Trace, which uses unsafePerformIO under the hood |
2024-09-21 05:04:40 +0200 | <Inst> | ehhh, unsafePerformIO sort of breaks the entire haskell programming model, doesn't it? |
2024-09-21 05:04:44 +0200 | <Inst> | since you can now run IO anywhere |
2024-09-21 05:05:17 +0200 | <geekosaur> | if you get a performance improvement from an IORef, I would first suspect you had thunk buildup that the IORef was causing to be forced |
2024-09-21 05:06:11 +0200 | <Inst> | probably, sigh |
2024-09-21 05:06:33 +0200 | <Inst> | also, by the way, do I finally get monads now that I'm thinking in terms of monadic typeclasses? |
2024-09-21 05:06:51 +0200 | <geekosaur> | actually, no, you can't. that;s not what unsafePerformIO is. unsafePerformIO is "hey compiler, I promise you that this is actually pure". at which point it is evaluated on demand instead of forcing evaluation |
2024-09-21 05:06:56 +0200 | <Inst> | as in, Constraint m => m a type actions |
2024-09-21 05:07:14 +0200 | <geekosaur> | not all constraints are monads |
2024-09-21 05:07:45 +0200 | <geekosaur> | what if the constraint is Functor? |
2024-09-21 05:07:58 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 05:08:24 +0200 | <Inst> | i know, but what I mean is that using monadic / applicative polymorphism to write actions such that it's the type that forces the actual codepath |
2024-09-21 05:09:02 +0200 | <Inst> | hence the old canard about "computation in a context" |
2024-09-21 05:09:04 +0200 | <geekosaur> | mmm, I'd say that's more about "free monad"? |
2024-09-21 05:09:11 +0200 | <geekosaur> | which is a subset of monads |
2024-09-21 05:09:51 +0200 | <geekosaur> | that said, I'm operating on 3h of sleep and it's getting late here so I may be blathering at this point 😞 |
2024-09-21 05:12:00 +0200 | <Inst> | i'm blathering at all times, go to bed, geekosaur, it's friday :) |
2024-09-21 05:12:33 +0200 | <geekosaur> | gotta wait for my nighttime drugs to kick in (in particular the painkillers, sigh) |
2024-09-21 05:13:53 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds) |
2024-09-21 05:13:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 05:14:01 +0200 | <Inst> | i'm sorry to hear :( |
2024-09-21 05:14:10 +0200 | <Inst> | and that's sort of a giveaway :( |
2024-09-21 05:14:20 +0200 | <Inst> | also I guess I was talking about mtl style |
2024-09-21 05:16:16 +0200 | <geekosaur> | effect systems do the same thing, they just get there via a different path |
2024-09-21 05:18:24 +0200 | <Inst> | what's the exact name for constraint-based polymorphic effects? |
2024-09-21 05:18:36 +0200 | <geekosaur> | beats me 🙂 |
2024-09-21 05:18:48 +0200 | <Inst> | iirc it was mentioned it's useful for mocking, but i can't figure out other contexts where the effect polymorphism is useful |
2024-09-21 05:19:12 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
2024-09-21 05:19:16 +0200 | <geekosaur> | swapping out effect providers |
2024-09-21 05:19:29 +0200 | <Inst> | i realize i had a large chunk of code, and it was problematic because i couldn't redirect stdout trivially |
2024-09-21 05:19:34 +0200 | <geekosaur> | for example, switching logging frameworks |
2024-09-21 05:20:43 +0200 | <geekosaur> | (this is not the problem I have with effect systems. the problem I have with them is that they will happily let you "algebraically" combine effects that mtl will rightly reject because they're not safe to combine) |
2024-09-21 05:20:45 +0200 | <dolio> | unsafeCoercing between boxed values, even if you think they should be represented 'the same' is not something you can generally get away with, in my experience. |
2024-09-21 05:21:05 +0200 | <dolio> | Boxed values of different types, that is. |
2024-09-21 05:21:12 +0200 | <geekosaur> | I provided a more specific rule earlier |
2024-09-21 05:21:24 +0200 | <geekosaur> | even used monochrom's quote to demonstrate 🙂 |
2024-09-21 05:26:36 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) |
2024-09-21 05:26:55 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
2024-09-21 05:27:20 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
2024-09-21 05:29:17 +0200 | bilegeek | (~bilegeek@227.sub-174-208-228.myvzw.com) (Quit: Leaving) |
2024-09-21 05:29:43 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 05:34:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 05:35:45 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
2024-09-21 05:37:14 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
2024-09-21 05:41:31 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
2024-09-21 05:45:31 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 05:46:49 +0200 | troojg | (~troojg@user/troojg) (Ping timeout: 260 seconds) |
2024-09-21 05:50:23 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
2024-09-21 05:50:27 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 05:54:58 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds) |
2024-09-21 05:58:50 +0200 | troojg | (~troojg@user/troojg) |
2024-09-21 06:01:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 06:04:05 +0200 | xff0x | (~xff0x@2405:6580:b080:900:64be:ce6a:a0a8:1563) (Ping timeout: 248 seconds) |
2024-09-21 06:04:23 +0200 | xff0x | (~xff0x@2405:6580:b080:900:64be:ce6a:a0a8:1563) |
2024-09-21 06:06:12 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 06:06:12 +0200 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) |
2024-09-21 06:17:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 06:21:57 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 06:23:46 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 06:28:11 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 252 seconds) |
2024-09-21 06:28:14 +0200 | troojg | (~troojg@user/troojg) (Ping timeout: 260 seconds) |
2024-09-21 06:30:26 +0200 | neuroevolutus | (~neuroevol@146.70.211.110) |
2024-09-21 06:34:20 +0200 | benjaminl | (~benjaminl@user/benjaminl) (Read error: Connection reset by peer) |
2024-09-21 06:34:36 +0200 | benjaminl | (~benjaminl@user/benjaminl) |
2024-09-21 06:48:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 06:53:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2024-09-21 06:53:29 +0200 | hammond | (proscan@gateway04.insomnia247.nl) (Ping timeout: 260 seconds) |
2024-09-21 06:54:33 +0200 | terrorjack4 | (~terrorjac@static.48.15.202.116.clients.your-server.de) (Quit: The Lounge - https://thelounge.chat) |
2024-09-21 06:55:31 +0200 | libertyprime | (~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz) (Remote host closed the connection) |
2024-09-21 06:57:21 +0200 | terrorjack4 | (~terrorjac@2a01:4f8:c17:dc9f::) |
2024-09-21 07:01:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 07:07:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
2024-09-21 07:09:03 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 07:13:51 +0200 | <Inst> | by the way, am i really not understanding arrows? |
2024-09-21 07:14:39 +0200 | <Inst> | getLine >>= (<$) <*> putStrLn >>= putStrLn is a shoddy mess |
2024-09-21 07:15:06 +0200 | <Inst> | but so's getLine >>= runKleisli (Kleisli putStrLn &&& Kleisli putStrLn) |
2024-09-21 07:15:41 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds) |
2024-09-21 07:15:45 +0200 | <Inst> | arr is Kleisli . (pure . f) ffs |
2024-09-21 07:16:56 +0200 | <Inst> | getLine >>= ((>>) . putStrLn) <*> putStrLn is only slightly better |
2024-09-21 07:17:46 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 07:23:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-09-21 07:25:05 +0200 | neuroevolutus | (~neuroevol@146.70.211.110) (Ping timeout: 256 seconds) |
2024-09-21 07:26:05 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
2024-09-21 07:28:20 +0200 | mikess | (~mikess@user/mikess) (Ping timeout: 252 seconds) |
2024-09-21 07:30:25 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
2024-09-21 07:32:00 +0200 | euphores | (~SASL_euph@user/euphores) |
2024-09-21 07:32:37 +0200 | euphores | (~SASL_euph@user/euphores) (Max SendQ exceeded) |
2024-09-21 07:33:14 +0200 | euphores | (~SASL_euph@user/euphores) |
2024-09-21 07:33:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 07:38:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 07:45:21 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 07:49:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 07:50:07 +0200 | hammond | (proscan@gateway04.insomnia247.nl) |
2024-09-21 07:52:31 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 252 seconds) |
2024-09-21 07:54:00 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2024-09-21 08:02:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 08:06:48 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 08:07:20 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
2024-09-21 08:07:32 +0200 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
2024-09-21 08:09:29 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
2024-09-21 08:10:01 +0200 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) |
2024-09-21 08:12:04 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
2024-09-21 08:15:25 +0200 | <Inst> | for that problem |
2024-09-21 08:15:46 +0200 | <Inst> | getLine >>= for_ [putStrLn, putStrLn] . (&) works better |
2024-09-21 08:16:41 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
2024-09-21 08:18:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 08:18:05 +0200 | neuroevolutus | (~neuroevol@146.70.211.110) |
2024-09-21 08:21:40 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
2024-09-21 08:22:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 08:26:19 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 08:31:19 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 264 seconds) |
2024-09-21 08:33:23 +0200 | Me-me | (~me-me@kc.randomserver.name) (Read error: Connection reset by peer) |
2024-09-21 08:33:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 08:34:45 +0200 | Me-me | (~me-me@kc.randomserver.name) |
2024-09-21 08:38:43 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 08:41:12 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2024-09-21 08:44:48 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 08:49:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 08:49:58 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 245 seconds) |
2024-09-21 08:54:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2024-09-21 08:59:09 +0200 | <geekosaur> | Inst, Arrows are mostly a failed experiment |
2024-09-21 08:59:29 +0200 | <geekosaur> | but they gave rise to Profunctor and Applicative |
2024-09-21 08:59:45 +0200 | <geekosaur> | however there are some FRP frameworks based on Arrows |
2024-09-21 09:00:01 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
2024-09-21 09:00:02 +0200 | <geekosaur> | some of which have proposed modified versions of Arrow |
2024-09-21 09:00:18 +0200 | JamesMowery | (~JamesMowe@ip98-167-207-182.ph.ph.cox.net) (Quit: Goodbye) |
2024-09-21 09:00:37 +0200 | caconym | (~caconym@user/caconym) |
2024-09-21 09:00:45 +0200 | JamesMowery | (~JamesMowe@ip98-167-207-182.ph.ph.cox.net) |
2024-09-21 09:02:40 +0200 | <geekosaur> | I think the original idea was abstraction over composition, that is, normal functions and monadic functions (wrapped in Kleisli) can be composed in the same way in an Arrow framework |
2024-09-21 09:03:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 09:03:17 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Ping timeout: 248 seconds) |
2024-09-21 09:03:39 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds) |
2024-09-21 09:03:52 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
2024-09-21 09:04:26 +0200 | <geekosaur> | but it turned out that there was no real point in unifying (.) and (>=>), and while Arrow has the potential for static analysis, `arr` severely restricts what you can do with it |
2024-09-21 09:05:19 +0200 | <geekosaur> | (sorry, `flip (.)`) |
2024-09-21 09:06:59 +0200 | <ski> | `arr' should be moved to a subclass |
2024-09-21 09:08:03 +0200 | <geekosaur> | I have so far heard 3 proposals for how Arrow should be reworked |
2024-09-21 09:08:11 +0200 | <geekosaur> | none of them seems to have much traction |
2024-09-21 09:08:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
2024-09-21 09:08:57 +0200 | <geekosaur> | and I'm not sure any of them is compatible with the few existing users of Arrow (e.g. Yampa) |
2024-09-21 09:10:17 +0200 | <ski> | didn't conal have some work on compiling categorical stuff ? |
2024-09-21 09:10:34 +0200 | <geekosaur> | "Compiling to Categories"? |
2024-09-21 09:11:29 +0200 | <ski> | probably, yeah |
2024-09-21 09:12:48 +0200 | <geekosaur> | but he went straight to Control.Category in the paper I dug up |
2024-09-21 09:13:53 +0200 | <ski> | maybe we need `proc' notation that uses that |
2024-09-21 09:14:30 +0200 | <geekosaur> | (he used a plugin) |
2024-09-21 09:17:46 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 09:19:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 09:22:05 +0200 | <Inst> | geekosaur: you're STILl in pain? :( |
2024-09-21 09:22:48 +0200 | <Inst> | since i thought you went to sleep |
2024-09-21 09:23:09 +0200 | <geekosaur> | my sleep has been severely disturbed for longer than I've had the neck/arm issue |
2024-09-21 09:23:24 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
2024-09-21 09:23:26 +0200 | jle` | (~jle`@2603:8001:3b02:84d4:6c44:9933:28ff:d264) (Remote host closed the connection) |
2024-09-21 09:23:36 +0200 | <geekosaur> | it's absolutely not unusual that I wake up 02:30-03:00 and am up for an hour or so 😞 |
2024-09-21 09:23:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-09-21 09:24:06 +0200 | jle` | (~jle`@2603:8001:3b02:84d4:eb82:e687:8bae:8fb3) |
2024-09-21 09:24:06 +0200 | <Inst> | by the way, if I want to model an HTML object, is vector or seq a better application data structure for children / attributes? |
2024-09-21 09:24:31 +0200 | <tomsmeding> | Inst: will you be appending to that list |
2024-09-21 09:24:43 +0200 | <Inst> | yes, which is why i'm thinking seq not vector |
2024-09-21 09:24:54 +0200 | <tomsmeding> | i.e. what's the ratio between the number of times you read that list, and the number of times you modify it |
2024-09-21 09:24:58 +0200 | <Inst> | i guess i'm doing yet another html / css library |
2024-09-21 09:25:20 +0200 | <geekosaur> | cue xkcd 😛 |
2024-09-21 09:25:23 +0200 | <Inst> | well, i mean, it'll be converted to lazy bytestring |
2024-09-21 09:25:35 +0200 | <tomsmeding> | if you can arrange to always append at the front, and don't need to index into the thing, plain [] may be best |
2024-09-21 09:25:48 +0200 | <geekosaur> | that's what I was thinking |
2024-09-21 09:25:54 +0200 | <Inst> | wait, can you edit / replace Blaze / Lucid HTML types once they've been generated? |
2024-09-21 09:25:59 +0200 | <geekosaur> | but it definitely depends on what uou're doing |
2024-09-21 09:26:53 +0200 | <Inst> | iirc blaze and lucid are builders |
2024-09-21 09:27:07 +0200 | <tomsmeding> | bonus points if you ensure that client code can only treat the thing as a Monoid, so that you can swap out the implementation later :) |
2024-09-21 09:27:09 +0200 | <Inst> | https://hackage.haskell.org/package/type-of-html |
2024-09-21 09:29:00 +0200 | <Inst> | well, i have no idea what i'm doing, i think implementing ADTs for HTML / CSS will probably help me learn HTML / CSS better, and when this stuff falls through, I'll just rewrite the library |
2024-09-21 09:29:08 +0200 | <Inst> | already have a friend lined up to help me maintain it |
2024-09-21 09:29:31 +0200 | geekosaur | is having a "that trick never works!" moment |
2024-09-21 09:29:46 +0200 | <tomsmeding> | I feel like coding up representations of html/css will help you very well in learning the syntax of them both |
2024-09-21 09:29:50 +0200 | <Inst> | whatever, I'll just use list then then change the datatypes later! |
2024-09-21 09:29:55 +0200 | <tomsmeding> | which is like the easiest and least interesting part :) |
2024-09-21 09:29:56 +0200 | <Inst> | thanks tomsmeding |
2024-09-21 09:30:10 +0200 | <geekosaur> | (well, I nsuppose an ADT doesn't necessarily imply a structure) |
2024-09-21 09:30:16 +0200 | <Inst> | yeah, well, finally get out of vaporware, actually build something useful in the Haskell ecosystem instead of being a semi-tolerated troll |
2024-09-21 09:30:24 +0200 | <Inst> | and then go rework it once I have some idea of what I'm doing |
2024-09-21 09:30:33 +0200 | <tomsmeding> | css gets really complicated in how all the properties interact, e.g. how css Grid interacts with other layout stuff |
2024-09-21 09:30:37 +0200 | <tomsmeding> | or how the whole box model works |
2024-09-21 09:31:04 +0200 | <tomsmeding> | does a box shadow count as size of the element or not? Does the border? (depends on the border-box property) |
2024-09-21 09:31:07 +0200 | <geekosaur> | welp. going to be up a while longer, I guess |
2024-09-21 09:31:13 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
2024-09-21 09:31:16 +0200 | <geekosaur> | fire engines just pulled up |
2024-09-21 09:31:21 +0200 | <tomsmeding> | O.o |
2024-09-21 09:31:38 +0200 | <tomsmeding> | nearby? |
2024-09-21 09:31:39 +0200 | <geekosaur> | either the building fire alarm misfired again, or someone's stuck in the elevator again |
2024-09-21 09:31:44 +0200 | <tomsmeding> | ah |
2024-09-21 09:32:04 +0200 | jle` | (~jle`@2603:8001:3b02:84d4:eb82:e687:8bae:8fb3) (Read error: Connection reset by peer) |
2024-09-21 09:32:46 +0200 | <geekosaur> | …and one of the engines just turned around and left. that usually takes longer if it's the building fire alarm |
2024-09-21 09:33:06 +0200 | <geekosaur> | so maybe (c) someone called 911 in a panic and they just sent everything |
2024-09-21 09:33:09 +0200 | <tomsmeding> | re css, also the whole priority ordering of rules |
2024-09-21 09:33:19 +0200 | <geekosaur> | akron's weird that way |
2024-09-21 09:33:41 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
2024-09-21 09:34:17 +0200 | gmg | (~user@user/gehmehgeh) |
2024-09-21 09:34:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 09:36:25 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 09:40:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
2024-09-21 09:41:13 +0200 | <tomsmeding> | I would imagine that happens in lots of places, sometimes |
2024-09-21 09:48:35 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 255 seconds) |
2024-09-21 09:50:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 09:52:56 +0200 | <Inst> | is it a good or bad thing that Haskell matches so many of my neuroses? |
2024-09-21 09:53:12 +0200 | <Inst> | like, I like planning too much, doing too little |
2024-09-21 09:53:50 +0200 | <tomsmeding> | it means that you should watch out for overfitting :) |
2024-09-21 09:53:53 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb631d346e810a542001.dip0.t-ipconnect.de) |
2024-09-21 09:54:01 +0200 | <tomsmeding> | (to a software development style) |
2024-09-21 09:55:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-09-21 09:56:54 +0200 | <tomsmeding> | Inst: ooof https://hackage.haskell.org/package/type-of-html-1.6.2.0/docs/src/Html.Type.Internal.html#line-1408 |
2024-09-21 09:56:59 +0200 | misterfish | (~misterfis@84.53.85.146) |
2024-09-21 09:57:52 +0200 | <Inst> | someone should have used template Haskell there |
2024-09-21 09:58:11 +0200 | <tomsmeding> | well it's not _too_ bad |
2024-09-21 09:58:18 +0200 | <tomsmeding> | and the list doesn't necessarily have to be any longer, maybe |
2024-09-21 09:58:26 +0200 | <tomsmeding> | but beautiful it is not :p |
2024-09-21 09:58:30 +0200 | <Inst> | I just brought up the library as something close to what I wanted, I'm just doing straight ADT (without fancy type mechanics) until I get the hang of things, but it's annoying how I can't use subtypes etc |
2024-09-21 09:59:46 +0200 | <tomsmeding> | type classes can give you kind of the dual of that, "sub-behaviours"? |
2024-09-21 10:00:45 +0200 | <tomsmeding> | i.e. if the more general behaviour is a superclass of the more specific one, then any type that implements the specfic behaviour will be implicitly known to also implement the more general behaviour |
2024-09-21 10:01:16 +0200 | <tomsmeding> | which is analogous to subtyping in OOP, where a specfic object is also implicitly a more general object |
2024-09-21 10:01:47 +0200 | <tomsmeding> | (if you don't need the "implicit" part, you can just use what OOP calls "composition", i.e. just put the parent object in a field of the child object) |
2024-09-21 10:02:43 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 10:02:43 +0200 | <tomsmeding> | (which is also how all of the implicit techniques are implemented; the compiler just knows about them and resolves references to the contained structure automagically) |
2024-09-21 10:02:44 +0200 | neuroevolutus | (~neuroevol@146.70.211.110) (Quit: Client closed) |
2024-09-21 10:04:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 10:07:52 +0200 | youthlic | (~Thunderbi@user/youthlic) (Quit: youthlic) |
2024-09-21 10:08:19 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
2024-09-21 10:09:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2024-09-21 10:09:30 +0200 | youthlic | (~Thunderbi@user/youthlic) |
2024-09-21 10:12:01 +0200 | gary_borg | (~gary_borg@144.6.194.76) |
2024-09-21 10:12:56 +0200 | <gary_borg> | why is haskelbridge my opp |
2024-09-21 10:13:04 +0200 | <gary_borg> | im confused with this app im new ot irc |
2024-09-21 10:13:09 +0200 | <gary_borg> | why is someone here my opp |
2024-09-21 10:13:12 +0200 | <gary_borg> | what did i do wronh |
2024-09-21 10:13:27 +0200 | <tomsmeding> | what do you mean with "opp"? |
2024-09-21 10:14:20 +0200 | <gary_borg> | opposition |
2024-09-21 10:14:36 +0200 | <gary_borg> | Opponent or Opposition |
2024-09-21 10:14:37 +0200 | <gary_borg> | Opp (Opponent or Opposition) "Opp" is a slang abbreviation of the word "opponent" or "enemy." It is commonly used to refer to someone who is viewed as an adversary or someone with whom one has a conflict or disagreement. |
2024-09-21 10:14:51 +0200 | <tomsmeding> | irc does not have a concept of "opposition", so not sure what you're referring to :) |
2024-09-21 10:15:40 +0200 | <Inst> | tomsmeding: tbh you're right, you could use typeclasses and existential types for that |
2024-09-21 10:16:06 +0200 | <tomsmeding> | Inst: existential types are almost never the right answer |
2024-09-21 10:16:28 +0200 | <tomsmeding> | sometimes they are, sure, but when modelling data, they usually bring more harm than good |
2024-09-21 10:17:23 +0200 | <Inst> | after touching julia, why yes, you can have an entire language made out of typeclasses (since implicitly in Julia every function is a typeclass) |
2024-09-21 10:17:25 +0200 | <gary_borg> | https://imgur.com/a/7GTqvrr this is what im referring to. |
2024-09-21 10:17:31 +0200 | <Inst> | just in Haskell it's a lot more wonky |
2024-09-21 10:17:59 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
2024-09-21 10:18:00 +0200 | <tomsmeding> | gary_borg: ah lol |
2024-09-21 10:18:15 +0200 | <tomsmeding> | an "op" (not "opp") is an "operator", i.e. a user with admin rights on the channel |
2024-09-21 10:18:19 +0200 | <tomsmeding> | that user here is ChanServ |
2024-09-21 10:18:26 +0200 | Inst | (~Inst@user/Inst) (Leaving) |
2024-09-21 10:18:29 +0200 | Inst | (~Inst@user/Inst) |
2024-09-21 10:18:39 +0200 | <tomsmeding> | which is a bot from the irc server that mediates admin rights to the actual people having said access |
2024-09-21 10:19:29 +0200 | <ski> | (clearly operators are opposition, adversaries) |
2024-09-21 10:19:33 +0200 | <tomsmeding> | :D |
2024-09-21 10:19:47 +0200 | <gary_borg> | timtamspelling: oh ok ythank yo for choryfinning |
2024-09-21 10:20:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 10:21:22 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 10:24:21 +0200 | gary_borg | (~gary_borg@144.6.194.76) (Quit: Leaving) |
2024-09-21 10:24:45 +0200 | gary_borg | (~gary_borg@144.6.194.76) |
2024-09-21 10:25:04 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 260 seconds) |
2024-09-21 10:25:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
2024-09-21 10:25:28 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 244 seconds) |
2024-09-21 10:26:45 +0200 | misterfish | (~misterfis@84.53.85.146) |
2024-09-21 10:27:05 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) |
2024-09-21 10:29:10 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
2024-09-21 10:31:36 +0200 | <Inst> | tomsmeding: why are existential types a bad idea? |
2024-09-21 10:35:02 +0200 | <ski> | @where existential-antipattern |
2024-09-21 10:35:02 +0200 | <lambdabot> | "Haskell Antipattern: Existential Typeclass" by Luke Palmer at <https://web.archive.org/web/20220121105027/https://lukepalmer.wordpress.com/2010/01/24/haskell-ant…> |
2024-09-21 10:35:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 10:36:27 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2024-09-21 10:38:12 +0200 | gary_borg | (~gary_borg@144.6.194.76) (Killed (ozone (No Spam))) |
2024-09-21 10:40:20 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 10:40:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-09-21 10:42:13 +0200 | random-jellyfish | (~developer@user/random-jellyfish) |
2024-09-21 10:45:38 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds) |
2024-09-21 10:50:31 +0200 | <Inst> | oh fine, i'll do it the old fashioned way with a sum type :( |
2024-09-21 10:51:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 10:55:33 +0200 | __monty__ | (~toonn@user/toonn) |
2024-09-21 10:56:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 10:56:55 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2024-09-21 10:59:22 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 11:03:53 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
2024-09-21 11:05:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 11:09:00 +0200 | srazkvt | (~sarah@user/srazkvt) |
2024-09-21 11:09:25 +0200 | srazkvt | (~sarah@user/srazkvt) (Client Quit) |
2024-09-21 11:10:16 +0200 | <tomsmeding> | Inst: what ski posted, but also just that they tend to make life more annoying while not actually helping much |
2024-09-21 11:10:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-09-21 11:11:44 +0200 | <tomsmeding> | mind you, exceptions exist, especially if your types have some GADT-like type parameters and you're doing some computations that cannot (or should not) be fully reflected on the type level |
2024-09-21 11:12:03 +0200 | <tomsmeding> | but if you're in that world, you tend to know it |
2024-09-21 11:20:50 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 255 seconds) |
2024-09-21 11:21:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 11:26:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
2024-09-21 11:27:15 +0200 | <Inst> | i'm more annoyed that you can't newtype constructors for these types of sumtypes |
2024-09-21 11:28:19 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
2024-09-21 11:28:28 +0200 | <tomsmeding> | Inst: what do you mean? |
2024-09-21 11:28:46 +0200 | <tomsmeding> | have a type that allows just one of the constructors? |
2024-09-21 11:29:04 +0200 | <tomsmeding> | you could make it a GADT and give it a type parameter that is different for each constructor |
2024-09-21 11:29:43 +0200 | <tomsmeding> | question is whether that's worth it |
2024-09-21 11:30:05 +0200 | <tomsmeding> | at least it still behaves properly with the rest of the language, contrary to existentials :p |
2024-09-21 11:36:19 +0200 | random-jellyfish | (~developer@user/random-jellyfish) (Quit: Leaving) |
2024-09-21 11:36:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 11:37:21 +0200 | CiaoSen | (~Jura@2a05:5800:22d:f000:ca4b:d6ff:fec1:99da) |
2024-09-21 11:40:34 +0200 | <Inst> | i mean that newtype is just transparent, it's effectively a type synonym that's enforced only on the type level |
2024-09-21 11:40:59 +0200 | <Inst> | also iirc there's some freaky laziness-related quirkiness there as well, i.e, the constructor doesn't exist and when you evaluate for the constructor you're also evaluating the underlying term, iirc |
2024-09-21 11:41:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2024-09-21 11:41:36 +0200 | <Inst> | but the two characteristics of newtypes are, no sum types, and only one field allowed |
2024-09-21 11:41:38 +0200 | <ski> | Hugs has restrricted type synonyms (like in the MLs) |
2024-09-21 11:42:24 +0200 | <Inst> | i'd rather have sum types (i.e, C union types) with the newtype transparency |
2024-09-21 11:42:34 +0200 | <tomsmeding> | Inst: do you mean sum types or union types? |
2024-09-21 11:42:40 +0200 | <tomsmeding> | union types do not have a tag, sum types do |
2024-09-21 11:42:59 +0200 | <Inst> | ah, and that's why Cmm can't do it, and thus haskell can't |
2024-09-21 11:43:18 +0200 | <tomsmeding> | the haskell source language has sum types, and no union types; C has union types and no sum types |
2024-09-21 11:43:23 +0200 | <tomsmeding> | python also "has" union types |
2024-09-21 11:43:27 +0200 | <tomsmeding> | as does typescript |
2024-09-21 11:44:19 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
2024-09-21 11:44:45 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) |
2024-09-21 11:45:09 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
2024-09-21 11:51:06 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
2024-09-21 11:52:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 11:52:57 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
2024-09-21 11:56:21 +0200 | nnm | (~nnm@79-139-162-83.dynamic.spd-mgts.ru) |
2024-09-21 11:57:09 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds) |
2024-09-21 11:57:28 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 11:59:39 +0200 | <Inst> | tagged unions, i guess |
2024-09-21 11:59:49 +0200 | <tomsmeding> | right |
2024-09-21 12:00:09 +0200 | <tomsmeding> | I'd call a tagged union a "sum type" when the language ensures that the tag and the union contents remain in sync |
2024-09-21 12:00:29 +0200 | wagle | (~wagle@quassel.wagle.io) (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
2024-09-21 12:01:15 +0200 | <tomsmeding> | well -- the language, or the API of the sum type, if it's implemented in user space |
2024-09-21 12:01:41 +0200 | <tomsmeding> | e.g. std::variant in C++ builds on the underlying support for union types to create a sum type, because its API doesn't allow letting the tag and the contents get out of sync |
2024-09-21 12:01:56 +0200 | <tomsmeding> | (never mind that there are umpteen other problems with std::variant, it's a mess, but it _is_ a sum type) |
2024-09-21 12:03:18 +0200 | <ski> | the tag also needs to be distinct from the type of the contents |
2024-09-21 12:03:32 +0200 | <ski> | (`A + A' should not equal `A'9 |
2024-09-21 12:04:00 +0200 | <tomsmeding> | I would rather formulate that as "every alternative of the union should have a distinct tag" |
2024-09-21 12:04:48 +0200 | <tomsmeding> | looking at the types becomes ambiguous if you have e.g. a language with refinement types, where Int and {v : Int | v > 0} are distinct types but have indistinguishable values |
2024-09-21 12:04:50 +0200 | <ski> | yep, that's a more constructive way to phrase it |
2024-09-21 12:05:39 +0200 | ski | would call those (subset) comprenesion types |
2024-09-21 12:06:08 +0200 | <tomsmeding> | isn't "refinement type" a more general term? |
2024-09-21 12:06:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 12:06:32 +0200 | <tomsmeding> | at the very least, liquid haskell has these things and calls them "refinement types" :) |
2024-09-21 12:07:08 +0200 | <ski> | given `data List a = Nil | Cons a (List a)', i'd say `data EvenList a <: List a = Nil | Cons a (OddList a)' and `data OddList a <: List a = Cons a (EvenList a)' are refinement types |
2024-09-21 12:07:25 +0200 | <ski> | you refine a variant/sum type, by removing alternatives, yielding a subtype |
2024-09-21 12:07:51 +0200 | <ski> | this was described in papers before LiquidHaskell existed |
2024-09-21 12:08:11 +0200 | <tomsmeding> | I see |
2024-09-21 12:08:11 +0200 | <Lears> | "Union types" need to be debunked so people will stop expecting them to be a thing. They don't even make sense. |
2024-09-21 12:08:15 +0200 | <tomsmeding> | difference in terminology, then |
2024-09-21 12:08:36 +0200 | <tomsmeding> | Lears: there are type systems that support them /shrug/ |
2024-09-21 12:08:36 +0200 | <ski> | (you can also refine a record/product type, by removing fields, yielding a supertype) |
2024-09-21 12:10:15 +0200 | <ski> | "Supertyping Suggestion for Haskell" by jmeacham (of jhc) at <http://repetae.net/recent/out/supertyping.html> is something similar, but for type classes |
2024-09-21 12:11:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-09-21 12:15:33 +0200 | spenat_ | spenat |
2024-09-21 12:16:30 +0200 | CiaoSen | (~Jura@2a05:5800:22d:f000:ca4b:d6ff:fec1:99da) (Ping timeout: 246 seconds) |
2024-09-21 12:17:18 +0200 | Guest4 | (~Guest4@cpc122096-bmly10-2-0-cust498.2-3.cable.virginm.net) |
2024-09-21 12:21:38 +0200 | connrs | (~connrs@user/connrs) (Ping timeout: 265 seconds) |
2024-09-21 12:22:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 12:22:54 +0200 | dolio | (~dolio@130.44.140.168) (Ping timeout: 260 seconds) |
2024-09-21 12:22:55 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) (Ping timeout: 264 seconds) |
2024-09-21 12:23:21 +0200 | connrs | (~connrs@user/connrs) |
2024-09-21 12:24:09 +0200 | dolio | (~dolio@130.44.140.168) |
2024-09-21 12:26:57 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
2024-09-21 12:34:33 +0200 | driib318 | (~driib@vmi931078.contaboserver.net) (Quit: The Lounge - https://thelounge.chat) |
2024-09-21 12:35:39 +0200 | driib318 | (~driib@176.57.184.141) |
2024-09-21 12:37:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
2024-09-21 12:38:53 +0200 | Guest4 | (~Guest4@cpc122096-bmly10-2-0-cust498.2-3.cable.virginm.net) (Quit: Client closed) |
2024-09-21 12:42:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-09-21 12:43:17 +0200 | gvg_ | gvg |