Newest at the top
| 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 |
| 2026-02-16 01:54:26 +0100 | <EvanR> | typically they don't define it that way formally, or give particularly clear semantics |
| 2026-02-16 01:51:18 +0100 | <jreicher> | Not sure what you mean by that. If in an imperative language I say a[42] = "Don't panic", aren't I assured of mutating something in heap even though I might not know exactly where? |
| 2026-02-16 01:50:07 +0100 | xff0x | (~xff0x@2405:6580:b080:900:9c89:4c9f:731a:2a84) (Ping timeout: 264 seconds) |
| 2026-02-16 01:49:44 +0100 | <EvanR> | I still think mutable heap memory is implementation specific, and struggles to be a semantic thing, much less a paradigm-defining thing |
| 2026-02-16 01:49:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2026-02-16 01:47:02 +0100 | <jreicher> | I did see this discussed precisely many years ago, as something that mutation can actually be useful for, using it as a notification mechanism for a "distant" part of the program. |
| 2026-02-16 01:46:30 +0100 | <jreicher> | EvanR: ah, fair point with the messages. There's an extra bit I have in mind but I struggle to put it into words. It's something like an observer getting a mutation they didn't ask for, which I think is equivalent to referential transparency failing. |
| 2026-02-16 01:44:23 +0100 | <EvanR> | and in that case I'd be surprised if they even distinguish semantics |
| 2026-02-16 01:44:21 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 01:43:50 +0100 | <EvanR> | but yeah certain narrow presentations of OOP dwell heavily on "this is OOP. We mutate things" |
| 2026-02-16 01:42:33 +0100 | <EvanR> | they even lean into this seriously in immutable databases |
| 2026-02-16 01:42:12 +0100 | <EvanR> | for semantics |
| 2026-02-16 01:41:59 +0100 | <EvanR> | e.g. in one version of imperative programming, or even concurrent programming, the programs can have access to the history of messages which stands in for mutable state |
| 2026-02-16 01:41:08 +0100 | <EvanR> | if we're going to make a distinction between syntax and (different choices of) semantics, then mutable memory doesn't have to factor in either way |