| 2026-02-16 00:06:54 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 00:07:46 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 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:12:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-02-16 00:12:41 +0100 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-02-16 00:22:39 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 00:27:53 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 00:36:33 +0100 | emmanuelux | (~em@user/emmanuelux) (Read error: Connection reset by peer) |
| 2026-02-16 00:38:42 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 00:39:54 +0100 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-02-16 00:41:11 +0100 | michalz | (~michalz@185.246.207.205) (Read error: Connection reset by peer) |
| 2026-02-16 00:41:37 +0100 | michalz | (~michalz@185.246.207.201) |
| 2026-02-16 00:43:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-02-16 00:45:25 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2026-02-16 00:50:00 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
| 2026-02-16 00:54:44 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 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:59:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 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 01:10:30 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 01:15:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 01:21:22 +0100 | <monochrom> | :) |
| 2026-02-16 01:26:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 01:33:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 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: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: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: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:39:58 +0100 | <jreicher> | exact form those constructs take; it only matters whether they are present. |
| 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: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:42:12 +0100 | <EvanR> | for semantics |
| 2026-02-16 01:42:33 +0100 | <EvanR> | they even lean into this seriously in immutable databases |
| 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:44:21 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 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: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: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:49:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 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:50:07 +0100 | xff0x | (~xff0x@2405:6580:b080:900:9c89:4c9f:731a:2a84) (Ping timeout: 264 seconds) |
| 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:54:26 +0100 | <EvanR> | typically they don't define it that way formally, or give particularly clear semantics |
| 2026-02-16 01:54:41 +0100 | <EvanR> | e.g. there's no heap in C, called that |
| 2026-02-16 01:54:44 +0100 | <EvanR> | at least |
| 2026-02-16 01:54:58 +0100 | <jreicher> | Understood, but why is that a problem? |
| 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:55:11 +0100 | <EvanR> | *squint* |
| 2026-02-16 01:56:19 +0100 | <EvanR> | why is what a problem, what problem |
| 2026-02-16 01:57:06 +0100 | <jreicher> | Not having the heap mutation defined formally. |
| 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: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 02:00:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 02:00:08 +0100 | karenw | (~karenw@user/karenw) (Ping timeout: 260 seconds) |
| 2026-02-16 02:02:42 +0100 | <EvanR> | I don't think there's any disagreement about anything here |
| 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:04:10 +0100 | <EvanR> | and when they try to "teach paradigms" in class, there's no "mutable variable programming" paradigm |
| 2026-02-16 02:04:54 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 02:05:16 +0100 | <EvanR> | for good reasons |
| 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:06:10 +0100 | <jreicher> | To the extent that I used to say a constant variable is an oxymoron. |
| 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:28 +0100 | <jreicher> | geekosaur: yes, but it's not under the programmer's control. That difference is critical. |
| 2026-02-16 02:11:49 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-02-16 02:14:09 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 252 seconds) |
| 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:15:33 +0100 | emmanuelux | (~em@user/emmanuelux) (Quit: bye) |
| 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:54 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 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:16:17 +0100 | omidmash1 | (~omidmash@user/omidmash) omidmash |
| 2026-02-16 02:16:39 +0100 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 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:17:24 +0100 | omidmash1 | omidmash |
| 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:58 +0100 | omidmash3 | (~omidmash@user/omidmash) (Ping timeout: 246 seconds) |
| 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:18:17 +0100 | <EvanR> | I think it's confusing levels, but ok |
| 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:20:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 02:21:30 +0100 | <c_wraith> | under what constraints? |
| 2026-02-16 02:22:16 +0100 | <c_wraith> | like, you have to be banning unsafePerformIO and friends |
| 2026-02-16 02:22:22 +0100 | <jreicher> | Oh, yes. :) |
| 2026-02-16 02:22:39 +0100 | <c_wraith> | how about unsafeInterleaveST? |
| 2026-02-16 02:24:16 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 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:28:35 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 250 seconds) |
| 2026-02-16 02:35:04 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2026-02-16 02:36:05 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2026-02-16 02:38:04 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-02-16 02:38:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 02:43:11 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 02:43:13 +0100 | Tuplanolla | (~Tuplanoll@85-156-32-207.elisa-laajakaista.fi) (Ping timeout: 264 seconds) |
| 2026-02-16 02:54:11 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 02:59:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 03:00:02 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Remote host closed the connection) |
| 2026-02-16 03:00:30 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds) |
| 2026-02-16 03:04:02 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2026-02-16 03:10:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 03:11:50 +0100 | ss4 | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-02-16 03:12:44 +0100 | <Lears> | % :seti -XLexicalNegation |
| 2026-02-16 03:12:44 +0100 | <yahb2> | <no output> |
| 2026-02-16 03:12:50 +0100 | <Lears> | % (- 1) 42 |
| 2026-02-16 03:12:50 +0100 | <yahb2> | 41 |
| 2026-02-16 03:12:58 +0100 | <Lears> | larsivi: ^ |
| 2026-02-16 03:15:19 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 245 seconds) |
| 2026-02-16 03:16:44 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 03:17:50 +0100 | camblsoup | (~camblsoup@d64-180-5-83.bchsia.telus.net) |
| 2026-02-16 03:21:42 +0100 | camblsoup | (~camblsoup@d64-180-5-83.bchsia.telus.net) (Client Quit) |
| 2026-02-16 03:28:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 03:32:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 03:40:21 +0100 | confusedalex_ | (~confuseda@user/confusedalex) confusedalex |
| 2026-02-16 03:40:56 +0100 | confusedalex | (~confuseda@user/confusedalex) (Ping timeout: 252 seconds) |
| 2026-02-16 03:40:56 +0100 | confusedalex_ | confusedalex |
| 2026-02-16 03:44:14 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 03:49:05 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 03:58:31 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:4df9:a697:65af:4b46) |
| 2026-02-16 04:00:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 04:04:37 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 244 seconds) |
| 2026-02-16 04:05:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-02-16 04:09:56 +0100 | omidmash | (~omidmash@user/omidmash) (Quit: The Lounge - https://thelounge.chat) |
| 2026-02-16 04:11:51 +0100 | td_ | (~td@i53870902.versanet.de) (Ping timeout: 244 seconds) |
| 2026-02-16 04:14:01 +0100 | td_ | (~td@i5387093C.versanet.de) td_ |
| 2026-02-16 04:14:38 +0100 | omidmash | (~omidmash@user/omidmash) omidmash |
| 2026-02-16 04:14:39 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-02-16 04:15:06 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Client Quit) |
| 2026-02-16 04:15:39 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-02-16 04:15:47 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 04:20:44 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 04:22:02 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2026-02-16 04:22:09 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2026-02-16 04:25:13 +0100 | mulk | (~mulk@p5b2dcbcc.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2026-02-16 04:26:30 +0100 | mulk | (~mulk@p5b2dcbcc.dip0.t-ipconnect.de) mulk |
| 2026-02-16 04:31:34 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 04:36:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-02-16 04:47:22 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 04:54:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-02-16 04:54:54 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds) |
| 2026-02-16 04:55:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 04:57:37 +0100 | rainbyte | (~rainbyte@186.22.19.214) (Read error: Connection reset by peer) |
| 2026-02-16 04:59:46 +0100 | rainbyte | (~rainbyte@186.22.19.214) rainbyte |
| 2026-02-16 05:01:13 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-02-16 05:04:04 +0100 | s3np41 | (~s3np41@078088254000.unknown.vectranet.pl) (Ping timeout: 245 seconds) |
| 2026-02-16 05:05:54 +0100 | s3np41 | (~s3np41@078088254000.unknown.vectranet.pl) |
| 2026-02-16 05:11:35 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 05:16:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2026-02-16 05:27:23 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |