Newest at the top
| 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 |
| 2026-02-16 02:14:09 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 252 seconds) |
| 2026-02-16 02:11:49 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-02-16 02:06:28 +0100 | <jreicher> | geekosaur: yes, but it's not under the programmer's control. That difference is critical. |
| 2026-02-16 02:06:10 +0100 | <geekosaur> | your fancy compiler for a pure functional programming language may optimize some things into mutable variables |
| 2026-02-16 02:06:10 +0100 | <jreicher> | To the extent that I used to say a constant variable is an oxymoron. |
| 2026-02-16 02:05:56 +0100 | <jreicher> | That's actually how I understand imperative programming. It's exactly "mutable variable programming" to me. |
| 2026-02-16 02:05:16 +0100 | <EvanR> | for good reasons |
| 2026-02-16 02:04:54 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 02:04:10 +0100 | <EvanR> | and when they try to "teach paradigms" in class, there's no "mutable variable programming" paradigm |
| 2026-02-16 02:03:35 +0100 | <EvanR> | mutation isn't really semantical gives the shitty to non-existent semantics provided in imperative languages, while it's clearly how they're implemented |
| 2026-02-16 02:02:42 +0100 | <EvanR> | I don't think there's any disagreement about anything here |
| 2026-02-16 02:00:08 +0100 | karenw | (~karenw@user/karenw) (Ping timeout: 260 seconds) |
| 2026-02-16 02:00:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 01:59:38 +0100 | <jreicher> | Well again I'm not sure if those specifics would bother me. It's a mutation that causes referential transparency to fail, and is under the programmer's control. That's what I think (but am not sure) sets these languages apart. |
| 2026-02-16 01:57:35 +0100 | <geekosaur> | in C if it's a local definition `char *a[43]` you'd be modifying stack, not heap |
| 2026-02-16 01:57:06 +0100 | <jreicher> | Not having the heap mutation defined formally. |
| 2026-02-16 01:56:19 +0100 | <EvanR> | why is what a problem, what problem |
| 2026-02-16 01:55:11 +0100 | <EvanR> | *squint* |
| 2026-02-16 01:55:07 +0100 | <jreicher> | I mean, if it allowed for no mutation at all, it would be... |
| 2026-02-16 01:54:58 +0100 | <jreicher> | Understood, but why is that a problem? |
| 2026-02-16 01:54:44 +0100 | <EvanR> | at least |
| 2026-02-16 01:54:41 +0100 | <EvanR> | e.g. there's no heap in C, called that |