Newest at the top
| 2026-02-16 03:44:14 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 03:40:56 +0100 | confusedalex_ | confusedalex |
| 2026-02-16 03:40:56 +0100 | confusedalex | (~confuseda@user/confusedalex) (Ping timeout: 252 seconds) |
| 2026-02-16 03:40:21 +0100 | confusedalex_ | (~confuseda@user/confusedalex) confusedalex |
| 2026-02-16 03:32:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 03:28:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 03:21:42 +0100 | camblsoup | (~camblsoup@d64-180-5-83.bchsia.telus.net) (Client Quit) |
| 2026-02-16 03:17:50 +0100 | camblsoup | (~camblsoup@d64-180-5-83.bchsia.telus.net) |
| 2026-02-16 03:16:44 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 03:15:19 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 245 seconds) |
| 2026-02-16 03:12:58 +0100 | <Lears> | larsivi: ^ |
| 2026-02-16 03:12:50 +0100 | <yahb2> | 41 |
| 2026-02-16 03:12:50 +0100 | <Lears> | % (- 1) 42 |
| 2026-02-16 03:12:44 +0100 | <yahb2> | <no output> |
| 2026-02-16 03:12:44 +0100 | <Lears> | % :seti -XLexicalNegation |
| 2026-02-16 03:11:50 +0100 | ss4 | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-02-16 03:10:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 03:04:02 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2026-02-16 03:00:30 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds) |
| 2026-02-16 03:00:02 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Remote host closed the connection) |
| 2026-02-16 02:59:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 02:54:11 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 02:43:13 +0100 | Tuplanolla | (~Tuplanoll@85-156-32-207.elisa-laajakaista.fi) (Ping timeout: 264 seconds) |
| 2026-02-16 02:43:11 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 02:38:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 02:38:04 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-02-16 02:36:05 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2026-02-16 02:35:04 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2026-02-16 02:28:35 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 250 seconds) |
| 2026-02-16 02:25:37 +0100 | <jreicher> | TBH I'm not sure. I can't figure out what I think of referential transparency with threads. |
| 2026-02-16 02:24:16 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-02-16 02:22:39 +0100 | <c_wraith> | how about unsafeInterleaveST? |
| 2026-02-16 02:22:22 +0100 | <jreicher> | Oh, yes. :) |
| 2026-02-16 02:22:16 +0100 | <c_wraith> | like, you have to be banning unsafePerformIO and friends |
| 2026-02-16 02:21:30 +0100 | <c_wraith> | under what constraints? |
| 2026-02-16 02:20:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 02:19:20 +0100 | <jreicher> | I can understand why you say that. As I said I don't have anything formal, but I would be interested in anything that can apparently display a failure of referential transparency, written in Haskell. I don't think it's possible. |
| 2026-02-16 02:18:17 +0100 | <EvanR> | I think it's confusing levels, but ok |
| 2026-02-16 02:18:00 +0100 | <jreicher> | I know, but I think that's a subset of mutation behaviour that preserves referential transparency (as graph reduction does anyway). |
| 2026-02-16 02:17:58 +0100 | omidmash3 | (~omidmash@user/omidmash) (Ping timeout: 246 seconds) |
| 2026-02-16 02:17:37 +0100 | <EvanR> | so the "heap needs to mutate for my reasoning to work" is not necessarily useful |
| 2026-02-16 02:17:24 +0100 | omidmash1 | omidmash |
| 2026-02-16 02:17:02 +0100 | <EvanR> | in haskell, we can program imperative programs with apparently mutable variables, and while the underlying semantics are still purely functional |
| 2026-02-16 02:16:39 +0100 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-02-16 02:16:17 +0100 | omidmash1 | (~omidmash@user/omidmash) omidmash |
| 2026-02-16 02:16:07 +0100 | <jreicher> | Yep, but I'm not thinking of what's actually happening; I'm trying to think about the semantics even if they're abstract. That's why I keep talking about referential transparency failing. If that happens, then I think you need mutation in your semantics somewhere, somehow. It makes it unavoidable. |
| 2026-02-16 02:15:54 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 02:15:53 +0100 | <EvanR> | though even in the beginning "it's mutation therefore fast" failed if you ran out of registers, today even less predictive |
| 2026-02-16 02:15:33 +0100 | emmanuelux | (~em@user/emmanuelux) (Quit: bye) |
| 2026-02-16 02:14:14 +0100 | <EvanR> | a lot of stuff is not under your control in C either... this is the sad fact of being a high level language from the start |