2026/05/31

Newest at the top

2026-05-31 05:27:15 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-31 05:16:22 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)
2026-05-31 05:09:12 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-31 05:05:35 +0000takuan(~takuan@d8D86B9E9.access.telenet.be)
2026-05-31 04:59:30 +0000vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 248 seconds)
2026-05-31 04:58:30 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 253 seconds)
2026-05-31 04:53:25 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-31 04:47:46 +0000humasect(~humasect@192.249.132.90) (Quit: Leaving...)
2026-05-31 04:45:18 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2026-05-31 04:43:34 +0000Pozyomka(~pyon@user/pyon) (Quit: fuck claro)
2026-05-31 04:39:59 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-31 04:29:07 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 264 seconds)
2026-05-31 04:26:14 +0000Pozyomka_(~pyon@user/pyon) (Read error: Connection reset by peer)
2026-05-31 04:25:19 +0000Pozyomka(~pyon@user/pyon) pyon
2026-05-31 04:24:19 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-31 04:23:31 +0000Pozyomka(~pyon@user/pyon) (Remote host closed the connection)
2026-05-31 04:23:29 +0000Pozyomka_(~pyon@user/pyon) pyon
2026-05-31 04:13:36 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 266 seconds)
2026-05-31 04:08:23 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-31 04:05:26 +0000haritz(~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in)
2026-05-31 03:38:20 +0000humasect(~humasect@192.249.132.90) humasect
2026-05-31 03:35:20 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 254 seconds)
2026-05-31 03:33:44 +0000Inline(~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline
2026-05-31 03:30:27 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-31 03:18:56 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-05-31 03:17:48 +0000Pozyomka(~pyon@user/pyon) pyon
2026-05-31 03:17:48 +0000Pozyomka_(~pyon@user/pyon) (Remote host closed the connection)
2026-05-31 03:12:25 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-31 03:03:42 +0000 <jreicher> lisbeths: thought about what you want to do a little more and I've had an idea. Have you tried using arrays efficiently in Haskell, without re-implementing lambda calculus evaluation?
2026-05-31 03:01:52 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2026-05-31 02:59:22 +0000spew(~spew@user/spew) spew
2026-05-31 02:59:04 +0000spew(~spew@user/spew) (Quit: nyaa~)
2026-05-31 02:56:41 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-31 02:45:55 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-05-31 02:41:04 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-31 02:37:51 +0000 <jreicher> lisbeths: you don't store the arguments in a list. The lambda calculus expression IS the lsit.
2026-05-31 02:37:10 +0000Fijxu(~Fijxu@user/fijxu) fijxu
2026-05-31 02:36:26 +0000Fijxu(~Fijxu@user/fijxu) (Quit: XD!!)
2026-05-31 02:35:08 +0000 <lisbeths> im more talking about how to get fast arrays in lc
2026-05-31 02:34:37 +0000 <lisbeths> you can write lazy algorithms in lc by suspending the application of something and storing all the arguments in a list. it doesnt have to be built into the interpreter
2026-05-31 02:33:24 +0000 <jreicher> But for a really efficient implementation you need to figure out fast currying. In some ways it's the most difficult of the three.
2026-05-31 02:32:16 +0000 <jreicher> Memoisation of results depends a bit on whether you are reducing under abstractions. I've never seen an implementation of that, but it's sometimes called "full laziness". Would be cool if someone did it.
2026-05-31 02:31:05 +0000 <jreicher> And that's not even covering how you might represent the result of a beta reduction. The expensive way to do it is to generate a new lambda expression, but if performance is not a consideration there's actually nothing wrong with that. The use of environments, etc. is really just an optimisation.
2026-05-31 02:30:21 +0000 <jreicher> For that there are (at least) three kinds of optimisation. One is tail call optimisation. Another is fast currying. And then another is lazy evaluation, which is the memoisation of results.
2026-05-31 02:30:13 +0000bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2026-05-31 02:30:01 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2026-05-31 02:29:35 +0000 <jreicher> machine. Next is the implementation itself...
2026-05-31 02:29:35 +0000 <jreicher> lisbeths: there are (at least) two different domains of lambda calculus evaluation performance. One is the calculus itself, i.e. some evaluation orders are shorter than others. In the K-calculus, some evaluations don't terminate at all. The term "lazy" evaluation is sometimes used (incorrectly, in my opinion) to refer to evaluation order. You should make sure you're doing normal order evaluation. That's kind of the bare minimum for a
2026-05-31 02:25:06 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-31 02:19:25 +0000bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds)