| 2026-06-30 00:08:31 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 00:15:09 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-30 00:26:37 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 00:28:00 +0000 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2026-06-30 00:30:44 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-30 00:36:50 +0000 | acidjnk_new | (~acidjnk@p200300d6e74def672da110570be53229.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2026-06-30 00:36:59 +0000 | acidjnk | (~acidjnk@p200300d6e74def672da110570be53229.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2026-06-30 00:41:55 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 00:46:53 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 268 seconds) |
| 2026-06-30 00:57:16 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:01:50 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 01:06:50 +0000 | xff0x | (~xff0x@2405:6580:b080:900:e4cf:554c:fb5:7866) (Ping timeout: 245 seconds) |
| 2026-06-30 01:08:26 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 01:10:58 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 276 seconds) |
| 2026-06-30 01:10:58 +0000 | polykernel_ | polykernel |
| 2026-06-30 01:12:38 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:16:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 01:26:43 +0000 | ft | (~ft@p3e9bc5ec.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2026-06-30 01:27:22 +0000 | Digit | (~user@user/digit) Digit |
| 2026-06-30 01:28:01 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:31:53 +0000 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2026-06-30 01:32:31 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2026-06-30 01:32:36 +0000 | absentia | (~henricus@user/absentia) absentia |
| 2026-06-30 01:32:57 +0000 | <absentia> | i appear to be struggling with haskell text parsing |
| 2026-06-30 01:33:07 +0000 | <absentia> | it's not much, 300k lines and 25MB of UTF8 |
| 2026-06-30 01:33:14 +0000 | jrm | (~jrm@user/jrm) jrm |
| 2026-06-30 01:33:23 +0000 | <absentia> | but it is stateful, i need to thread a cache through the parse, updated by each line |
| 2026-06-30 01:33:40 +0000 | <absentia> | attoparsec.text still chokes, takes several minutes |
| 2026-06-30 01:34:11 +0000 | <absentia> | accumulating into a vector for each line |
| 2026-06-30 01:35:11 +0000 | <jreicher> | Parsing is not stateful. |
| 2026-06-30 01:35:25 +0000 | <jreicher> | Sorry, I should say it's not side-effecting |
| 2026-06-30 01:35:36 +0000 | <jreicher> | You can write it with a state monad if you want |
| 2026-06-30 01:35:40 +0000 | <absentia> | jreicher: they're weechat logs |
| 2026-06-30 01:35:43 +0000 | <absentia> | i manually implemented a state monad |
| 2026-06-30 01:35:59 +0000 | <absentia> | the idea is when you see a PRIVMSG log line, you look up the hostname associated with that nick in a cache |
| 2026-06-30 01:36:02 +0000 | <jreicher> | You mean you didn't use the state monad supplied by Haskell? |
| 2026-06-30 01:36:06 +0000 | <absentia> | the cache is populated by earlier JOIN/PART/QUIT messages |
| 2026-06-30 01:36:19 +0000 | <absentia> | jreicher: so what do i do, do i stack StateT on top of Parser? |
| 2026-06-30 01:36:34 +0000 | <absentia> | some LLM actually advised not to do this, it will be slow |
| 2026-06-30 01:36:53 +0000 | <absentia> | instead my parser just returns (s, a) |
| 2026-06-30 01:36:53 +0000 | <jreicher> | Would you prefer something that's fast and broken, or slow and works? |
| 2026-06-30 01:36:56 +0000 | <mauke> | StateT Parser feels wrong |
| 2026-06-30 01:37:01 +0000 | <absentia> | it's already slow and works |
| 2026-06-30 01:37:03 +0000 | <absentia> | but thank you for presuming |
| 2026-06-30 01:37:11 +0000 | <jreicher> | Oh I thought you said it was broken |
| 2026-06-30 01:37:11 +0000 | <absentia> | my issue is i want it to be fast and working |
| 2026-06-30 01:37:13 +0000 | <EvanR> | when you are parsing and have a state, you have to decide when the state is reset if ever |
| 2026-06-30 01:37:17 +0000 | <absentia> | jreicher: where did i say that |
| 2026-06-30 01:37:17 +0000 | <mauke> | wouldn't that give you stateful construction of a (pure) parser? |
| 2026-06-30 01:37:22 +0000 | <absentia> | jreicher: maybe you should work on your reading comprehension |
| 2026-06-30 01:37:32 +0000 | <absentia> | jreicher: instead of projecting whatever wh*te nonsense you have going on up there |
| 2026-06-30 01:37:52 +0000 | <monochrom> | I think they mean StateT Foo Parser but they don't tell you what's Foo. |
| 2026-06-30 01:37:53 +0000 | <EvanR> | this is no longer serious! |
| 2026-06-30 01:38:00 +0000 | <mauke> | er, yes |
| 2026-06-30 01:38:03 +0000 | <jreicher> | absentia: it's what I thought you meant by "I appear to be struggling" and also "chokes". It's a simple misunderstanding, and you don't need to be so harsh about it. |
| 2026-06-30 01:38:10 +0000 | <mauke> | StateT s Parser |
| 2026-06-30 01:38:13 +0000 | <absentia> | anyway |
| 2026-06-30 01:38:22 +0000 | <absentia> | mauke: Parser does not instance MonadState or whatever |
| 2026-06-30 01:38:40 +0000 | <absentia> | attoparsec explicitly diverges from parsec and megaparsec in this way, supposedly for performance |
| 2026-06-30 01:38:51 +0000 | <mauke> | ?? |
| 2026-06-30 01:38:55 +0000 | <monochrom> | But crucially whether this is fast or slow depends on Foo, along with a hundred other "details" not revealed. |
| 2026-06-30 01:39:07 +0000 | <absentia> | https://hackage.haskell.org/package/attoparsec-0.14.4/docs/Data-Attoparsec-Internal-Types.html#t:P… |
| 2026-06-30 01:39:20 +0000 | <mauke> | my concern was the layering |
| 2026-06-30 01:39:26 +0000 | <absentia> | https://hackage.haskell.org/package/parsec-3.1.18.0/docs/Text-Parsec.html#t:ParsecT |
| 2026-06-30 01:39:34 +0000 | <mauke> | specifically StateT-around-Parser vs ParserT-around-State |
| 2026-06-30 01:39:37 +0000 | <absentia> | mauke: i'm saying, there is no other possible layering |
| 2026-06-30 01:39:40 +0000 | <monochrom> | But really the moment I saw "LLM said ..." I turned off. |
| 2026-06-30 01:39:52 +0000 | <absentia> | and the only possible layering is nonsensical for the reason you pointed out |
| 2026-06-30 01:40:09 +0000 | <absentia> | because there is no ParsecT in Attoparsec instancing MonadState |
| 2026-06-30 01:40:14 +0000 | <absentia> | there is in Parsec |
| 2026-06-30 01:40:41 +0000 | <absentia> | so actually what i have are s -> Parser (s, a) |
| 2026-06-30 01:40:42 +0000 | <mauke> | why do you keep talking about instances |
| 2026-06-30 01:40:47 +0000 | <monochrom> | The 3 times I took a look at what Google AI said, they were all wrong. In fact in one case, it said "X is true" where the very references it cited said "X is false". |
| 2026-06-30 01:40:49 +0000 | <absentia> | mauke: where do the stateful effects come from |
| 2026-06-30 01:41:02 +0000 | <absentia> | without a monad instance |
| 2026-06-30 01:41:30 +0000 | <mauke> | wait, now it's about Monad? |
| 2026-06-30 01:41:54 +0000 | <absentia> | the hell... all i'm saying is there is no MonadState instance for Attoparsec.Text.Parser |
| 2026-06-30 01:41:56 +0000 | <mauke> | I do assume there is a Monad instance, yes |
| 2026-06-30 01:42:02 +0000 | <mauke> | I don't care about MonadState |
| 2026-06-30 01:42:05 +0000 | <absentia> | therefore i thread my own state through |
| 2026-06-30 01:42:19 +0000 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2026-06-30 01:42:33 +0000 | <absentia> | i should really just profile it at this point |
| 2026-06-30 01:42:40 +0000 | <absentia> | instead of guessing |
| 2026-06-30 01:42:48 +0000 | <absentia> | but it's aggravating that something as simple as text parsing is so damn slow |
| 2026-06-30 01:42:52 +0000 | <mauke> | IIRC all MonadState gives you is the ability to write 'put x' instead of 'lift (put x)' |
| 2026-06-30 01:43:23 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:43:25 +0000 | <absentia> | mauke: so what is it that gives you the ability to lift |
| 2026-06-30 01:43:29 +0000 | ft | (~ft@p3e9bccb7.dip0.t-ipconnect.de) ft |
| 2026-06-30 01:43:31 +0000 | jrm | (~jrm@user/jrm) jrm |
| 2026-06-30 01:43:36 +0000 | <mauke> | monad transformer |
| 2026-06-30 01:43:41 +0000 | <absentia> | yeah. it doesn't instance that either. |
| 2026-06-30 01:43:48 +0000 | <absentia> | maybe that's closer to what i meant |
| 2026-06-30 01:44:13 +0000 | <EvanR> | there are ways to parse really fast, and break things |
| 2026-06-30 01:44:21 +0000 | <geekosaur> | if it claims to be ParsecT then it ought to be (that's what the trailing T by convention means) |
| 2026-06-30 01:44:32 +0000 | <absentia> | there is only ParsecT in Parsec |
| 2026-06-30 01:44:37 +0000 | <absentia> | there is no transformer in Attoparsec |
| 2026-06-30 01:44:40 +0000 | <absentia> | it only instances monad |
| 2026-06-30 01:44:47 +0000 | <absentia> | in fact monadplus and monadfail |
| 2026-06-30 01:44:58 +0000 | <geekosaur> | maybe that's the wrong way to go then. |
| 2026-06-30 01:45:21 +0000 | <absentia> | well attoparsec is allegedly "faster" without the ability to lift stateful computations |
| 2026-06-30 01:45:31 +0000 | <absentia> | but it still takes like 10 minutes to parse 25MB |
| 2026-06-30 01:45:40 +0000 | <geekosaur> | also if you want really fast you probably want flatparse, but the price you pay is inconvenience |
| 2026-06-30 01:45:51 +0000 | <absentia> | sometimes i wonder why i didn't write this in python or C or something |
| 2026-06-30 01:46:01 +0000 | <absentia> | it's just shocking to me because i've written minimax engines in haskell |
| 2026-06-30 01:46:08 +0000 | <absentia> | but it just absolutely shits the bed on plaintext processing |
| 2026-06-30 01:46:10 +0000 | <EvanR> | python, that blazing fast language |
| 2026-06-30 01:46:20 +0000 | <absentia> | yeah but do you think it would take 10 minutes to parse 25MB? |
| 2026-06-30 01:46:31 +0000 | <absentia> | i even tried the naive caveman approach |
| 2026-06-30 01:46:33 +0000 | <absentia> | T.splitOn |
| 2026-06-30 01:46:34 +0000 | <EvanR> | you sound like you don't know what you're doing honestly |
| 2026-06-30 01:46:35 +0000 | <absentia> | etc |
| 2026-06-30 01:46:43 +0000 | <geekosaur> | that sounds bad enough that I wonder if you're doing something really wrong |
| 2026-06-30 01:46:46 +0000 | <absentia> | should i just poste the goddamn code |
| 2026-06-30 01:47:02 +0000 | <mauke> | that usually helps :-) |
| 2026-06-30 01:47:07 +0000 | <EvanR> | messing up basic haskell fundamentals |
| 2026-06-30 01:47:13 +0000 | <mauke> | EvanR: ? |
| 2026-06-30 01:47:14 +0000 | <absentia> | https://bpa.st/V2MQ |
| 2026-06-30 01:47:26 +0000 | <EvanR> | in the old days that would cause an early exit for too much stack used |
| 2026-06-30 01:47:30 +0000 | <monochrom> | This is known as "information hiding". |
| 2026-06-30 01:47:33 +0000 | <absentia> | go and audit the code |
| 2026-06-30 01:47:37 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Remote host closed the connection) |
| 2026-06-30 01:47:40 +0000 | <absentia> | i seriously don't see why this should be non performant |
| 2026-06-30 01:47:54 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-30 01:48:11 +0000 | Digit | (~user@user/digit) (Remote host closed the connection) |
| 2026-06-30 01:48:41 +0000 | <absentia> | like you have to be fucking kidding me if this performs so poorly |
| 2026-06-30 01:48:52 +0000 | <absentia> | there aren't even any explicit lists |
| 2026-06-30 01:49:03 +0000 | <absentia> | yes Vector.snoc is O(n) but spatial locality and cache lines etc |
| 2026-06-30 01:49:19 +0000 | <absentia> | rather shit asymptotics than shotgun random accessing memory and cache missing all the time |
| 2026-06-30 01:49:21 +0000 | <monochrom> | Well that does it. |
| 2026-06-30 01:49:32 +0000 | <absentia> | monochrom: seen this talk by Stroustrup? |
| 2026-06-30 01:49:38 +0000 | <absentia> | https://www.youtube.com/watch?v=OB-bdWKwXsU&t=44m38s |
| 2026-06-30 01:49:39 +0000 | <monochrom> | No. |
| 2026-06-30 01:49:43 +0000 | <absentia> | he says caches beat asymptotics |
| 2026-06-30 01:49:45 +0000 | <absentia> | every time |
| 2026-06-30 01:49:59 +0000 | <absentia> | vectors >>> linked lists |
| 2026-06-30 01:50:00 +0000 | <monochrom> | Well he hasn't seen your example. |
| 2026-06-30 01:50:06 +0000 | <EvanR> | lol |
| 2026-06-30 01:50:10 +0000 | <absentia> | there must be something quite unique about GHC.... |
| 2026-06-30 01:50:17 +0000 | <monochrom> | Also he is not using immutable vectors. |
| 2026-06-30 01:50:21 +0000 | <EvanR> | are you thinking Vector is C++ vector |
| 2026-06-30 01:50:27 +0000 | <absentia> | is it the linalg vector |
| 2026-06-30 01:50:34 +0000 | <absentia> | what am i supposed to use then |
| 2026-06-30 01:50:37 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-06-30 01:50:38 +0000 | schuelermine | (~Thunderbi@user/schuelermine) (Ping timeout: 244 seconds) |
| 2026-06-30 01:50:58 +0000 | <EvanR> | some humility |
| 2026-06-30 01:51:11 +0000 | <absentia> | i think liberians love to project all their own flaws unto everyone else.... |
| 2026-06-30 01:51:22 +0000 | Digit | (~user@user/digit) Digit |
| 2026-06-30 01:51:35 +0000 | <absentia> | can you point out the "basic haskell fundamentals" that are obviously absent from my code EvanR |
| 2026-06-30 01:51:58 +0000 | <EvanR> | e.g. trying to do the equivalent of repeatedly appending an item to the end of a list |
| 2026-06-30 01:52:07 +0000 | <absentia> | i literally came out the gate with that |
| 2026-06-30 01:52:17 +0000 | <monochrom> | Stroustrup is working with, say, "after every 1000 snocs, move to a new location". But Haskell Vector's is after every 1 snoc, move to a new location. |
| 2026-06-30 01:52:17 +0000 | <absentia> | and acknowledged the poor asymptotics, but cited Stroustrup's pragmatics |
| 2026-06-30 01:52:27 +0000 | <absentia> | ok. let's try with plain lists |
| 2026-06-30 01:52:31 +0000 | <EvanR> | quadratic, sure |
| 2026-06-30 01:52:42 +0000 | <EvanR> | but you sounded surprised that it was slow |
| 2026-06-30 01:52:50 +0000 | <absentia> | because i also tried it with lists |
| 2026-06-30 01:52:52 +0000 | <absentia> | it was still pitiful |
| 2026-06-30 01:52:59 +0000 | <absentia> | something like 3000 lines a minute |
| 2026-06-30 01:53:05 +0000 | <absentia> | i am importing 21M |
| 2026-06-30 01:53:18 +0000 | <EvanR> | lists are pretty bad for a lot of things but now we're talking hypotheticals again |
| 2026-06-30 01:53:19 +0000 | <absentia> | then again it was not a controlled experiment |
| 2026-06-30 01:53:23 +0000 | <absentia> | i will try this exact code with lists |
| 2026-06-30 01:55:09 +0000 | <monochrom> | You should go back to C++. Because even when you attempt Haskell, you're just translating C++ to Haskell word by word. That is doomed to make slow programs. There are ways to write fast Haskell programs, but first you must not presume that C++ best practices become Haskell best practices. Some do, some others are the exact opposite. You have to start from scratch. Or just go back to the C++ comfort zone. |
| 2026-06-30 01:55:44 +0000 | <absentia> | why are liberians content to make assuming gender a hate crime |
| 2026-06-30 01:55:50 +0000 | <absentia> | but go on to assume all sorts of other intangible things about you |
| 2026-06-30 01:56:02 +0000 | <absentia> | i've written a naive bayesian filter in haskell |
| 2026-06-30 01:56:06 +0000 | <absentia> | half the functions are pointfree |
| 2026-06-30 01:56:20 +0000 | <absentia> | i've even written a chess engine in haskell |
| 2026-06-30 01:56:31 +0000 | <absentia> | it will go up to 4ply within 2 minutes on a $5 VPS |
| 2026-06-30 01:56:55 +0000 | <EvanR> | C++ in any language |
| 2026-06-30 01:57:03 +0000 | <EvanR> | just as bad as haskell in any language |
| 2026-06-30 01:57:23 +0000 | <jreicher> | Hmm. I would have thought all the takes in the do blocks would be OK... |
| 2026-06-30 01:59:51 +0000 | <monochrom> | Haskell's Vector snoc performs a relocation (really a copy --- the old version still exists) every time. You lose cache locality already. It never benefits from what Stroustrup hoped for. |
| 2026-06-30 02:00:01 +0000 | <absentia> | is this because of immutability |
| 2026-06-30 02:00:05 +0000 | <absentia> | is it literally a malloc per snoc |
| 2026-06-30 02:00:13 +0000 | <monochrom> | Yes and yes. |
| 2026-06-30 02:00:20 +0000 | <absentia> | maybe my friend's intuition was right after all... |
| 2026-06-30 02:00:25 +0000 | <absentia> | he was sniffing out excessive memory allocation |
| 2026-06-30 02:00:51 +0000 | <absentia> | hm |
| 2026-06-30 02:01:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:01:37 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-30 02:01:37 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-30 02:01:37 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 02:01:42 +0000 | <absentia> | accumulating into a list and then V.fromList'ing doesn't seem to yield much improvement either |
| 2026-06-30 02:01:55 +0000 | <absentia> | ok |
| 2026-06-30 02:01:59 +0000 | <monochrom> | Becasue xs ++ [x] is even worse. |
| 2026-06-30 02:02:01 +0000 | <absentia> | well maybe it only took two minutes that time |
| 2026-06-30 02:02:18 +0000 | <absentia> | i mean V.fromList after the final iteration |
| 2026-06-30 02:02:24 +0000 | <absentia> | or recursive call |
| 2026-06-30 02:02:52 +0000 | luke | (~luke@user/luke) (Remote host closed the connection) |
| 2026-06-30 02:03:06 +0000 | luke | (~luke@user/luke) luke |
| 2026-06-30 02:04:31 +0000 | <mauke> | ok, I've watched the stroustrup thing. he's talking about std::vector vs std::list |
| 2026-06-30 02:04:56 +0000 | <mauke> | i.e. a mutable, resizable (dynamic) array vs. a mutable, doubly-linked list |
| 2026-06-30 02:05:10 +0000 | <mauke> | neither of those map to haskell Vector and [] |
| 2026-06-30 02:06:01 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 248 seconds) |
| 2026-06-30 02:06:01 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-30 02:06:34 +0000 | <absentia> | well thanks for this then |
| 2026-06-30 02:06:35 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-06-30 02:06:41 +0000 | <absentia> | a list yields non-negligible improvement |
| 2026-06-30 02:07:24 +0000 | Digit | (~user@user/digit) (Ping timeout: 245 seconds) |
| 2026-06-30 02:08:53 +0000 | emilym | (~Thunderbi@user/emilym) emilym |
| 2026-06-30 02:09:14 +0000 | <absentia> | https://arxiv.org/abs/1808.08329 |
| 2026-06-30 02:09:17 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 02:09:22 +0000 | <absentia> | sensational paper headlines considered harmful |
| 2026-06-30 02:10:10 +0000 | <monochrom> | I use lazy lists all the time. But as loops, not data. |
| 2026-06-30 02:10:20 +0000 | <absentia> | [1..] is great sure |
| 2026-06-30 02:10:28 +0000 | <absentia> | i find lazy eval extremely difficult to reason about |
| 2026-06-30 02:10:33 +0000 | <monochrom> | Add line numbers: zip [1..] myLines |
| 2026-06-30 02:10:51 +0000 | <absentia> | in terms of performance |
| 2026-06-30 02:11:22 +0000 | <monochrom> | But everyone agrees that lists are terrible for data, lazy or not, Haskell or C. |
| 2026-06-30 02:12:00 +0000 | <mauke> | I don't! |
| 2026-06-30 02:12:10 +0000 | <monochrom> | The world is not a boolean question like "should you use lists or not". |
| 2026-06-30 02:12:57 +0000 | emilym | (~Thunderbi@user/emilym) (Ping timeout: 248 seconds) |
| 2026-06-30 02:13:08 +0000 | <mauke> | the snoc thing reminds me of Larry Wall's "Doing linear scans over an associatvie array is like clubbing someone to death with a loaded Uzi" |
| 2026-06-30 02:13:21 +0000 | <jreicher> | absentia: I believe the computation time of lazy should be no worse than strict. Only the memory use is a bit unpredictable. |
| 2026-06-30 02:14:29 +0000 | <jreicher> | So if you are seeing worse times, I don't think laziness is the reason. |
| 2026-06-30 02:15:24 +0000 | <absentia> | i should have just profiled this from the very beginning |
| 2026-06-30 02:15:24 +0000 | <mauke> | memory has a time all of its own |
| 2026-06-30 02:15:26 +0000 | <absentia> | and it would have been obvious |
| 2026-06-30 02:15:34 +0000 | <mauke> | particularly if your space leak runs into swap :-( |
| 2026-06-30 02:15:54 +0000 | <jreicher> | mauke: yeah, well, thrashing is completely its own thing. |
| 2026-06-30 02:16:47 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:16:52 +0000 | <jreicher> | absentia: why didn't you profile it earlier? Just curious |
| 2026-06-30 02:16:56 +0000 | <monochrom> | Well GC takes time too. And it shows up asymptotically too. If you use linear space, GC time is at least quadratic in total. |
| 2026-06-30 02:17:59 +0000 | <absentia> | jreicher: because i was fed up doing all this other auxiliary work just to get this parser going |
| 2026-06-30 02:18:16 +0000 | <absentia> | i already had to replatform the project on top of debian trixie because bullseye is being EOL'd, all packages out of date |
| 2026-06-30 02:18:19 +0000 | <absentia> | can't update stack resolver |
| 2026-06-30 02:18:29 +0000 | <absentia> | so ok, vacate the VPS, move the platform over, upgrade stack, upgrade libs |
| 2026-06-30 02:18:44 +0000 | <absentia> | then before i can write any code, now i have to set up a profiling harness and benchmark |
| 2026-06-30 02:18:50 +0000 | <absentia> | which probably means installing and setting up hspec |
| 2026-06-30 02:18:54 +0000 | <absentia> | and this just feels like an actual job now |
| 2026-06-30 02:19:02 +0000 | <absentia> | but it's just me being stubborn |
| 2026-06-30 02:19:08 +0000 | <absentia> | i knew from the get-go the first move is always to profile |
| 2026-06-30 02:19:15 +0000 | <absentia> | just wanted to fuck around i guess, idk |
| 2026-06-30 02:19:25 +0000 | <jreicher> | Only if performance is a requirement, and the runtime behaviour is opaque. |
| 2026-06-30 02:19:36 +0000 | <absentia> | based on the old numbers it would have taken 117 hours |
| 2026-06-30 02:19:39 +0000 | <absentia> | not really acceptable |
| 2026-06-30 02:20:00 +0000 | <jreicher> | I wouldn't expect to need a profiler for a simple assembler program, but I would (potentially) for an apparently simple SQL query. (For example) |
| 2026-06-30 02:20:11 +0000 | <monochrom> | I have my share of not even reading the error message. |
| 2026-06-30 02:20:20 +0000 | <jreicher> | Naughty boy |
| 2026-06-30 02:20:25 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 248 seconds) |
| 2026-06-30 02:20:33 +0000 | davidlbowman | (~davidlbow@user/davidlbowman) davidlbowman |
| 2026-06-30 02:20:39 +0000 | <jreicher> | ^boy^person. Very sorry |
| 2026-06-30 02:20:48 +0000 | <monochrom> | No worries. :) |
| 2026-06-30 02:21:36 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-06-30 02:26:09 +0000 | finsternis | (~X@23.226.237.192) (Remote host closed the connection) |
| 2026-06-30 02:26:23 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 02:28:22 +0000 | td_ | (~td@i53870922.versanet.de) (Ping timeout: 265 seconds) |
| 2026-06-30 02:29:45 +0000 | td_ | (~td@i53870912.versanet.de) |
| 2026-06-30 02:32:08 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:37:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-06-30 02:47:33 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:50:36 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 265 seconds) |
| 2026-06-30 02:51:50 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 02:56:53 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-30 02:56:53 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-30 02:56:53 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 03:02:53 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 03:07:21 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-30 03:26:45 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 03:30:06 +0000 | ft | (~ft@p3e9bccb7.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2026-06-30 03:33:38 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-30 03:41:54 +0000 | ft | (~ft@p3e9bc446.dip0.t-ipconnect.de) ft |
| 2026-06-30 03:44:43 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 03:49:00 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-30 04:00:03 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 04:04:29 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 04:10:04 +0000 | johna321 | (~johna321@c-76-110-10-66.hsd1.fl.comcast.net) |
| 2026-06-30 04:15:27 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 04:19:45 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 04:28:34 +0000 | machinedgod | (~machinedg@d108-173-95-19.abhsia.telus.net) (Ping timeout: 276 seconds) |
| 2026-06-30 04:46:10 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 04:50:57 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-06-30 04:57:24 +0000 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2026-06-30 04:59:14 +0000 | Axman6 | (~Axman6@user/axman6) Axman6 |
| 2026-06-30 05:01:32 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 05:08:27 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 252 seconds) |
| 2026-06-30 05:12:21 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 05:16:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-06-30 05:27:44 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 05:31:59 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-30 05:32:31 +0000 | johna321 | (~johna321@c-76-110-10-66.hsd1.fl.comcast.net) (Ping timeout: 265 seconds) |
| 2026-06-30 05:38:56 +0000 | divlamir | (~divlamir@user/divlamir) (Remote host closed the connection) |
| 2026-06-30 05:39:08 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-30 05:43:02 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 05:47:15 +0000 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2026-06-30 05:47:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-30 05:54:00 +0000 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli) |
| 2026-06-30 06:10:13 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Quit: peterbecich) |
| 2026-06-30 06:10:44 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-30 06:13:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 06:15:10 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 245 seconds) |
| 2026-06-30 06:17:40 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 06:26:47 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-30 06:26:47 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-30 06:26:47 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 06:28:41 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 06:35:27 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 261 seconds) |
| 2026-06-30 06:39:08 +0000 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2026-06-30 06:44:20 +0000 | czan | (~czan@user/mange) (Quit: Quittin' time!) |
| 2026-06-30 06:46:06 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 06:49:04 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 245 seconds) |
| 2026-06-30 06:52:57 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-30 06:53:43 +0000 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-06-30 07:02:31 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2026-06-30 07:10:08 +0000 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2026-06-30 07:11:36 +0000 | ft | (~ft@p3e9bc446.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2026-06-30 07:13:01 +0000 | ft | (~ft@p3e9bca38.dip0.t-ipconnect.de) ft |
| 2026-06-30 07:14:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 07:15:22 +0000 | rainbyte | (~rainbyte@181.47.219.31) (Remote host closed the connection) |
| 2026-06-30 07:15:41 +0000 | rainbyte | (~rainbyte@181.47.219.31) rainbyte |
| 2026-06-30 07:18:43 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-06-30 07:20:17 +0000 | michalz | (~michalz@185.246.207.193) |
| 2026-06-30 07:26:01 +0000 | tromp | (~textual@2001:1c00:340e:2700:39b7:4dd7:ef94:da89) |
| 2026-06-30 07:32:47 +0000 | tromp | (~textual@2001:1c00:340e:2700:39b7:4dd7:ef94:da89) (Read error: No route to host) |
| 2026-06-30 07:36:35 +0000 | jaror | (~jaror@user/jaror) (Quit: The Lounge - https://thelounge.chat) |
| 2026-06-30 07:37:00 +0000 | jaror | (~jaror@user/jaror) jaror |
| 2026-06-30 07:38:17 +0000 | schuelermine | (~Thunderbi@user/schuelermine) schuelermine |
| 2026-06-30 07:45:26 +0000 | chele | (~chele@user/chele) chele |
| 2026-06-30 07:51:14 +0000 | schuelermine | (~Thunderbi@user/schuelermine) (Ping timeout: 248 seconds) |
| 2026-06-30 07:51:52 +0000 | schuelermine | (~Thunderbi@user/schuelermine) schuelermine |
| 2026-06-30 07:58:00 +0000 | fp | (~Thunderbi@130.233.70.229) fp |
| 2026-06-30 07:58:42 +0000 | schuelermine | (~Thunderbi@user/schuelermine) (Ping timeout: 256 seconds) |
| 2026-06-30 08:04:57 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 08:09:31 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 08:12:44 +0000 | terrorjack | (~terrorjac@2a01:4f8:271:2d98::2) (Quit: The Lounge - https://thelounge.chat) |
| 2026-06-30 08:16:51 +0000 | terrorjack | (~terrorjac@2a01:4f8:271:2d98::2) terrorjack |
| 2026-06-30 08:23:40 +0000 | ft | (~ft@p3e9bca38.dip0.t-ipconnect.de) (Quit: leaving) |
| 2026-06-30 08:34:42 +0000 | CiaoSen | (~Jura@2a02:3100:661d:600:4e50:ddff:fe9b:8922) CiaoSen |
| 2026-06-30 08:36:54 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2026-06-30 08:40:52 +0000 | jaror6 | (~jaror@user/jaror) jaror |
| 2026-06-30 08:42:32 +0000 | jaror | (~jaror@user/jaror) (Ping timeout: 262 seconds) |
| 2026-06-30 08:42:32 +0000 | jaror6 | jaror |
| 2026-06-30 08:42:45 +0000 | Ranhir | (~Ranhir@157.97.53.139) (Ping timeout: 272 seconds) |
| 2026-06-30 08:45:34 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 08:46:41 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 08:47:22 +0000 | Ranhir | (~Ranhir@157.97.53.139) Ranhir |
| 2026-06-30 08:49:10 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 08:50:37 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 08:53:16 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2026-06-30 08:54:08 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 08:55:11 +0000 | CiaoSen | (~Jura@2a02:3100:661d:600:4e50:ddff:fe9b:8922) (Ping timeout: 252 seconds) |
| 2026-06-30 08:57:43 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 08:58:21 +0000 | fp | (~Thunderbi@130.233.70.229) (Ping timeout: 252 seconds) |
| 2026-06-30 09:01:51 +0000 | acidjnk_new | (~acidjnk@p200300d6e74def67cefedba3bc5cab81.dip0.t-ipconnect.de) |
| 2026-06-30 09:02:01 +0000 | acidjnk | (~acidjnk@p200300d6e74def67cefedba3bc5cab81.dip0.t-ipconnect.de) acidjnk |
| 2026-06-30 09:03:01 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 09:05:07 +0000 | danza | (~danza@user/danza) danza |
| 2026-06-30 09:08:26 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 09:21:07 +0000 | fp | (~Thunderbi@130.233.70.229) fp |
| 2026-06-30 09:32:17 +0000 | <probie> | monochrom: Are lists always bad for data? A single list is bad, but if you have many (singly-linked) lists and a lot of sharing going on I'm not willing to immediately write it off as "bad" |
| 2026-06-30 09:42:39 +0000 | karenw | (~karenw@user/karenw) karenw |
| 2026-06-30 09:46:03 +0000 | Digit | (~user@user/digit) Digit |
| 2026-06-30 09:46:45 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2026-06-30 09:47:19 +0000 | jreicher | (~joelr@user/jreicher) (Killed (manganese.libera.chat (Nickname regained by services))) |
| 2026-06-30 09:47:50 +0000 | jreicher | (~joelr@user/jreicher) jreicher |
| 2026-06-30 09:48:21 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 09:52:18 +0000 | Digit | digitteknohippie |
| 2026-06-30 09:52:18 +0000 | digitteknohippie | (~user@user/digit) (Remote host closed the connection) |
| 2026-06-30 09:55:50 +0000 | Digit | (~user@user/digit) Digit |
| 2026-06-30 10:03:30 +0000 | Digit | (~user@user/digit) (Ping timeout: 248 seconds) |
| 2026-06-30 10:04:13 +0000 | fp2 | (~Thunderbi@130.233.70.229) fp |
| 2026-06-30 10:04:26 +0000 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-06-30 10:04:39 +0000 | fp | (~Thunderbi@130.233.70.229) (Read error: Connection reset by peer) |
| 2026-06-30 10:04:39 +0000 | fp2 | fp |
| 2026-06-30 10:08:32 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:10:21 +0000 | kuribas | (~user@2a02-1810-2825-6000-bae0-9ec9-ef49-8ccc.ip6.access.telenet.be) |
| 2026-06-30 10:10:53 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 10:12:25 +0000 | Digitteknohippie | (~user@user/digit) Digit |
| 2026-06-30 10:16:48 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 246 seconds) |
| 2026-06-30 10:16:51 +0000 | Digitteknohippie | Digit |
| 2026-06-30 10:22:36 +0000 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
| 2026-06-30 10:23:00 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2026-06-30 10:25:40 +0000 | poscat | (~poscat@user/poscat) poscat |
| 2026-06-30 10:27:32 +0000 | <tomsmeding> | that sounds like a tree :p |
| 2026-06-30 10:27:47 +0000 | <tomsmeding> | I guess an inverted tree |
| 2026-06-30 10:30:45 +0000 | emmanuelux_ | (~em@168.104.204.77.rev.sfr.net) |
| 2026-06-30 10:31:42 +0000 | emmanuelux | (~em@user/emmanuelux) (Ping timeout: 256 seconds) |
| 2026-06-30 10:31:52 +0000 | <fp> | When one says that some T :: * -> * is Co/Contra/Invariant over a -> b, what is "varying"? I understand that it means you can turn a -> b into T a -> T b or T b -> T a or not, but to me that follows only from the Co/Contra/In, not the variant |
| 2026-06-30 10:36:56 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:37:26 +0000 | <fp> | Like I'm familiar with invariance in the sense of like a physical energy system where it's behavior is invariant wrt the total energy of the system, i.e. no energy is lost or destroyed regardless of the evolution of the system. So you can understand the invariance as "the total energy can't vary" |
| 2026-06-30 10:41:08 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Read error: Connection reset by peer) |
| 2026-06-30 10:41:32 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:44:12 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 10:45:33 +0000 | <tomsmeding> | fp: I think there are two different notions of co(ntra)variant here: one is that of a co(ntra) variant functor, and the other is that of co(ntra)variance in type systems |
| 2026-06-30 10:46:00 +0000 | <tomsmeding> | a covariant functor has fmap : (a -> b) -> T a -> T b; a contravariant functor has fmap : (a -> b) -> T b -> T a |
| 2026-06-30 10:46:17 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:46:49 +0000 | <tomsmeding> | co(ntra)variance in type systems relates to subtyping, where the idea is that a subtype A' of A is to be accepted wherever A is |
| 2026-06-30 10:47:20 +0000 | <tomsmeding> | but then if you think about it, B -> A' should be a subtype of B -> A, but A -> B should be a subtype of A' -> B |
| 2026-06-30 10:47:29 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 10:47:45 +0000 | <tomsmeding> | because whenever B -> A works, getting a more precise A out (i.e. an A') would be acceptable |
| 2026-06-30 10:48:25 +0000 | <tomsmeding> | but if you're expecting a function A' -> B, then a function A -> B also works, as passing an A' to that is fine by subtyping |
| 2026-06-30 10:49:23 +0000 | <fp> | Mm I see |
| 2026-06-30 10:49:25 +0000 | <tomsmeding> | hence 'a -> b' is said to be covariant in b (because b' <= b ==> a -> b' <= a -> b), and contravariant in a (because a' <= a ==> a -> b <= a' -> b) |
| 2026-06-30 10:49:52 +0000 | <tomsmeding> | with the type systems one, the thing that varies is the specificity along the subtyping relation ("making something more 'sub'") |
| 2026-06-30 10:50:16 +0000 | <tomsmeding> | with the category theory one, the thing that "varies" is the direction of movement along the arrow, I guess? I'm not a category theorist |
| 2026-06-30 10:50:45 +0000 | <fp> | Ok interesting thank you |
| 2026-06-30 10:51:40 +0000 | <fp> | I'v fallen down a bit of a rabbit hole of people talking about wacky algebras and type-level programming, and stuff like this comes up |
| 2026-06-30 10:52:12 +0000 | <tomsmeding> | you can see the subtyping version in Haskell too, even though Haskell does not, by the usual terminology, have subtyping: polymorphism has similar behaviour |
| 2026-06-30 10:52:34 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 10:53:00 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:53:21 +0000 | <tomsmeding> | Int <= (forall a. Num a => a) [here '<=' is "more specific"], hence (Bool -> Int) <= (Bool -> forall a. Num a => a) = (forall a. Num a => Bool -> a) |
| 2026-06-30 10:53:49 +0000 | <tomsmeding> | but ((forall a. Num a => a) -> Bool) <= (Int -> Bool) |
| 2026-06-30 10:54:51 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 10:55:12 +0000 | <tomsmeding> | there are fewer Ints than "arbitrary Num values", but if you have to _take_ an arbitrary Num value, there's less you can do than if you know you're getting an Int |
| 2026-06-30 10:57:19 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:57:48 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2026-06-30 10:59:24 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 11:00:25 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 11:02:17 +0000 | fun-safe-math | (~fun-safe-@97-120-35-225.ptld.qwest.net) () |
| 2026-06-30 11:02:45 +0000 | <fp> | does `forall a. Num a` mean that a single monomorphization of a function will polymorphically accept any Num a => a ? |
| 2026-06-30 11:04:05 +0000 | tremon | (~tremon@83-80-159-219.cable.dynamic.v4.ziggo.nl) tremon |
| 2026-06-30 11:04:12 +0000 | fun-safe-math | (~fun-safe-@97-120-35-225.ptld.qwest.net) fun-safe-math |
| 2026-06-30 11:06:39 +0000 | <tomsmeding> | fp: "a function" -- which function? It matters on which side the forall stands :) |
| 2026-06-30 11:07:51 +0000 | <fp> | Mm, then could it be `f :: forall a. Num a => a -> Bool` is what I said and `g:: forall a. Num a => Bool -> a` is type erasure? |
| 2026-06-30 11:08:26 +0000 | <tomsmeding> | those two functions are just the other way round, I'm not sure where type erasure comes in |
| 2026-06-30 11:09:07 +0000 | <tomsmeding> | I'm not sure where your thoughts are / where you're stuck (if you are), but in case you're not familiar with that view, you can see "forall" as just another argument |
| 2026-06-30 11:09:27 +0000 | <fp> | I guess in my head, forall is a thing that creates dynamic dispatch on the backend |
| 2026-06-30 11:09:32 +0000 | <tomsmeding> | f :: forall a. Num a => Bool -> a takes 3 arguments: a type 'a', a dictionary 'Num a', and a 'Bool' |
| 2026-06-30 11:10:03 +0000 | <tomsmeding> | as such (f1 :: forall a. Num a => a -> Bool) and (f2 :: (forall a. Num a => a) -> Bool) are very different: f1 takes 3 arguments, f2 takes 1 |
| 2026-06-30 11:10:43 +0000 | <fp> | You know, there's probably a manual page I should read about this |
| 2026-06-30 11:10:43 +0000 | <tomsmeding> | on the other hand, (g1 :: forall a. Num a => Bool -> a) and (g2 :: Bool -> (forall a. Num a => a)) are the same up to argument ordering: they both take 3 arguments, just in a different order |
| 2026-06-30 11:11:26 +0000 | <tomsmeding> | now, when you actually want to execute this stuff and be fast-ish, you indeed start thinking about dynamic dispatch and polymorphic code and stuff |
| 2026-06-30 11:11:51 +0000 | <tomsmeding> | but when thinking about meaning and behaviour in the type system, I think this perspective is much more precise |
| 2026-06-30 11:17:58 +0000 | <tomsmeding> | fp: re manual, I don't think the GHC manual explains any of this since it generally assumes you know the underlying theory |
| 2026-06-30 11:18:11 +0000 | xff0x | (~xff0x@2405:6580:b080:900:f8e0:a6ee:fc93:d765) |
| 2026-06-30 11:18:33 +0000 | <tomsmeding> | there may well be resources that explain this in more detail for haskell specifically, but I don't know them |
| 2026-06-30 11:19:21 +0000 | <tomsmeding> | oh I guess this is just system F |
| 2026-06-30 11:19:25 +0000 | <tomsmeding> | https://en.wikipedia.org/wiki/System_F |
| 2026-06-30 11:20:07 +0000 | <tomsmeding> | both simply typed lambda calculus and dependently-typed calculi (type theory) have much theory and literature devoted to them; system F and Haskell are a bit in the middle |
| 2026-06-30 11:20:40 +0000 | <tomsmeding> | and the terminology when you read about this stuff tends to assume some knowledge about basic type theory |
| 2026-06-30 11:21:02 +0000 | <fp> | Interesting, I'll have to read |
| 2026-06-30 11:39:19 +0000 | <gentauro> | tomsmeding: -> https://sdiehl.github.io/typechecker-zoo/system-f-omega/system-f-omega.html ;) |
| 2026-06-30 11:39:55 +0000 | <tomsmeding> | > System Fω stands as one of the most type systems in the theoretical foundations of programming languages |
| 2026-06-30 11:40:15 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 11:40:51 +0000 | <tomsmeding> | now I want to know the most _what_ type system System Fω is lol |
| 2026-06-30 11:42:34 +0000 | <tomsmeding> | fp: ^ another resource |
| 2026-06-30 11:42:57 +0000 | <tomsmeding> | depending on how deep you want to dive into this :p |
| 2026-06-30 11:43:25 +0000 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-06-30 11:44:09 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 11:55:01 +0000 | lynxx_ | (~lynxx_@2001:9e8:3bcd:2200:997c:8365:c7f6:f178) |
| 2026-06-30 11:55:35 +0000 | fgarcia | (~lei@user/fgarcia) (Ping timeout: 252 seconds) |
| 2026-06-30 11:57:45 +0000 | fgarcia | (~lei@user/fgarcia) fgarcia |
| 2026-06-30 12:08:06 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 12:08:49 +0000 | <jreicher> | Coincidentally I've just been looking at his Prism language today. |
| 2026-06-30 12:10:56 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 12:13:25 +0000 | <__monty__> | tomsmeding: Just read, system Fω is the most type. |
| 2026-06-30 12:14:37 +0000 | danza | (~danza@user/danza) (Read error: Connection reset by peer) |
| 2026-06-30 12:14:40 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 12:19:31 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 264 seconds) |
| 2026-06-30 12:24:51 +0000 | haritz | (~hrtz@140.228.70.141) |
| 2026-06-30 12:24:52 +0000 | haritz | (~hrtz@140.228.70.141) (Changing host) |
| 2026-06-30 12:24:52 +0000 | haritz | (~hrtz@user/haritz) haritz |
| 2026-06-30 12:28:27 +0000 | potatoes_ | (~quassel@130.44.145.181) (Ping timeout: 252 seconds) |
| 2026-06-30 12:34:17 +0000 | lynxx_ | (~lynxx_@2001:9e8:3bcd:2200:997c:8365:c7f6:f178) (Ping timeout: 248 seconds) |
| 2026-06-30 12:34:36 +0000 | lynxx | (~lynxx_@2001:9e8:3bcd:2200:997c:8365:c7f6:f178) |
| 2026-06-30 12:55:04 +0000 | Alex_delenda_est | (~al_test@178.34.151.183) (Quit: ;-) |
| 2026-06-30 12:55:33 +0000 | AlexZenon | (~alzenon@178.34.151.183) (Quit: ;-) |
| 2026-06-30 12:55:35 +0000 | lynxx | (~lynxx_@2001:9e8:3bcd:2200:997c:8365:c7f6:f178) (Quit: lynxx) |
| 2026-06-30 12:55:48 +0000 | AlexNoo | (~AlexNoo@178.34.151.183) (Quit: Leaving) |
| 2026-06-30 12:56:03 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 13:00:36 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2026-06-30 13:04:19 +0000 | lynxx | (~lynxx@i59F6675C.versanet.de) |
| 2026-06-30 13:06:56 +0000 | AlexNoo | (~AlexNoo@178.34.151.183) |
| 2026-06-30 13:11:14 +0000 | AlexNoo | (~AlexNoo@178.34.151.183) (Ping timeout: 248 seconds) |
| 2026-06-30 13:11:56 +0000 | AlexNoo | (~AlexNoo@178.34.151.183) |
| 2026-06-30 13:12:56 +0000 | AlexNoo_ | (~AlexNoo@178.34.151.183) |
| 2026-06-30 13:13:01 +0000 | AlexZenon | (~alzenon@178.34.151.183) |
| 2026-06-30 13:13:40 +0000 | AlexNoo__ | (~AlexNoo@178.34.151.183) |
| 2026-06-30 13:13:54 +0000 | lynxx6 | (~lynxx@i59F6675C.versanet.de) |
| 2026-06-30 13:15:52 +0000 | <tomsmeding> | __monty__: clearly! |
| 2026-06-30 13:16:34 +0000 | AlexNoo | (~AlexNoo@178.34.151.183) (Ping timeout: 248 seconds) |
| 2026-06-30 13:16:34 +0000 | lynxx | (~lynxx@i59F6675C.versanet.de) (Ping timeout: 248 seconds) |
| 2026-06-30 13:16:34 +0000 | lynxx6 | lynxx |
| 2026-06-30 13:17:06 +0000 | AlexNoo_ | (~AlexNoo@178.34.151.183) (Ping timeout: 248 seconds) |
| 2026-06-30 13:18:10 +0000 | AlexNoo__ | (~AlexNoo@178.34.151.183) (Ping timeout: 248 seconds) |