Newest at the top
| 2025-01-10 14:30:08 +0100 | LearnHaskell69 | (~LearnHask@88.197.71.220) |
| 2025-01-10 14:29:51 +0100 | mange | (~user@user/mange) (Quit: Zzz...) |
| 2025-01-10 14:29:39 +0100 | LearnHaskell26 | (~LearnHask@88.197.71.220) (Client Quit) |
| 2025-01-10 14:29:33 +0100 | iamsleepy | (~weechat@2a01:4f9:3070:feff:bd6e:6edf:b3ad:783f) iamsleepy |
| 2025-01-10 14:29:25 +0100 | LearnHaskell26 | (~LearnHask@88.197.71.220) |
| 2025-01-10 14:28:17 +0100 | iamsleepy | (~weechat@2a01:4f9:3070:feff:e108:469f:fb3b:55a7) (Ping timeout: 248 seconds) |
| 2025-01-10 14:26:59 +0100 | jespada | (~jespada@2800:a4:161:4200:1503:f643:a41c:4d0c) jespada |
| 2025-01-10 14:25:59 +0100 | jespada | (~jespada@2800:a4:161:4200:1503:f643:a41c:4d0c) (Client Quit) |
| 2025-01-10 14:25:58 +0100 | rynite | (~bwkam@user/rynite) rynite |
| 2025-01-10 14:25:25 +0100 | son0p | (~ff@2800:e6:4001:6cc3:2e2c:4b4e:bc2a:6f17) son0p |
| 2025-01-10 14:24:44 +0100 | jespada | (~jespada@2800:a4:161:4200:1503:f643:a41c:4d0c) jespada |
| 2025-01-10 14:22:26 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
| 2025-01-10 14:15:55 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-01-10 14:03:40 +0100 | LearnHaskell | (~LearnHask@88.197.71.220) |
| 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) |