Newest at the top
| 2026-05-31 05:27:15 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-31 05:16:22 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-05-31 05:09:12 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-31 05:05:35 +0000 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2026-05-31 04:59:30 +0000 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 248 seconds) |
| 2026-05-31 04:58:30 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 253 seconds) |
| 2026-05-31 04:53:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-31 04:47:46 +0000 | humasect | (~humasect@192.249.132.90) (Quit: Leaving...) |
| 2026-05-31 04:45:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-05-31 04:43:34 +0000 | Pozyomka | (~pyon@user/pyon) (Quit: fuck claro) |
| 2026-05-31 04:39:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-31 04:29:07 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 264 seconds) |
| 2026-05-31 04:26:14 +0000 | Pozyomka_ | (~pyon@user/pyon) (Read error: Connection reset by peer) |
| 2026-05-31 04:25:19 +0000 | Pozyomka | (~pyon@user/pyon) pyon |
| 2026-05-31 04:24:19 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-05-31 04:23:31 +0000 | Pozyomka | (~pyon@user/pyon) (Remote host closed the connection) |
| 2026-05-31 04:23:29 +0000 | Pozyomka_ | (~pyon@user/pyon) pyon |
| 2026-05-31 04:13:36 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 266 seconds) |
| 2026-05-31 04:08:23 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-31 04:05:26 +0000 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2026-05-31 03:38:20 +0000 | humasect | (~humasect@192.249.132.90) humasect |
| 2026-05-31 03:35:20 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 254 seconds) |
| 2026-05-31 03:33:44 +0000 | Inline | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline |
| 2026-05-31 03:30:27 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-31 03:18:56 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-05-31 03:17:48 +0000 | Pozyomka | (~pyon@user/pyon) pyon |
| 2026-05-31 03:17:48 +0000 | Pozyomka_ | (~pyon@user/pyon) (Remote host closed the connection) |
| 2026-05-31 03:12:25 +0000 | merijn | (~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 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-05-31 02:59:22 +0000 | spew | (~spew@user/spew) spew |
| 2026-05-31 02:59:04 +0000 | spew | (~spew@user/spew) (Quit: nyaa~) |
| 2026-05-31 02:56:41 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-31 02:45:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-05-31 02:41:04 +0000 | merijn | (~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 +0000 | Fijxu | (~Fijxu@user/fijxu) fijxu |
| 2026-05-31 02:36:26 +0000 | Fijxu | (~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 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2026-05-31 02:30:01 +0000 | merijn | (~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 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-31 02:19:25 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds) |