Newest at the top
| 2025-01-10 13:54:09 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Ping timeout: 248 seconds) |
| 2025-01-10 13:48:34 +0100 | <mreh> | so yeah, pretty low impact definitely |
| 2025-01-10 13:48:01 +0100 | <mreh> | I think it does CSE, but it might have a more important role than that, not sure |
| 2025-01-10 13:43:57 +0100 | ubert1 | ubert |
| 2025-01-10 13:43:57 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:6af7:7356:266e:a6fb) (Ping timeout: 246 seconds) |
| 2025-01-10 13:42:39 +0100 | <merijn> | mreh: Yeah, so small impact * low probability of happening = your probably fine |
| 2025-01-10 13:42:31 +0100 | ubert1 | (~Thunderbi@2a02:8109:ab8a:5a00:84ab:2b5:da25:e47f) ubert |
| 2025-01-10 13:42:29 +0100 | CiaoSen | (~Jura@2a05:5800:2e7:b00:ca4b:d6ff:fec1:99da) CiaoSen |
| 2025-01-10 13:40:57 +0100 | <mreh> | I *think* at least |
| 2025-01-10 13:40:48 +0100 | <mreh> | gpipe uses them to prevent recomputation of intermediate expressions |
| 2025-01-10 13:40:31 +0100 | <mreh> | I think in my case, it would be a performance issue, so not terrible |
| 2025-01-10 13:40:03 +0100 | <merijn> | mreh: It depends on "how bad is a false negative * probability of false negative" |
| 2025-01-10 13:39:55 +0100 | xff0x | (~xff0x@2405:6580:b080:900:8710:a51a:14b3:2b97) |
| 2025-01-10 13:39:04 +0100 | <mreh> | https://hackage.haskell.org/package/GPipe-2.2.5/docs/src/Data.SNMap.html#local-6989586621679049777 |
| 2025-01-10 13:38:59 +0100 | <mreh> | it seems to work for Gpipe and the way it builds GLSL expressions, but I haven't ever inspected the GLSL it outputs |
| 2025-01-10 13:38:14 +0100 | <merijn> | For WHNF constructors it seems *likely* they will be the same, but no guarantees |
| 2025-01-10 13:38:11 +0100 | <mreh> | merijn: a luke-warm guarantee is probably enough for my purposes |
| 2025-01-10 13:37:00 +0100 | <merijn> | So StableName guarantees no false positives, but does not guarantee no false negatives |
| 2025-01-10 13:36:27 +0100 | <merijn> | "The reverse is not necessarily true: if two stable names are not equal, then the objects they name may still be equal. Note in particular that makeStableName may return a different StableName after an object is evaluated." |
| 2025-01-10 13:36:24 +0100 | <merijn> | mreh: See also the note in the haddocks |
| 2025-01-10 13:35:58 +0100 | <merijn> | but hard guarantees are hard ;) |
| 2025-01-10 13:35:56 +0100 | l_k | (~student@213.24.133.111) |
| 2025-01-10 13:35:48 +0100 | <merijn> | mreh: But I would say it's certainly not guaranteed that "stableNameOf Foo == stableNameOf Foo" (with Foo being a constructor), it seems likely they will be the same |
| 2025-01-10 13:35:12 +0100 | <merijn> | Wait, I'm confusing StableName and StablePtr |
| 2025-01-10 13:35:04 +0100 | l_k | (~student@85.172.76.97) (Read error: Connection reset by peer) |
| 2025-01-10 13:34:46 +0100 | <mreh> | merijn: okay |
| 2025-01-10 13:34:33 +0100 | <merijn> | The creation of the StableName is what guarantees the stability |
| 2025-01-10 13:34:25 +0100 | l__k | (~student@85.172.77.123) (Ping timeout: 248 seconds) |
| 2025-01-10 13:34:13 +0100 | <merijn> | mreh: Very much no of the top of my head |
| 2025-01-10 13:33:21 +0100 | <hellwolf> | the achilles' heel of of thesis project |
| 2025-01-10 13:33:12 +0100 | <mreh> | before I delve into the literature, does anyone know if StableName equality is guaranteed when called on the same constructor? i.e. if I evaluate an object to WNHF will it always have the same StableName returned by makeStableName? |
| 2025-01-10 13:31:37 +0100 | l_k | (~student@85.172.76.97) |
| 2025-01-10 13:31:19 +0100 | l_k | (~student@81.177.127.117) (Ping timeout: 264 seconds) |
| 2025-01-10 13:30:44 +0100 | mreh | (~matthew@host86-146-25-121.range86-146.btcentralplus.com) mreh |
| 2025-01-10 13:28:18 +0100 | l__k | (~student@85.172.77.123) |
| 2025-01-10 13:26:40 +0100 | l__k | (~student@85.172.110.137) (Ping timeout: 244 seconds) |
| 2025-01-10 13:26:26 +0100 | <geekosaur> | thesis project |
| 2025-01-10 13:26:21 +0100 | <geekosaur> | yes |
| 2025-01-10 13:25:15 +0100 | <merijn> | I think it was ezyang's baby? |
| 2025-01-10 13:24:22 +0100 | <hellwolf> | I have watched a talk about backpack, awhile back. But I also heard that people behind backpack left. |
| 2025-01-10 13:23:55 +0100 | l_k | (~student@81.177.127.117) |
| 2025-01-10 13:23:54 +0100 | <merijn> | they're part of backpack, yeah |
| 2025-01-10 13:23:11 +0100 | <hellwolf> | I used mixins from cabal, if that's the same thing |
| 2025-01-10 13:22:55 +0100 | <merijn> | And did you look at backpack? |
| 2025-01-10 13:22:39 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-10 13:22:27 +0100 | <merijn> | But people already complain about binary sizes :p |
| 2025-01-10 13:22:10 +0100 | <merijn> | hellwolf: monomorphising everything is (conceptually and theoretically) trivial |
| 2025-01-10 13:21:57 +0100 | tomboy64 | (~tomboy64@user/tomboy64) tomboy64 |
| 2025-01-10 13:21:24 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-10 13:20:11 +0100 | vpan | (~vpan@212.117.1.172) (Quit: Leaving.) |