Newest at the top
| 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 |
| 2026-02-16 01:39:58 +0100 | <jreicher> | exact form those constructs take; it only matters whether they are present. |
| 2026-02-16 01:39:57 +0100 | <jreicher> | For myself I try to make it precise something like following. All program execution requires mutation of state in the sense that the computer's memory is mutating. But the HUGE difference between a pure functional language and not is that the semantics of that are present in the latter and not at all in the former. Meaning you have language constructs that say "mutate this". The programmer can control it. So to me it doesn't matter the |
| 2026-02-16 01:37:25 +0100 | <EvanR> | I think just being precise is a fine path to getting there. OOP isn't a priori precise unfortunately. mutable behavior? |
| 2026-02-16 01:35:54 +0100 | <jreicher> | Particularly since the mainstream OO languages seem to be converging on the functional way of doing the latter. |
| 2026-02-16 01:35:20 +0100 | <jreicher> | EvanR: TBH I'm comfortable with not pinning down terms. I'm more interested in finding good ways to think about stuff, and I think it's worth treating encapsulation of mutable behaviour differently from encapsulation of (immutable) data representation, if that makes sense? |
| 2026-02-16 01:33:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 01:26:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 01:21:22 +0100 | <monochrom> | :) |
| 2026-02-16 01:15:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 01:10:30 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 01:08:49 +0100 | <EvanR> | so you want to subtract a number by 1 let me first introduce you to some category theory |
| 2026-02-16 00:59:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-02-16 00:59:04 +0100 | troydm | (~troydm@user/troydm) (Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset) |
| 2026-02-16 00:54:44 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 00:50:00 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
| 2026-02-16 00:45:25 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2026-02-16 00:43:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-02-16 00:41:37 +0100 | michalz | (~michalz@185.246.207.201) |
| 2026-02-16 00:41:11 +0100 | michalz | (~michalz@185.246.207.205) (Read error: Connection reset by peer) |
| 2026-02-16 00:39:54 +0100 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-02-16 00:38:42 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 00:36:33 +0100 | emmanuelux | (~em@user/emmanuelux) (Read error: Connection reset by peer) |
| 2026-02-16 00:27:53 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 00:22:39 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 00:12:41 +0100 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-02-16 00:12:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-02-16 00:08:36 +0100 | tromp | (~textual@2001:1c00:3487:1b00:4c61:e2e8:1826:9093) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-02-16 00:07:46 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |