Newest at the top
| 2026-04-09 12:10:24 +0000 | <merijn> | mauke: Well, if you wanna be pedantic it's "no longer makes unavailable for release" ;) |
| 2026-04-09 12:10:10 +0000 | <mauke> | haskell doesn't do timely destruction |
| 2026-04-09 12:10:09 +0000 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) machinedgod |
| 2026-04-09 12:09:58 +0000 | <mauke> | s/releases/makes available for release/ |
| 2026-04-09 12:09:38 +0000 | <merijn> | Milan_Vanca: But that's pretty much how it works in any garbage collected languages, that's not really specific to Haskell :) |
| 2026-04-09 12:09:12 +0000 | <merijn> | correct |
| 2026-04-09 12:09:04 +0000 | <Milan_Vanca> | I gues compiler sees that x is not used after one_hour_long and so releases it as soon as it finish printing of x? |
| 2026-04-09 12:08:02 +0000 | <Milan_Vanca> | Sorry to bother you with these stupid questions but I have found no tutorial on this matter. |
| 2026-04-09 12:07:44 +0000 | uli-fem | (~uli-fem@115.128.112.118) (Ping timeout: 268 seconds) |
| 2026-04-09 12:07:42 +0000 | <Milan_Vanca> | Will https://paste.tomsmeding.com/XLBvdfd1 will x be in memory while one_hour_long computation runs? |
| 2026-04-09 12:05:08 +0000 | <tomsmeding> | here x is a global variable, so it never goes out of scope, so it lives forever (until the GC decides that it's pointless keeping it around because nothing references it any more) |
| 2026-04-09 12:04:39 +0000 | <tomsmeding> | on a higher level: x is a monomorphic variable, so its value will live (once computed) until it goes out of scope -- or potentially for even longer if GHC decides so |
| 2026-04-09 12:04:37 +0000 | <merijn> | mauke: It's a CAF, those can be GCed just fine if nothing references them anymore |
| 2026-04-09 12:04:13 +0000 | <merijn> | mauke: Yes |
| 2026-04-09 12:03:50 +0000 | <tomsmeding> | they can be, yes |
| 2026-04-09 12:03:43 +0000 | <mauke> | are those ever released? |
| 2026-04-09 12:03:37 +0000 | <mauke> | also, x is a global variable |
| 2026-04-09 12:03:22 +0000 | <tomsmeding> | Milan_Vanca: the recursive function 'main' has a reference to x, and main stays alive (because it loops), so its reference to x also stays alive, so the GC does not remove x |
| 2026-04-09 12:02:41 +0000 | uli-fem | (~uli-fem@115.128.112.118) |
| 2026-04-09 12:02:21 +0000 | <tomsmeding> | apparently GHC does decide to keep `x` in your print x >> print x example; click Core here: https://play.haskell.org/saved/4XJoAJ1A |
| 2026-04-09 12:02:08 +0000 | <mauke> | import Debug.Trace (trace); x :: Int; x = trace "computing x" (4 + 1) |
| 2026-04-09 12:01:44 +0000 | <merijn> | `x` is not polymorphic and not "function-like" so the MMR doesn't apply |
| 2026-04-09 12:01:33 +0000 | <mauke> | you can test it, btw |
| 2026-04-09 12:01:18 +0000 | <merijn> | No |
| 2026-04-09 12:01:09 +0000 | <Milan_Vanca> | This must be recomputed multiple times right? |
| 2026-04-09 12:01:00 +0000 | <Milan_Vanca> | There is recursion.. and there is only one reference to x |
| 2026-04-09 12:00:44 +0000 | <Milan_Vanca> | I thought so.. what about this example https://paste.tomsmeding.com/C5RBYVCY |
| 2026-04-09 11:59:46 +0000 | <tomsmeding> | because once a value has no references to it any more, the garbage collector (GC) cleans it up |
| 2026-04-09 11:59:44 +0000 | <mauke> | yes |
| 2026-04-09 11:59:34 +0000 | <tomsmeding> | until you don't have any references to it any more |
| 2026-04-09 11:59:13 +0000 | <Milan_Vanca> | So basically If instead of X I allocated gigantic bytestring.. it would be ketp in memory for whole time program is running? |
| 2026-04-09 11:57:29 +0000 | <tomsmeding> | (there's enough unpredictability as it is) |
| 2026-04-09 11:57:11 +0000 | <tomsmeding> | there could be, if you interpret the semantics loosely, but that would result in extremely unpredictable performance and memory use and hence GHC does not do that |
| 2026-04-09 11:56:34 +0000 | <tomsmeding> | there's no "limited-time caching" going on |
| 2026-04-09 11:56:28 +0000 | <tomsmeding> | in general, whether a value is recomputed or not in haskell depends on the type of things and whether things are in the same scope, not how much code is in between the references |
| 2026-04-09 11:55:42 +0000 | <tomsmeding> | *so |
| 2026-04-09 11:55:40 +0000 | <tomsmeding> | yep, in that example x will be computed once, and it's clearer from the source that that is os |
| 2026-04-09 11:55:14 +0000 | <mauke> | Milan_Vanca: no, MR prevents recomputation of x |
| 2026-04-09 11:55:13 +0000 | <tomsmeding> | please read |
| 2026-04-09 11:55:11 +0000 | <tomsmeding> | Milan_Vanca: no, MR is enabled so x will NOT be recomputed |
| 2026-04-09 11:54:59 +0000 | <Milan_Vanca> | https://paste.tomsmeding.com/U94PhW5b |
| 2026-04-09 11:54:54 +0000 | <Milan_Vanca> | I haven't disabled it so I guess it is enabled and thus x will be recomputed... got it.. Had I done something like this |
| 2026-04-09 11:54:48 +0000 | <tomsmeding> | yeah |
| 2026-04-09 11:54:44 +0000 | <mauke> | except '4::Integer' is not actually expressible in Haskell; it's a native Integer literal |
| 2026-04-09 11:54:42 +0000 | <tomsmeding> | at which point the fromInteger is likely optimised away, but that's irrelevant to the point of whether things are computed once or more than once |
| 2026-04-09 11:54:16 +0000 | <mauke> | with MR on, it kinda desugars to 'x = fromInteger (4::Integer) :: Integer' :-) |
| 2026-04-09 11:53:53 +0000 | <tomsmeding> | x will get a monomorphic type here (probably defaulting to Integer) because MonomorphismRestriction is on by default |
| 2026-04-09 11:53:32 +0000 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-04-09 11:53:26 +0000 | <tomsmeding> | oh, mauke is right |
| 2026-04-09 11:53:01 +0000 | <mauke> | turning it off is a language extension |