Newest at the top
| 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.) |
| 2025-01-10 13:18:47 +0100 | <mari47944> | huh i think there are a few proposals aligned, but i might be wrong |
| 2025-01-10 13:18:24 +0100 | l_k | (~student@217.107.126.75) (Ping timeout: 244 seconds) |
| 2025-01-10 13:17:58 +0100 | <hellwolf> | no theory needed |
| 2025-01-10 13:17:53 +0100 | <hellwolf> | CPP people just simply #define A TO_BE_B |
| 2025-01-10 13:17:24 +0100 | <hellwolf> | It must be very complicated, theory wise :p |
| 2025-01-10 13:17:12 +0100 | <hellwolf> | Type theory people will laugh at our enthusiasm. |
| 2025-01-10 13:15:57 +0100 | l_k_ | (~student@85.172.110.63) (Ping timeout: 246 seconds) |
| 2025-01-10 13:14:36 +0100 | l__k | (~student@85.172.110.137) |