Logs: liberachat/#haskell
| 2026-02-16 00:26:19 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-02-16 00:33:20 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 00:35:20 | <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 00:35:54 | <jreicher> | Particularly since the mainstream OO languages seem to be converging on the functional way of doing the latter. |
| 2026-02-16 00:37:25 | <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 00:39:57 | <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 00:39:58 | <jreicher> | exact form those constructs take; it only matters whether they are present. |
| 2026-02-16 00:41:08 | <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 00:41:59 | <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 00:42:12 | <EvanR> | for semantics |
| 2026-02-16 00:42:33 | <EvanR> | they even lean into this seriously in immutable databases |
| 2026-02-16 00:43:50 | <EvanR> | but yeah certain narrow presentations of OOP dwell heavily on "this is OOP. We mutate things" |
| 2026-02-16 00:44:21 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-02-16 00:44:23 | <EvanR> | and in that case I'd be surprised if they even distinguish semantics |
| 2026-02-16 00:46:30 | <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 00:47:02 | <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 00:49:38 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2026-02-16 00:49:44 | <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 00:50:07 | × | xff0x quits (~xff0x@2405:6580:b080:900:9c89:4c9f:731a:2a84) (Ping timeout: 264 seconds) |
| 2026-02-16 00:51:18 | <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 00:54:26 | <EvanR> | typically they don't define it that way formally, or give particularly clear semantics |
| 2026-02-16 00:54:41 | <EvanR> | e.g. there's no heap in C, called that |
| 2026-02-16 00:54:44 | <EvanR> | at least |
| 2026-02-16 00:54:58 | <jreicher> | Understood, but why is that a problem? |
| 2026-02-16 00:55:07 | <jreicher> | I mean, if it allowed for no mutation at all, it would be... |
| 2026-02-16 00:55:11 | <EvanR> | *squint* |
| 2026-02-16 00:56:19 | <EvanR> | why is what a problem, what problem |
| 2026-02-16 00:57:06 | <jreicher> | Not having the heap mutation defined formally. |
| 2026-02-16 00:57:35 | <geekosaur> | in C if it's a local definition `char *a[43]` you'd be modifying stack, not heap |
| 2026-02-16 00:59:38 | <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:00:08 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-02-16 01:00:08 | × | karenw quits (~karenw@user/karenw) (Ping timeout: 260 seconds) |
| 2026-02-16 01:02:42 | <EvanR> | I don't think there's any disagreement about anything here |
| 2026-02-16 01:03:35 | <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 01:04:10 | <EvanR> | and when they try to "teach paradigms" in class, there's no "mutable variable programming" paradigm |
| 2026-02-16 01:04:54 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 01:05:16 | <EvanR> | for good reasons |
| 2026-02-16 01:05:56 | <jreicher> | That's actually how I understand imperative programming. It's exactly "mutable variable programming" to me. |
| 2026-02-16 01:06:10 | <jreicher> | To the extent that I used to say a constant variable is an oxymoron. |
| 2026-02-16 01:06:10 | <geekosaur> | your fancy compiler for a pure functional programming language may optimize some things into mutable variables |
| 2026-02-16 01:06:28 | <jreicher> | geekosaur: yes, but it's not under the programmer's control. That difference is critical. |
| 2026-02-16 01:11:49 | → | weary-traveler joins (~user@user/user363627) |
| 2026-02-16 01:14:09 | × | ljdarj quits (~Thunderbi@user/ljdarj) (Ping timeout: 252 seconds) |
| 2026-02-16 01:14:14 | <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 01:15:33 | × | emmanuelux quits (~em@user/emmanuelux) (Quit: bye) |
| 2026-02-16 01:15:53 | <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 01:15:54 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-02-16 01:16:07 | <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 01:16:17 | → | omidmash1 joins (~omidmash@user/omidmash) |
| 2026-02-16 01:16:39 | → | emmanuelux joins (~em@user/emmanuelux) |
| 2026-02-16 01:17:02 | <EvanR> | in haskell, we can program imperative programs with apparently mutable variables, and while the underlying semantics are still purely functional |
| 2026-02-16 01:17:24 | omidmash1 | is now known as omidmash |
| 2026-02-16 01:17:37 | <EvanR> | so the "heap needs to mutate for my reasoning to work" is not necessarily useful |
| 2026-02-16 01:17:58 | × | omidmash3 quits (~omidmash@user/omidmash) (Ping timeout: 246 seconds) |
| 2026-02-16 01:18:00 | <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 01:18:17 | <EvanR> | I think it's confusing levels, but ok |
| 2026-02-16 01:19:20 | <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 01:20:38 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 01:21:30 | <c_wraith> | under what constraints? |
| 2026-02-16 01:22:16 | <c_wraith> | like, you have to be banning unsafePerformIO and friends |
| 2026-02-16 01:22:22 | <jreicher> | Oh, yes. :) |
| 2026-02-16 01:22:39 | <c_wraith> | how about unsafeInterleaveST? |
| 2026-02-16 01:24:16 | → | prdak joins (~Thunderbi@user/prdak) |
| 2026-02-16 01:25:37 | <jreicher> | TBH I'm not sure. I can't figure out what I think of referential transparency with threads. |
| 2026-02-16 01:28:35 | × | prdak quits (~Thunderbi@user/prdak) (Ping timeout: 250 seconds) |
| 2026-02-16 01:35:04 | × | bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2026-02-16 01:36:05 | → | bitdex joins (~bitdex@gateway/tor-sasl/bitdex) |
| 2026-02-16 01:38:04 | → | xff0x joins (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-02-16 01:38:08 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-02-16 01:43:11 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 01:43:13 | × | Tuplanolla quits (~Tuplanoll@85-156-32-207.elisa-laajakaista.fi) (Ping timeout: 264 seconds) |
| 2026-02-16 01:54:11 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-02-16 01:59:08 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 02:00:02 | × | ezzieyguywuf quits (~Unknown@user/ezzieyguywuf) (Remote host closed the connection) |
| 2026-02-16 02:00:30 | × | bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds) |
| 2026-02-16 02:04:02 | → | bitdex joins (~bitdex@gateway/tor-sasl/bitdex) |
| 2026-02-16 02:10:01 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-02-16 02:11:50 | → | ss4 joins (~wootehfoo@user/wootehfoot) |
| 2026-02-16 02:12:44 | <Lears> | % :seti -XLexicalNegation |
| 2026-02-16 02:12:44 | <yahb2> | <no output> |
| 2026-02-16 02:12:50 | <Lears> | % (- 1) 42 |
| 2026-02-16 02:12:50 | <yahb2> | 41 |
| 2026-02-16 02:12:58 | <Lears> | larsivi: ^ |
| 2026-02-16 02:15:19 | × | wootehfoot quits (~wootehfoo@user/wootehfoot) (Ping timeout: 245 seconds) |
| 2026-02-16 02:16:44 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 02:17:50 | → | camblsoup joins (~camblsoup@d64-180-5-83.bchsia.telus.net) |
| 2026-02-16 02:21:42 | × | camblsoup quits (~camblsoup@d64-180-5-83.bchsia.telus.net) (Client Quit) |
| 2026-02-16 02:28:00 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-02-16 02:32:49 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 02:40:21 | → | confusedalex_ joins (~confuseda@user/confusedalex) |
| 2026-02-16 02:40:56 | × | confusedalex quits (~confuseda@user/confusedalex) (Ping timeout: 252 seconds) |
| 2026-02-16 02:40:56 | confusedalex_ | is now known as confusedalex |
| 2026-02-16 02:44:14 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-02-16 02:49:05 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 02:58:31 | → | bggd_ joins (~bgg@2a01:e0a:fd5:f510:4df9:a697:65af:4b46) |
| 2026-02-16 03:00:01 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-02-16 03:04:37 | × | machinedgod quits (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 244 seconds) |
| 2026-02-16 03:05:25 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-02-16 03:09:56 | × | omidmash quits (~omidmash@user/omidmash) (Quit: The Lounge - https://thelounge.chat) |
| 2026-02-16 03:11:51 | × | td_ quits (~td@i53870902.versanet.de) (Ping timeout: 244 seconds) |
All times are in UTC.