IRCBrowse

2025/01/20

2025-01-20 00:01:56 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-20 00:05:10 +0100ftzm(~ftzm@085081033150.dynamic.telenor.dk) (Ping timeout: 252 seconds)
2025-01-20 00:07:19 +0100xff0x_(~xff0x@2405:6580:b080:900:1e1c:692f:68bb:bafe) (Ping timeout: 264 seconds)
2025-01-20 00:12:28 +0100ftzm(~ftzm@085081061247.dynamic.telenor.dk) ftzm
2025-01-20 00:12:59 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 00:15:29 +0100Everything(~Everythin@195.138.86.118) (Quit: Lost terminal)
2025-01-20 00:17:48 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2025-01-20 00:28:09 +0100taleseeker(~taleseeke@185.107.44.16) (Quit: irc: cannot access '/proc/taleseeker': No such file or directory)
2025-01-20 00:28:22 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 00:30:24 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-01-20 00:32:39 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2025-01-20 00:42:40 +0100taleseeker(~taleseeke@185.107.44.16)
2025-01-20 00:42:47 +0100caconym(~caconym@user/caconym) (Quit: bye)
2025-01-20 00:43:01 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2025-01-20 00:43:47 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 00:44:14 +0100caconym(~caconym@user/caconym) caconym
2025-01-20 00:50:23 +0100sawilagar(~sawilagar@user/sawilagar) (Ping timeout: 245 seconds)
2025-01-20 00:50:39 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2025-01-20 01:01:50 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 01:06:02 +0100xff0x(~xff0x@2405:6580:b080:900:2483:168a:41f:3286)
2025-01-20 01:06:24 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-20 01:09:44 +0100rvalue(~rvalue@user/rvalue) (Ping timeout: 260 seconds)
2025-01-20 01:11:54 +0100rvalue(~rvalue@user/rvalue) rvalue
2025-01-20 01:17:12 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 01:22:05 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2025-01-20 01:22:52 +0100ystael(~ystael@user/ystael) ystael
2025-01-20 01:24:03 +0100Midjak(~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep)
2025-01-20 01:32:34 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 01:34:10 +0100dsrt^(~dsrt@108.192.66.114) (Remote host closed the connection)
2025-01-20 01:34:16 +0100dnerdhm^(~dnerdhm@108.192.66.114) (Remote host closed the connection)
2025-01-20 01:37:03 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2025-01-20 01:39:02 +0100euleritian(~euleritia@77.23.250.232) (Read error: Connection reset by peer)
2025-01-20 01:39:27 +0100euleritian(~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de)
2025-01-20 01:46:23 +0100 <albet70> bind Cont Monad is CPS?
2025-01-20 01:46:29 +0100 <albet70> Cont Monad contain CPS compute, use bind to chain Cont Monad, is this still CPS?
2025-01-20 01:47:56 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 01:48:00 +0100dtman34(~dtman34@c-75-72-179-251.hsd1.mn.comcast.net) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in)
2025-01-20 01:48:21 +0100dtman34(~dtman34@c-75-72-179-251.hsd1.mn.comcast.net) dtman34
2025-01-20 01:49:08 +0100acidjnk(~acidjnk@p200300d6e7283f1558eeea12d8956a76.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
2025-01-20 01:52:32 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2025-01-20 01:53:33 +0100sprotte24(~sprotte24@p200300d16f4f2e00b0312921636c686d.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2025-01-20 01:57:43 +0100xff0x(~xff0x@2405:6580:b080:900:2483:168a:41f:3286) (Ping timeout: 264 seconds)
2025-01-20 02:03:19 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 02:05:26 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2025-01-20 02:06:06 +0100stiell(~stiell@gateway/tor-sasl/stiell) stiell
2025-01-20 02:06:33 +0100 <haskellbridge> <Bowuigi> I think so, yeah. It kinda composes two CPS programs
2025-01-20 02:08:03 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds)
2025-01-20 02:08:31 +0100 <albet70> what's the point to write two CPS and use bind to chain them rather than just write one CPS
2025-01-20 02:10:27 +0100 <haskellbridge> <Bowuigi> Separation of concerns
2025-01-20 02:11:15 +0100anpad(~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in)
2025-01-20 02:13:27 +0100 <jle`> albet70: "composable CPS programs" essentially
2025-01-20 02:13:39 +0100 <jle`> same as the point of writing two lists to concat them together instead of writing one long list
2025-01-20 02:14:12 +0100 <jle`> or two IO actions and sequence them one after the other instead of writing one big IO action
2025-01-20 02:16:05 +0100 <jle`> but yeah, consider the function (++) :: [a] -> [a] -> [a] to concat two lists (or strings) together, and someone asks you "why would you ever concat two lists together instead of just writing one big list"
2025-01-20 02:17:00 +0100 <albet70> can CPS do early return from a nested function call? like f (g (a ...))) turn to CPS, can return from a to f directly? like return only return the previous function caller, can it return to the original caller at once?
2025-01-20 02:18:41 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 02:22:24 +0100homo(~homo@user/homo) (Read error: Connection reset by peer)
2025-01-20 02:25:02 +0100 <c_wraith> with CPS, there aren't nested function calls
2025-01-20 02:26:05 +0100 <c_wraith> at least when you go *full* CPS, functions never return.
2025-01-20 02:26:26 +0100 <c_wraith> They take an argument for what to do next - the continuation
2025-01-20 02:26:54 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-20 02:27:53 +0100 <albet70> but runCont still need a k to get its result
2025-01-20 02:28:27 +0100 <c_wraith> it's not full CPS - it's bounded in scope.
2025-01-20 02:28:48 +0100 <c_wraith> runCont is the adapter
2025-01-20 02:29:38 +0100otto_s(~user@p4ff277d7.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2025-01-20 02:29:45 +0100 <c_wraith> (also, you still have access to all regular functions inside of Cont. they aren't CPS'd)
2025-01-20 02:30:37 +0100 <geekosaur> not by Cont, at least. (doesn't GHC do full CPS?)
2025-01-20 02:31:25 +0100otto_s(~user@p5b044ca8.dip0.t-ipconnect.de)
2025-01-20 02:34:25 +0100 <int-e> as an invisible implementation detail of graph reduction
2025-01-20 02:36:39 +0100Raito_Bezarius(~Raito@wireguard/tunneler/raito-bezarius) (Ping timeout: 276 seconds)
2025-01-20 02:37:12 +0100Raito_Bezarius(~Raito@wireguard/tunneler/raito-bezarius) Raito_Bezarius
2025-01-20 02:37:43 +0100 <albet70> so Cont is not CPS?
2025-01-20 02:38:17 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 02:38:18 +0100 <int-e> it is
2025-01-20 02:38:32 +0100 <int-e> it lives at a different level of abstraction
2025-01-20 02:39:02 +0100 <monochrom> Does this make sense? Cont does CPS so you don't have to. >:)
2025-01-20 02:39:27 +0100 <monochrom> But then since you don't have to, it's not CPS from your POV.
2025-01-20 02:40:39 +0100 <albet70> it's confused
2025-01-20 02:40:46 +0100 <monochrom> Analogously, GHC compiles my Haskell code to asm. So is Haskell asm? Of course not. But then why does GHC do asm? Doesn't that make Haskell asm?
2025-01-20 02:40:52 +0100 <int-e> :t cont (const ()) -- I guess you can quibble about this and how Codensity is the real CPS
2025-01-20 02:40:53 +0100 <lambdabot> Cont () a
2025-01-20 02:41:17 +0100 <probie> What precisely do you guys mean when you say "CPS"?
2025-01-20 02:41:27 +0100 <int-e> continuation passing style
2025-01-20 02:41:42 +0100 <probie> ...
2025-01-20 02:41:46 +0100 <int-e> where rather than returning a value, you pass it to a continuation
2025-01-20 02:42:07 +0100 <probie> What precisely do you guys means when you say "continuation passing style"?
2025-01-20 02:42:09 +0100 <monochrom> https://www.vex.net/~trebla/haskell/cont.xhtml#cps Does that answer your question?
2025-01-20 02:42:21 +0100 <int-e> probie: It's not precise. That's where I was going.
2025-01-20 02:42:37 +0100 <probie> monochrom: Not really, it gives me a definition that may not match what you are actually talking about
2025-01-20 02:42:50 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-20 02:42:50 +0100 <monochrom> Yeah it's like "I write FP, I write OOP", it's supposed to have grey areas.
2025-01-20 02:43:11 +0100 <monochrom> OK but I wrote that for Cont so it is actually.
2025-01-20 02:43:23 +0100 <int-e> Cont or Codensity express a particular flavor of CPS where every function gets passed exactly one continuation.
2025-01-20 02:43:33 +0100alx741(~alx741@186.33.188.229) (Ping timeout: 246 seconds)
2025-01-20 02:44:48 +0100 <int-e> GHC's CPS is that it doesn't maintain a call stack but instead passes continuations (pointers to code to jump to after loading a result in a register) around.
2025-01-20 02:44:54 +0100poscat(~poscat@user/poscat) (Quit: Bye)
2025-01-20 02:45:05 +0100 <int-e> They're both CPS and they're not the same.
2025-01-20 02:46:02 +0100 <int-e> Cont/Codensity give you Haskell-level access to continuations. GHC's are, as already mentioned, an implementation detail. One you'll probably only care about if you stare at CMM code or disassemblies.
2025-01-20 02:46:05 +0100 <probie> and yet I think albet70 has a specific meaning of CPS in mind which it seems no-one is attempting to discern so that their questions can be answered
2025-01-20 02:46:40 +0100 <monochrom> Sure. You can try to discern. Good luck with that. (Speaking from experience.)
2025-01-20 02:47:09 +0100 <monochrom> Askers should learn to clarify their questions, not be spoiled and expect answerers to guess.
2025-01-20 02:47:12 +0100 <albet70> no, I don't have, I just confused
2025-01-20 02:47:21 +0100 <int-e> probie: /I/ think we have affirmed that Cont is CPS before muddying the water by bringing up all the other stuff :P
2025-01-20 02:47:28 +0100 <albet70> someone say this is , others say this isn't
2025-01-20 02:48:09 +0100poscat(~poscat@user/poscat) poscat
2025-01-20 02:48:19 +0100 <int-e> The sophistery of Cont vs. Codensity is that with Cont you can discard a continuation and just inject a result.
2025-01-20 02:48:25 +0100 <probie> int-e: I'm not even happy with that. `Cont` is not CPS. `pure $ f (g (h a)) :: Cont r a` is not in continuation passing style.
2025-01-20 02:48:43 +0100anpad(~pandeyan@user/anpad) anpad
2025-01-20 02:48:44 +0100 <int-e> probie: that's okay and anticipated
2025-01-20 02:49:00 +0100 <int-e> but personally I don't find that distinction useful
2025-01-20 02:49:05 +0100 <monochrom> <monochrom> Does this make sense? Cont does CPS so you don't have to. >:) <monochrom> But then since you don't have to, it's not CPS from your POV.
2025-01-20 02:49:46 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2025-01-20 02:50:15 +0100 <int-e> Cont is a viable answer to "I want to write CPS code, what do I use" in the single-continuation setting.
2025-01-20 02:50:40 +0100Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2025-01-20 02:50:46 +0100 <int-e> Codensity solves a problem that you won't run into if that's your premise.
2025-01-20 02:50:51 +0100 <monochrom> Instead of making "CPS" precise, I think what we lack is chosing the level of abstraction in the first place.
2025-01-20 02:50:58 +0100anpad(~pandeyan@user/anpad) (Client Quit)
2025-01-20 02:51:15 +0100 <int-e> It's an operational notion, those tend to be inherently imprecise :P
2025-01-20 02:51:32 +0100 <int-e> embrace the ambiguity
2025-01-20 02:51:34 +0100 <int-e> love the bomb
2025-01-20 02:51:56 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 02:52:35 +0100 <int-e> probie: anyway, feel free to make things precise
2025-01-20 02:54:13 +0100 <monochrom> One more analogy/fable and I'll stop, I promise. >:)
2025-01-20 02:54:15 +0100 <albet70> can we do early return from nested function call by CPS or callcc without Cont Monad?
2025-01-20 02:54:21 +0100 <albet70> just function level
2025-01-20 02:55:35 +0100 <c_wraith> everything Cont does is just functions
2025-01-20 02:56:02 +0100 <monochrom> Suppose your prof gives you this homework: Write factorial in CPS. You're too lazy to hand-convert to CPS, so you give direct-style factorial code to chatgpt and tell it to CPSize for you. Let's say it even does it correctly. Is it CPS? Surely you didn't write it yourself, so it isn't? But you have a correct solution to hand in, so it is?
2025-01-20 02:56:21 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-20 02:56:21 +0100 <monochrom> Right now chatgpt can't do it correctly, but Cont can!
2025-01-20 02:56:34 +0100 <c_wraith> If you want early return, the trick is to not nest functions. Using CPS (by hand or by Cont) can remove that nesting, when done properly
2025-01-20 02:57:35 +0100 <int-e> > runCont (callCC (\cont -> cont 41 >> undefined) >>= pure . succ) id
2025-01-20 02:57:37 +0100 <lambdabot> 42
2025-01-20 02:58:06 +0100 <int-e> Is that an "early return"? What's a "return" if you're looking at Cont-specific monadic code?
2025-01-20 02:59:14 +0100 <int-e> (note the `undefined` action that is never executed)
2025-01-20 02:59:51 +0100anpad(~pandeyan@user/anpad) anpad
2025-01-20 03:01:05 +0100 <int-e> This is why I'm reluctant to just say "yes" - there is a form of early return here, but you're writing your code in a very peculiar style. It's a shallow abstraction.
2025-01-20 03:02:26 +0100 <probie> > let f acc l = case l of { x:xs | x <= 10 -> f (x + acc) xs; _ -> acc } in f 0 [4,6,8,9,12,3,2] -- does this count as an early return?
2025-01-20 03:02:27 +0100 <lambdabot> 27
2025-01-20 03:03:07 +0100 <int-e> You don't even need the Cont monad to achieve and of this; you can manually change your code to return `(a -> r) -> r` instead of `a`, gain the capability to pass multiple continuations without the awkward `callCC`, and have more readable code because it's not monadic.
2025-01-20 03:04:06 +0100 <int-e> And get the same capability of an early return, relying on Haskell's tail recursion elimination.
2025-01-20 03:04:09 +0100int-eshrugs
2025-01-20 03:04:20 +0100weary-traveler(~user@user/user363627) user363627
2025-01-20 03:04:30 +0100 <c_wraith> (strict speaking, tail *call* elimination. It works whether the call is recursive or not)
2025-01-20 03:04:43 +0100 <int-e> sure
2025-01-20 03:04:56 +0100 <int-e> Not the objection I was expecting
2025-01-20 03:06:09 +0100 <c_wraith> I think full tail-call elimination is really cool, and in many ways simpler than having a special case for tail recursion
2025-01-20 03:06:12 +0100 <int-e> > let iter n = n : iter (n+1) -- I was expecting this
2025-01-20 03:06:13 +0100 <lambdabot> <no location info>: error:
2025-01-20 03:06:13 +0100 <lambdabot> not an expression: ‘let iter n = n : iter (n+1) -- I was expecting this’
2025-01-20 03:06:19 +0100 <monochrom> Were you waiting for this? "Haskell doesn't specify TCE" :)
2025-01-20 03:06:27 +0100 <int-e> whoops
2025-01-20 03:06:38 +0100 <int-e> monochrom: no
2025-01-20 03:06:54 +0100 <c_wraith> Haskell may not specify exactly that, but it does specify something roughly equivalent
2025-01-20 03:06:54 +0100 <int-e> monochrom: I was expecting the laziness complication
2025-01-20 03:07:10 +0100 <int-e> that makes things tail-recursive that aren't syntactically tail recursive
2025-01-20 03:07:18 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 03:07:28 +0100 <c_wraith> The spec does require that recursion not have a max depth
2025-01-20 03:07:38 +0100 <monochrom> Oh yeah I used to raised that on haskell-cafe. It didn't end well, people thought I was a moron.
2025-01-20 03:08:28 +0100Adran(~adran@botters/adran) (Quit: Este é o fim.)
2025-01-20 03:09:25 +0100 <int-e> > let start c = c []; push xs x c = c (x:xs); add (x:y:xs) c = c (x+y:xs); end xs = xs in start push 1 push 2 add push 3 add push 4 end -- CPS
2025-01-20 03:09:27 +0100 <lambdabot> [4,6]
2025-01-20 03:10:37 +0100 <monochrom> https://mail.haskell.org/pipermail/haskell-cafe/2007-May/025591.html and see subsequent responses.
2025-01-20 03:10:56 +0100 <int-e> monochrom: yeah that's unfair; you're just a troll :P
2025-01-20 03:12:12 +0100 <albet70> for example in python f(g(a(b(c)))) you can throw an exception in c and catch it in f, no need to return to b, then to a, then to g
2025-01-20 03:12:14 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2025-01-20 03:12:40 +0100 <albet70> i just wonder if cps can achive that
2025-01-20 03:12:58 +0100 <albet70> without exception stuff
2025-01-20 03:13:57 +0100 <c_wraith> the thing, CPS doesn't work like that.
2025-01-20 03:14:40 +0100 <albet70> try catch isn't cps, right?
2025-01-20 03:14:41 +0100 <c_wraith> You have to write it more like `b c (f . g . a)'
2025-01-20 03:15:10 +0100 <c_wraith> It's an invasive intervention
2025-01-20 03:15:18 +0100 <monochrom> int-e: :( XD
2025-01-20 03:15:23 +0100 <int-e> The answer is yes but you have to change all your functions to take continuations as arguments. (Whether you do that using Cont or not is up to you.)
2025-01-20 03:15:38 +0100 <int-e> For example, look at this https://hackage.haskell.org/package/parsec-3.1.18.0/docs/src/Text.Parsec.Prim.html#ParsecT
2025-01-20 03:15:39 +0100 <c_wraith> You need to make significant changes, because the whole point is that you're replacing nested function calls with continuations
2025-01-20 03:15:58 +0100 <int-e> Which you can read as ParsecT wrapping a function that takes *four* continuations
2025-01-20 03:16:36 +0100 <monochrom> I'm going to go out on a limb that Python achieves that by compiling an exception language to CPS low level code.
2025-01-20 03:16:43 +0100 <int-e> On a different level, the answer is no; you can't have a pure function with an early return. Obviously not; that wouldn't be pure.
2025-01-20 03:16:51 +0100 <geekosaur> it does stack unwinding
2025-01-20 03:16:54 +0100 <geekosaur> so does C++
2025-01-20 03:17:02 +0100 <geekosaur> so does GHC for that matter
2025-01-20 03:17:18 +0100 <geekosaur> exceptions pretty much require it
2025-01-20 03:17:22 +0100 <int-e> The game we're playing could be called "pick your favorite abstraction to think about your code".
2025-01-20 03:17:42 +0100 <monochrom> THANK YOU!
2025-01-20 03:18:38 +0100 <geekosaur> in all cases it works backwards up stack frames until it finds one with an exception handler
2025-01-20 03:20:36 +0100 <probie> "true" CPS code™ (with TCO) doesn't allocate stack frames
2025-01-20 03:21:33 +0100 <geekosaur> in GHC Haskell these frames don't correspond to calls the way they do in more procedural languages; but I don't recall what they do correspond to.
2025-01-20 03:22:28 +0100 <geekosaur> (possibly it's all exception frames. note that in Haskell you must be in IO to handle an exception, so things are a bit different than they are for pure code anyway)
2025-01-20 03:22:43 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 03:23:32 +0100 <c_wraith> ghc uses the stack for nested evaluation of thunks. That often corresponds with nested function calls, but not always.
2025-01-20 03:23:59 +0100 <int-e> AIUI, fundamentally, entering a thunk allocates a stack frame. This extends to strict functions (which can be thought of as a thunk that is entered immediately, but GHC won't allocate the thunk)
2025-01-20 03:24:01 +0100 <geekosaur> I know you can piggyback on the mechanism to get a "stack trace" (with +RTS -xc) *but* profiling must be enabled for it to work; I presume that provides something resembling a call stack
2025-01-20 03:25:28 +0100 <int-e> Details get murky quickly. You won't be able to discern most of these things at the source code level.
2025-01-20 03:26:01 +0100 <int-e> (GHC does way too much inlining, for starters. And you'd need to anticipate strictness analysis too.)
2025-01-20 03:26:17 +0100 <geekosaur> (in a profiling report, you do get an indication of call stacks of some flavor)
2025-01-20 03:26:58 +0100 <int-e> But the thunk thing explains why `foldl (+) 1 [1..1000000]` used to overflow the stack (before stacks were made extensible)
2025-01-20 03:27:21 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-20 03:27:42 +0100 <int-e> because that *tail-recusively* builds a huge thunk that is then entered, entering a chain of subthunks all at once
2025-01-20 03:28:13 +0100 <int-e> (the strictness analyser can spoil the fun of course)
2025-01-20 03:29:28 +0100 <int-e> Anyway. Understanding Haskell low-level execution is quite difficult. I'm sure I'm getting it subtly wrong.
2025-01-20 03:30:07 +0100 <int-e> Well, not sure. But the chances are good.
2025-01-20 03:32:42 +0100 <monochrom> Once you fix an evaluation order, you will realize you need a stack for some things. Eager and lazy have opposite "some things", but both will need a stack.
2025-01-20 03:33:51 +0100 <monochrom> Fortunately! PLT people have noticed a commonality over all evaluation orders. The "some things" is called... continuations. You can always say "continuation stack" and it will be always right.
2025-01-20 03:37:31 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-01-20 03:37:50 +0100 <geekosaur> you know we probably lost albet70 long ago…
2025-01-20 03:38:05 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 03:38:15 +0100 <monochrom> At a high level, it goes like this. Given an evaluation order, you can factor each to-be-evaluated expression into redex and context. Redex means the small subexpression to evaluate right now, context is the rest.
2025-01-20 03:39:26 +0100 <int-e> geekosaur: *surely* one of the many answers we've come up with was satisfactory
2025-01-20 03:39:47 +0100 <monochrom> If you then try to go a bit lower level, you say: push the context (or representation of) on the stack, bring the redex to the front and work on it, afterwards pop the context and look for the next redex, etc.
2025-01-20 03:39:55 +0100 <geekosaur> unless they drowned in the wall-o-wtf
2025-01-20 03:40:07 +0100 <monochrom> In this case, context is synonym for continuation.
2025-01-20 03:41:25 +0100 <monochrom> Ooops, s/small//
2025-01-20 03:42:44 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2025-01-20 03:43:29 +0100Adran(~adran@botters/adran) Adran
2025-01-20 03:43:58 +0100hgolden(~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) (Remote host closed the connection)
2025-01-20 03:45:00 +0100 <int-e> monochrom: Heh. So if you use Cont or other (a -> r) -> (b -> r) -> r Haskell-level continuations, then at runtime, you have thunk-level CPS (continuations are stored in thunks until needed)
2025-01-20 03:45:29 +0100 <albet70> I like this talks even I don't understand now, it's very inspired :)
2025-01-20 03:45:39 +0100hgolden(~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) hgolden
2025-01-20 03:45:47 +0100 <geekosaur> that's what I said, wall-o-wtf 🙂
2025-01-20 03:46:02 +0100 <monochrom> Yeah you're just trading heap for stack. It's why I was so worked up about limited stack and unlimited heap.
2025-01-20 03:49:40 +0100 <monochrom> Anyway, that's a high-level reason why I don't make a distinction between "call stack like in C" and "eval stack like in Haskell". (I'm also mocking the irony there too because neither ISO C nor Haskell 2010 require a stack.) They are all continuation stacks, and once you know the evaluation order you know what continuation means.
2025-01-20 03:49:49 +0100 <monochrom> But here is also a low-level reason.
2025-01-20 03:50:38 +0100anpad(~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in)
2025-01-20 03:51:56 +0100 <monochrom> For this, you have to accept that I use the callee-pops-arguments convention. Suppose you make a "function call", i.e., push argument, push "return" address, jump to function. And suppose the function "returns", i.e., pop "return" address, pop argument, jump.
2025-01-20 03:52:11 +0100 <monochrom> Now just rename "return" to "continuation" there, and you have CPS.
2025-01-20 03:53:21 +0100 <int-e> right, and `call` (or `jsr` or whatever; the assembly level things) are callCC
2025-01-20 03:53:28 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 03:53:57 +0100 <int-e> and you have to read programs backward to discern continuations
2025-01-20 03:53:59 +0100 <int-e> what fun
2025-01-20 03:54:09 +0100 <int-e> +s
2025-01-20 03:58:29 +0100machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 248 seconds)
2025-01-20 04:01:09 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds)
2025-01-20 04:01:25 +0100JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty
2025-01-20 04:02:58 +0100homo(~homo@user/homo) homo
2025-01-20 04:05:07 +0100anpad(~pandeyan@user/anpad) anpad
2025-01-20 04:07:57 +0100anpad(~pandeyan@user/anpad) (Client Quit)
2025-01-20 04:11:31 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 04:15:30 +0100anpad(~pandeyan@user/anpad) anpad
2025-01-20 04:15:57 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2025-01-20 04:16:17 +0100anpad(~pandeyan@user/anpad) (Client Quit)
2025-01-20 04:19:20 +0100 <homo> it's happening, microhs lowers language requirements to be bootstrappable with hugs https://github.com/augustss/MicroHs/commit/2f9eab4db4e811e4c75ea370a64914abc94abf9c https://github.com/augustss/MicroHs/commit/56be300c293304b37cb18db499d825621be9ec4d
2025-01-20 04:19:48 +0100 <homo> however, pattern guards are not going away, so someone has to implement those in hugs
2025-01-20 04:23:59 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 04:24:10 +0100anpad(~pandeyan@user/anpad) anpad
2025-01-20 04:26:32 +0100pavonia(~user@user/siracusa) siracusa
2025-01-20 04:28:39 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2025-01-20 04:33:12 +0100JuanDaughertyColinRobinson
2025-01-20 04:37:24 +0100anpad(~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in)
2025-01-20 04:39:22 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 04:41:33 +0100ColinRobinsonJuanDaugherty
2025-01-20 04:42:40 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 272 seconds)
2025-01-20 04:43:49 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-20 04:44:36 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds)
2025-01-20 04:52:28 +0100JuanDaughertyColinRobinson
2025-01-20 04:54:44 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 04:59:17 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2025-01-20 05:00:48 +0100anpad(~pandeyan@user/anpad) anpad
2025-01-20 05:03:11 +0100ColinRobinson(~juan@user/JuanDaugherty) (Quit: ColinRobinson)
2025-01-20 05:10:07 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 05:14:38 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-20 05:25:29 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 05:30:07 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds)
2025-01-20 05:37:21 +0100dtman34(~dtman34@c-75-72-179-251.hsd1.mn.comcast.net) (Ping timeout: 252 seconds)
2025-01-20 05:40:51 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 05:43:14 +0100comonad(~comonad@p200300d027182d00bcfd40be9d94d2dc.dip0.t-ipconnect.de) (Quit: WeeChat 4.4.2)
2025-01-20 05:47:39 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2025-01-20 05:51:56 +0100dtman34(~dtman34@2601:447:d000:1f5e:d8cf:6a91:a7b5:a018) dtman34
2025-01-20 05:56:54 +0100dtman34(~dtman34@2601:447:d000:1f5e:d8cf:6a91:a7b5:a018) (Ping timeout: 252 seconds)
2025-01-20 06:00:34 +0100michalz(~michalz@185.246.207.217)
2025-01-20 06:01:49 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-01-20 06:04:06 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 06:05:47 +0100j1n37(~j1n37@user/j1n37) (Read error: Connection reset by peer)
2025-01-20 06:07:47 +0100JimL(~quassel@89.162.16.26) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2025-01-20 06:08:49 +0100dtman34(~dtman34@2601:447:d000:1f5e:d8cf:6a91:a7b5:a018) dtman34
2025-01-20 06:09:12 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds)
2025-01-20 06:10:42 +0100Pozyomka(~pyon@user/pyon) (Ping timeout: 272 seconds)
2025-01-20 06:11:00 +0100j1n37(~j1n37@user/j1n37) j1n37
2025-01-20 06:11:17 +0100JimL(~quassel@89.162.16.26) JimL
2025-01-20 06:19:30 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 06:24:03 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-20 06:34:52 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 06:39:20 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-20 06:39:33 +0100monochrom(trebla@216.138.220.146) (Ping timeout: 248 seconds)
2025-01-20 06:41:10 +0100monochrom(trebla@216.138.220.146)
2025-01-20 06:50:16 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 06:54:18 +0100ft(~ft@p508db21c.dip0.t-ipconnect.de) (Quit: leaving)
2025-01-20 06:55:29 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2025-01-20 07:06:12 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 07:09:36 +0100notzmv(~umar@user/notzmv) (Ping timeout: 265 seconds)
2025-01-20 07:10:51 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-20 07:12:46 +0100alp(~alp@2001:861:8ca0:4940:eea0:f0c9:6:c921)
2025-01-20 07:13:09 +0100haritz(~hrtz@user/haritz) (Ping timeout: 248 seconds)
2025-01-20 07:17:46 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-01-20 07:19:45 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 265 seconds)
2025-01-20 07:19:45 +0100tnt2tnt1
2025-01-20 07:21:34 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 07:23:10 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2025-01-20 07:26:34 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-20 07:26:38 +0100euleritian(~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds)
2025-01-20 07:27:10 +0100euleritian(~euleritia@77.23.250.232)
2025-01-20 07:31:46 +0100euleritian(~euleritia@77.23.250.232) (Ping timeout: 272 seconds)
2025-01-20 07:34:22 +0100euleritian(~euleritia@dynamic-176-006-144-251.176.6.pool.telefonica.de)
2025-01-20 07:34:44 +0100comonad(~comonad@p200300d027182d00bcfd40be9d94d2dc.dip0.t-ipconnect.de)
2025-01-20 07:37:38 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 07:45:04 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds)
2025-01-20 07:55:41 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 07:58:56 +0100 <haskellbridge> <sm> What’s the goal there homo ?
2025-01-20 08:00:43 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds)
2025-01-20 08:01:38 +0100monochrom(trebla@216.138.220.146) (Ping timeout: 248 seconds)
2025-01-20 08:01:43 +0100rvalue(~rvalue@user/rvalue) (Read error: Connection reset by peer)
2025-01-20 08:02:14 +0100rvalue(~rvalue@user/rvalue) rvalue
2025-01-20 08:02:35 +0100 <jackdk> Bootstrap gcc -> hugs -> microhs -> ghc
2025-01-20 08:05:36 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds)
2025-01-20 08:07:07 +0100monochrom(trebla@216.138.220.146)
2025-01-20 08:07:20 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2025-01-20 08:11:03 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 08:15:13 +0100acidjnk(~acidjnk@p200300d6e7283f8031585a6e342b94fb.dip0.t-ipconnect.de) acidjnk
2025-01-20 08:16:16 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Read error: Connection reset by peer)
2025-01-20 08:16:23 +0100comerijn(~merijn@77.242.116.146) merijn
2025-01-20 08:21:12 +0100 <homo> sm jackdk while ideally ghc would be bootstrapped with microhs, the first thing I want is to have darcs binary that I can trust
2025-01-20 08:22:51 +0100 <haskellbridge> <Bowuigi> Can microhs bootstrap GHC at all?
2025-01-20 08:22:57 +0100 <homo> it's still preferable that ghc lowers requirements so much that it becomes possible to compile today ghc with ancient ghc, then bootstrap with microhs should be easy
2025-01-20 08:23:11 +0100 <homo> nobody tried bootstrapping ghc with microhs
2025-01-20 08:23:33 +0100comerijn(~merijn@77.242.116.146) (Ping timeout: 265 seconds)
2025-01-20 08:23:52 +0100 <haskellbridge> <Bowuigi> Ah it's multistep for now, so like microhs -> ghc -> ghc -> ... -> ghc
2025-01-20 08:24:15 +0100 <homo> the reason to lower requirements is because it only makes sense to use small subset of language to implement whole language
2025-01-20 08:24:57 +0100 <homo> Bowuigi nobody tried even that multistep, it's too much work to adjust source code of any version of ghc
2025-01-20 08:26:48 +0100sawilagar(~sawilagar@user/sawilagar) sawilagar
2025-01-20 08:27:58 +0100 <homo> anyway, I have different idea: how about to use hugs ported to plan9 to bootstrap microhs on plan9 to have haskell2010 with 50+ ghc extensions compiler on plan9
2025-01-20 08:30:19 +0100 <haskellbridge> <Bowuigi> Well, the bootstrap process has to be made at most once per platform, but still, compiling a ton of GHC versions sounds painful
2025-01-20 08:32:50 +0100paul_j(~user@8.190.187.81.in-addr.arpa)
2025-01-20 08:34:55 +0100 <homo> Bowuigi and even impossible, I want to switch to riscv or arm, microhs is easy to boostrap there, but ghc is not
2025-01-20 08:42:20 +0100Square(~Square@user/square) Square
2025-01-20 08:42:47 +0100Square2(~Square4@user/square) Square
2025-01-20 08:44:15 +0100 <haskellbridge> <Bowuigi> For a scripting even Hugs is fast enough, do you have a special usecase in mind for GHC?
2025-01-20 08:46:09 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2025-01-20 08:46:51 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit)
2025-01-20 08:48:14 +0100 <homo> I want haskell compiler, not haskell interpreter, and my motivation to modify yacc and c parts of hugs just to get language features I need is almost 0
2025-01-20 08:48:57 +0100 <homo> also is there anyone who tried to run darcs under hugs?
2025-01-20 08:49:49 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2025-01-20 08:53:42 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 08:55:49 +0100alfiee(alfiee@user/alfiee) (Ping timeout: 260 seconds)
2025-01-20 08:56:14 +0100alfiee(alfiee@user/alfiee) alfiee
2025-01-20 09:00:02 +0100caconym(~caconym@user/caconym) (Quit: bye)
2025-01-20 09:00:29 +0100sord937(~sord937@gateway/tor-sasl/sord937) sord937
2025-01-20 09:00:41 +0100caconym(~caconym@user/caconym) caconym
2025-01-20 09:01:24 +0100monochrm(trebla@216.138.220.146)
2025-01-20 09:01:27 +0100paul_j`(~user@8.190.187.81.in-addr.arpa)
2025-01-20 09:01:42 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-20 09:02:31 +0100monochrom(trebla@216.138.220.146) (Ping timeout: 264 seconds)
2025-01-20 09:02:31 +0100monochrmmonochrom
2025-01-20 09:05:09 +0100Square(~Square@user/square) (Ping timeout: 260 seconds)
2025-01-20 09:06:19 +0100caryhartline(~caryhartl@KD106184157010.ec-userreverse.dion.ne.jp) CaryHartline
2025-01-20 09:09:21 +0100kuribas(~user@d51529C17.access.telenet.be) kuribas
2025-01-20 09:11:50 +0100monochrom(trebla@216.138.220.146) (Ping timeout: 272 seconds)
2025-01-20 09:12:27 +0100weary-traveler(~user@user/user363627) (Remote host closed the connection)
2025-01-20 09:12:39 +0100monochrom(trebla@216.138.220.146)
2025-01-20 09:12:44 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 09:14:53 +0100kuribas(~user@d51529C17.access.telenet.be) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3))
2025-01-20 09:15:08 +0100kuribas(~user@ptr-17d51eocedivlwulkvg.18120a2.ip6.access.telenet.be) kuribas
2025-01-20 09:17:22 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-20 09:17:42 +0100notzmv(~umar@user/notzmv) notzmv
2025-01-20 09:18:55 +0100 <homo> Bowuigi keep in mind memory manager of hugs is another pain point, try in hugs: sum $ reverse [1..200000]
2025-01-20 09:19:18 +0100 <homo> then try in ghci: sum $ reverse [1..1000000]
2025-01-20 09:19:49 +0100caryhartline(~caryhartl@KD106184157010.ec-userreverse.dion.ne.jp) (Read error: Connection reset by peer)
2025-01-20 09:20:06 +0100mulk(~mulk@pd9514590.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2025-01-20 09:22:50 +0100machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod
2025-01-20 09:27:22 +0100euleritian(~euleritia@dynamic-176-006-144-251.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2025-01-20 09:27:41 +0100euleritian(~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de)
2025-01-20 09:28:06 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 09:31:05 +0100monochrom(trebla@216.138.220.146) (Ping timeout: 244 seconds)
2025-01-20 09:32:35 +0100CiaoSen(~Jura@2a05:5800:2ce:7100:ca4b:d6ff:fec1:99da) CiaoSen
2025-01-20 09:32:36 +0100mulk(~mulk@pd9514590.dip0.t-ipconnect.de) mulk
2025-01-20 09:33:07 +0100monochrom(trebla@216.138.220.146)
2025-01-20 09:33:07 +0100euleritian(~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2025-01-20 09:33:59 +0100euleritian(~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de)
2025-01-20 09:37:30 +0100weary-traveler(~user@user/user363627) user363627
2025-01-20 09:38:07 +0100weary-traveler(~user@user/user363627) (Remote host closed the connection)
2025-01-20 09:40:16 +0100img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2025-01-20 09:41:37 +0100img(~img@user/img) img
2025-01-20 09:45:39 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds)
2025-01-20 09:49:30 +0100kuribas(~user@ptr-17d51eocedivlwulkvg.18120a2.ip6.access.telenet.be) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3))
2025-01-20 09:50:03 +0100kuribas(~user@ptr-17d51eocedivlwulkvg.18120a2.ip6.access.telenet.be) kuribas
2025-01-20 09:51:18 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-01-20 09:52:51 +0100akegalj(~akegalj@162-231.dsl.iskon.hr) akegalj
2025-01-20 09:54:09 +0100img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2025-01-20 09:55:29 +0100img(~img@user/img) img
2025-01-20 09:55:30 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2025-01-20 09:56:02 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 09:59:42 +0100alecs(~alecs@nat16.software.imdea.org) alecs
2025-01-20 10:02:42 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2025-01-20 10:03:59 +0100alecs(~alecs@nat16.software.imdea.org) (Client Quit)
2025-01-20 10:04:25 +0100alecs(~alecs@nat16.software.imdea.org) alecs
2025-01-20 10:05:43 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2025-01-20 10:06:27 +0100acidjnk(~acidjnk@p200300d6e7283f8031585a6e342b94fb.dip0.t-ipconnect.de) (Ping timeout: 276 seconds)
2025-01-20 10:07:49 +0100tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2025-01-20 10:10:10 +0100img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2025-01-20 10:10:41 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-01-20 10:11:23 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 244 seconds)
2025-01-20 10:11:23 +0100tnt2tnt1
2025-01-20 10:11:31 +0100img(~img@user/img) img
2025-01-20 10:11:53 +0100Smiles(uid551636@id-551636.lymington.irccloud.com) Smiles
2025-01-20 10:14:06 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 10:15:30 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-01-20 10:19:08 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)
2025-01-20 10:21:01 +0100lxsameer(~lxsameer@Serene/lxsameer) lxsameer
2025-01-20 10:21:32 +0100SrOs0(~sroso@user/SrOso) SrOso
2025-01-20 10:30:03 +0100alexherbo2(~alexherbo@2a02-8440-350d-0fe5-4d5d-0a7b-f8e6-7ac2.rev.sfr.net) alexherbo2
2025-01-20 10:30:17 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 10:33:55 +0100 <hc> join rust
2025-01-20 10:33:59 +0100 <hc> oops, sry
2025-01-20 10:34:55 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds)
2025-01-20 10:34:58 +0100 <kuribas> What do you think about verse?
2025-01-20 10:35:38 +0100 <tomsmeding> homo: if you're interested in bootstrapping ghc on a different platform, and you somehow manage to compile some version of ghc with microhs, couldn't you copy the resulting combinator C code to the other platform and compile it with gcc there?
2025-01-20 10:35:45 +0100 <tomsmeding> no need to run microhs with hugs, as far as I can see
2025-01-20 10:41:05 +0100sroso(~sroso@user/SrOso) SrOso
2025-01-20 10:42:48 +0100 <kuribas> Is verse only for the metaverse?
2025-01-20 10:43:17 +0100sroso(~sroso@user/SrOso) (Client Quit)
2025-01-20 10:43:26 +0100sroso(~sroso@user/SrOso) SrOso
2025-01-20 10:43:37 +0100 <kuribas> I wonder why so many haskell jobs are on the hype train (block chain, defense, high speed traiding, metaverse), rather than providing solid society progress.
2025-01-20 10:43:50 +0100sroso3(~sroso@user/SrOso) SrOso
2025-01-20 10:44:39 +0100SrOs0(~sroso@user/SrOso) (Quit: Leaving :))
2025-01-20 10:44:52 +0100 <kuribas> Though I suppose verse is more widely applicable than just the metaverse?
2025-01-20 10:45:40 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 10:46:03 +0100vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2025-01-20 10:47:47 +0100sroso3(~sroso@user/SrOso) (Quit: Client closed)
2025-01-20 10:48:58 +0100sroso(~sroso@user/SrOso) (Quit: Quit)
2025-01-20 10:49:03 +0100SrOs0(~sroso@user/SrOso) SrOso
2025-01-20 10:49:08 +0100sroso(~sroso@user/SrOso) SrOso
2025-01-20 10:49:30 +0100SrOs0(~sroso@user/SrOso) (Max SendQ exceeded)
2025-01-20 10:49:49 +0100sroso(~sroso@user/SrOso) (Client Quit)
2025-01-20 10:50:09 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2025-01-20 10:52:19 +0100infinity0(~infinity0@pwned.gg) (Ping timeout: 264 seconds)
2025-01-20 10:54:26 +0100sroso(~sroso@user/SrOso) SrOso
2025-01-20 11:01:01 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 11:03:03 +0100chele(~chele@user/chele) chele
2025-01-20 11:09:08 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds)
2025-01-20 11:12:15 +0100infinity0(~infinity0@pwned.gg) infinity0
2025-01-20 11:16:14 +0100__monty__(~toonn@user/toonn) toonn
2025-01-20 11:18:43 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 245 seconds)
2025-01-20 11:20:06 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-20 11:24:45 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds)