Newest at the top
| 2026-04-13 16:06:34 +0000 | <lambdabot> | "WHNF" |
| 2026-04-13 16:06:32 +0000 | <mauke> | > [error "x", error "y"] `seq` "WHNF" |
| 2026-04-13 16:06:20 +0000 | <lambdabot> | 2 |
| 2026-04-13 16:06:19 +0000 | <mauke> | > length [error "x", error "y"] |
| 2026-04-13 16:04:54 +0000 | <Milan_Vanca> | Ty guyz...I still don't fully understand. It's probably better to just continue learning. I will try to remember prevent accumulation of thunks. :) |
| 2026-04-13 16:01:52 +0000 | <[exa]> | Milan_Vanca: anyway you could implement some magical mark for "this has been deepseq'd" but there would be overhead and I don't see people going that way especially since the "right way" is to just make sure you don't accumulate too much thunk material in the first place |
| 2026-04-13 16:00:30 +0000 | danza | (~danza@user/danza) (Remote host closed the connection) |
| 2026-04-13 15:59:54 +0000 | jmcantrell_ | (~weechat@user/jmcantrell) (Ping timeout: 244 seconds) |
| 2026-04-13 15:58:07 +0000 | <[exa]> | and there's `n` such pointers. It's probably faster than the first deepseq esp. if the computation was "hard", but still `n` pointers. |
| 2026-04-13 15:57:43 +0000 | <[exa]> | Milan_Vanca: without traversing the pointer it is not sure if there's anything to evaluate, in turn it needs to traverse all of these pointers |
| 2026-04-13 15:57:05 +0000 | <[exa]> | Milan_Vanca: now, if you deepseq it again, the deepseq only sees: D1 --> (something unknown behind a pointer) |
| 2026-04-13 15:56:41 +0000 | <[exa]> | Milan_Vanca: if you deepseq it, you can get something like: D1 --> D2 --> D3 |
| 2026-04-13 15:56:18 +0000 | <[exa]> | Milan_Vanca: the unevaluated problem looks like: D1 --> Thunk1 |
| 2026-04-13 15:56:12 +0000 | <c_wraith> | Either prevent nested buildup of unevaluated expressions in the first place, or use an unlifted data type if you can't be bothered. |
| 2026-04-13 15:55:59 +0000 | <[exa]> | Milan_Vanca: ok so I'll draw a picture in IRC :D |
| 2026-04-13 15:54:45 +0000 | <mauke> | a two-element list looks like x1@((:) x2 x3@((:) x4 x5)). each of those x's can hide more unevaluated work |
| 2026-04-13 15:54:40 +0000 | <c_wraith> | My advice is to never actually use `rnf' in real code. It's a handy debugging tool if you can't find the source of unevaluated expressions in your program, but it's not a good solution. |
| 2026-04-13 15:52:46 +0000 | <c_wraith> | This isn't exactly automatic memoization, but it ends up sharing all the same issues. |
| 2026-04-13 15:51:44 +0000 | Guest62 | (~Guest62@p200300ca8f398000a276c2fd551b1612.dip0.t-ipconnect.de) |
| 2026-04-13 15:49:36 +0000 | <c_wraith> | Especially since it's not actually clear when that flag would be set. Would `rnf' need special RTS integration to set it specially? Would it check every time a value is evaluated if that makes some parent fully evaluated? |
| 2026-04-13 15:46:11 +0000 | <c_wraith> | Adding a state for "this has been fully evaluated" would add overhead to every single (lifted) value in memory |
| 2026-04-13 15:45:42 +0000 | <c_wraith> | right now, a value at run time has states for "this has been evaluated to a constructor" and "this hasn't been evaluated". |
| 2026-04-13 15:44:20 +0000 | <c_wraith> | I wouldn't call it a shortcoming |
| 2026-04-13 15:41:52 +0000 | <Milan_Vanca> | Yeah it is probably like that...there might not be need to evaluate further just the list |
| 2026-04-13 15:39:50 +0000 | <Milan_Vanca> | __monty__: I don't think so.. we write force longList1 so that evaluates it all the way down right? or maybe only to [thunk, thunk] from thunk:thunk and not [1, 2] ? |
| 2026-04-13 15:36:00 +0000 | <__monty__> | Wouldn't that end up with a traversal of all the NF datastructures known about instead of the datastructure you actually care about? |
| 2026-04-13 15:34:33 +0000 | <Milan_Vanca> | [exa]: And maybe picture would clarify it for me. Could you please draw a picture? |
| 2026-04-13 15:33:39 +0000 | <Milan_Vanca> | For that deepseq would need to be implemented in GHC and not just in term of seq maybe.. |
| 2026-04-13 15:32:26 +0000 | <Milan_Vanca> | Maybe it is infeasible to do so? |
| 2026-04-13 15:32:17 +0000 | <Milan_Vanca> | Isn't that "shortcoming" of GHC to not remember that recursive datastructure was evaluated to NF completly? |
| 2026-04-13 15:31:23 +0000 | v0id_7 | (~v0id_7@user/v0id-7:62772) v0id_7 |
| 2026-04-13 15:30:15 +0000 | slomp | (~slomp@47-158-199-90.lsan.ca.frontiernet.net) |
| 2026-04-13 15:29:39 +0000 | <[exa]> | (If confusing I can try to draw a picture :D ) |
| 2026-04-13 15:29:16 +0000 | <[exa]> | BUT you can memoize the result of `deepseq` in a `let` and then you can use as many times you want and it's always going to be memoized as fully evaluated. |
| 2026-04-13 15:27:54 +0000 | <[exa]> | (by having a head-normal data structure there's no way to tell if it points to a thunk, and the information that it was "already checked" isn't stored anywhere) |
| 2026-04-13 15:27:03 +0000 | <[exa]> | Milan_Vanca: the issue with `deepseq` is that it doesn't know if there's a thunk somewhere in the middle or not, so it has to traverse there again and again |
| 2026-04-13 15:26:12 +0000 | alter2000 | (~alter2000@user/alter2000) (Read error: Connection reset by peer) |
| 2026-04-13 15:25:51 +0000 | <Milan_Vanca> | longList; force longList should not traverse list 2 times |
| 2026-04-13 15:25:49 +0000 | <Milan_Vanca> | Hello I have found this statement in book "Evaluating something to normal form involves traversing the whole of its structure, so you should bear in mind that it is O(n) for a structure of size n, whereas seq is O(1). It is therefore a good idea to avoid repeated uses of force or deepseq on the same data." Is that correct? I thought that in ghc "results of evalutaions" are shared. So force |
| 2026-04-13 15:19:47 +0000 | Milan_Vanca | (~milan@user/Milan-Vanca:32634) Milan_Vanca |
| 2026-04-13 15:13:05 +0000 | slomp | (~slomp@47-158-199-90.lsan.ca.frontiernet.net) (Ping timeout: 245 seconds) |
| 2026-04-13 15:08:37 +0000 | sixfourtwelve | (~ethanmorg@static.82.129.225.46.clients.your-server.de) () |
| 2026-04-13 15:08:00 +0000 | synchromesh | (~john@2406:5a00:2412:2c00:2c29:cc68:8842:5c05) synchromesh |
| 2026-04-13 15:07:34 +0000 | slomp | (~slomp@47-158-199-90.lsan.ca.frontiernet.net) |
| 2026-04-13 15:06:37 +0000 | synchromesh | (~john@2406:5a00:2412:2c00:f13a:623d:2f3c:c3c6) (Read error: Connection reset by peer) |
| 2026-04-13 15:05:03 +0000 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) machinedgod |
| 2026-04-13 15:02:15 +0000 | fp1 | (~Thunderbi@87-95-80-117.bb.dnainternet.fi) (Read error: Connection reset by peer) |
| 2026-04-13 15:02:15 +0000 | danza | (~danza@user/danza) danza |
| 2026-04-13 15:01:29 +0000 | fp1 | (~Thunderbi@87-95-80-117.bb.dnainternet.fi) fp |
| 2026-04-13 14:55:05 +0000 | slomp | (~slomp@47-158-199-90.lsan.ca.frontiernet.net) (Ping timeout: 248 seconds) |