Newest at the top
| 2025-04-25 19:33:54 +0200 | <tomsmeding> | EvanR: I'm excited to see how he plans to make real number math decidable, let alone performant. :D |
| 2025-04-25 19:17:30 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2025-04-25 19:14:37 +0200 | wbrawner | (~wbrawner@static.205.41.78.5.clients.your-server.de) (Ping timeout: 272 seconds) |
| 2025-04-25 19:10:24 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2025-04-25 19:05:02 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 252 seconds) |
| 2025-04-25 19:04:12 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-04-25 19:02:57 +0200 | jacopovalanzano | (~jacopoval@cpc151911-cove17-2-0-cust105.3-1.cable.virginm.net) |
| 2025-04-25 19:01:57 +0200 | dhil | (~dhil@openvpn-125-1069.inf.ed.ac.uk) (Ping timeout: 272 seconds) |
| 2025-04-25 18:57:49 +0200 | tromp | (~textual@2001:1c00:3487:1b00:c44:d27d:c88:929f) |
| 2025-04-25 18:52:37 +0200 | tromp | (~textual@2001:1c00:3487:1b00:c44:d27d:c88:929f) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-04-25 18:52:03 +0200 | dhil | (~dhil@openvpn-125-1069.inf.ed.ac.uk) dhil |
| 2025-04-25 18:51:59 +0200 | wbrawner | (~wbrawner@static.205.41.78.5.clients.your-server.de) wbrawner |
| 2025-04-25 18:42:55 +0200 | Square | (~Square@user/square) Square |
| 2025-04-25 18:39:08 +0200 | dhil | (~dhil@5.151.29.137) (Ping timeout: 272 seconds) |
| 2025-04-25 18:39:02 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-04-25 18:30:06 +0200 | Googulator47 | (~Googulato@81.183.235.203) (Ping timeout: 240 seconds) |
| 2025-04-25 18:24:49 +0200 | <EvanR> | that was 2023 glad to see conal's still got it |
| 2025-04-25 18:19:51 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-04-25 18:19:35 +0200 | <EvanR> | but maybe it's because of haskell's brand of laziness |
| 2025-04-25 18:18:38 +0200 | ColinRobinson | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-04-25 18:18:30 +0200 | <ColinRobinson> | prolly means spiffed gmp backend oder |
| 2025-04-25 18:17:59 +0200 | <EvanR> | and I"m thinking, the fastest implementation we have doesn't use laziness |
| 2025-04-25 18:17:39 +0200 | <EvanR> | and that existing implementations are slow just because they haven't been optimized |
| 2025-04-25 18:17:11 +0200 | <EvanR> | in the latest conal talk listed on conal's website, in a side remark still suggests that "long term" we will replace float point math with real number math in a way that is high performance and correct and reliable. Saying something about how lazy evaluation could be involved |
| 2025-04-25 18:17:06 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-04-25 18:15:51 +0200 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-04-25 18:11:47 +0200 | Digit | (~user@user/digit) Digit |
| 2025-04-25 18:10:18 +0200 | JuanDaugherty | ColinRobinson |
| 2025-04-25 18:03:26 +0200 | <JuanDaugherty> | :) |
| 2025-04-25 18:03:11 +0200 | <EvanR> | JuanDaugherty, yes many years later in haskell, copy is e.g. an explicit operation to help ByteStrings get collected xD |
| 2025-04-25 18:02:13 +0200 | <EvanR> | do you think "make a copy" is referring to assigning to another variable |
| 2025-04-25 18:01:06 +0200 | wbrawner | (~wbrawner@129.146.103.146) (Remote host closed the connection) |
| 2025-04-25 18:00:39 +0200 | tromp | (~textual@2001:1c00:3487:1b00:c44:d27d:c88:929f) |
| 2025-04-25 17:59:54 +0200 | <EvanR> | I think no one ever figured it out, and it was removed |
| 2025-04-25 17:59:54 +0200 | <JuanDaugherty> | enwiki sez APL was 20y b4 ML |
| 2025-04-25 17:59:42 +0200 | <EvanR> | but apparently it wasn't |
| 2025-04-25 17:59:20 +0200 | <EvanR> | in godot 3 there was also this one bizarre feature explained in the manual as "pass by value". This one primitive of array of bytes or ints is "pass by value", which they then equated to immutable, and then community assumed this meant copy on write |
| 2025-04-25 17:57:25 +0200 | <EvanR> | so it could satisfy many stories |
| 2025-04-25 17:57:13 +0200 | <EvanR> | your example doesn't involve any copies since you don't save the original |
| 2025-04-25 17:56:54 +0200 | caconym7 | caconym |
| 2025-04-25 17:56:54 +0200 | caconym | (~caconym@user/caconym) (Ping timeout: 260 seconds) |
| 2025-04-25 17:56:52 +0200 | <int-e> | If you're picky about it it's lies all the way down. |
| 2025-04-25 17:56:39 +0200 | <int-e> | But it isn't. It's a matter of how I think about the operation. I want the same list, but with all elements replaced by their successor. It's convenient for me to think of that as mutation. Even if no actual mutation is taking place at runtime. Except there is mutation at runtime because laziness comes with in-place updates. |
| 2025-04-25 17:56:26 +0200 | <EvanR> | though maybe back in the difference array days this was normal |
| 2025-04-25 17:56:16 +0200 | <JuanDaugherty> | eerie concordence, god an extremal concept and immutablility equally absolutist |
| 2025-04-25 17:55:34 +0200 | <EvanR> | immutable update vs mutation |
| 2025-04-25 17:55:08 +0200 | <EvanR> | seems like an abuse of jargon |
| 2025-04-25 17:54:44 +0200 | caconym7 | (~caconym@user/caconym) caconym |
| 2025-04-25 17:54:17 +0200 | <int-e> | there's no contradiction here, just different levels of abstraction |
| 2025-04-25 17:54:05 +0200 | <lambdabot> | [2,3] |