4 ms·
I have a really dumb question about the Haskell GC, which I've never been brave enough to ask, but here goes: I thought everything in Haskell was immutable? If
by OskarS 10y ago
I have a really dumb question about the Haskell GC, which I've never been brave enough to ask, but here goes:
I thought everything in Haskell was immutable? If so, wouldn't that imply that it's impossible to create cyclic references (i.e. A and B can't both reference each other, because one of them has to be created first, and once created, it's immutable)?
Couldn't you then just use reference counting to decide when to recycle objects instead of having full-blown GC pauses? Or is it too expensive to keep a reference count on all those objects and keep it updated? Whatever cost it has, it seems much more preferable to me compared to 50 ms GC pauses for relatively simple code.
- cordite 10y agoUsually copying is only to compact everything alive back together for cache friendliness. However, it shouldn't need a stop the world for that due to immutability.
- deleted 10y ago[deleted]
- openasocket 10y agoNot a dumb question at all! You can create cycles in Haskell thanks to lazy evaluation. I can make a circular list in Haskell with the following: x :: [Int] x = 0 : y y :: [Int] y = 1 : x And thus we have a circular list with the elements 0 and 1. It's technically an infinite-length list with 0 and 1 repeating forever, but Haskell will represent this in memory as a circular list.
- OskarS 10y agoAh, I see, I figured that there might be some case like that. I would have expected that to be a compile-time error because `y` is an unrecognized identifier by the time `x` is defined, but I guess it makes sense with lazy evaluation to not make that kind of ordering matter.
- hood_syntax 10y agoYeah, all definitions are module level unless they are scoped in let or where blocks (someone correct me if I'm mistaken)
- tener 10y agoLazy evaluation is not important item here. It is merely the semantics is defined in a way that the order of declarations does not matter. Other languages have this property too - say, C# (not entirely true, but pretty close - at least if you think about top level methods etc.). Also an example where the order of declarations does not matter at all, because there is just one declaration: x :: [Integer] x = 0 : 1 : x
- tel 10y agoIt ought to, yes. More specifically, immutability means that you cannot observe sharing. What this means is that it's easy to break sharing and if you rely on it for performance you might face difficulties. But you can create it. Names are shared: let x = [1, 2, 3] in [x, x, x] There are more exotic ways, too.
- Ono-Sendai 10y agoYes you are correct, for statically typed (and not lazy) functional languages. In this case Ref counting will work fine since you can't create cycles. See http://www.forwardscattering.org/post/47 http://www.forwardscattering.org/post/47
- dllthomas 10y agoThe key thing missing from the responses so far is that laziness is a (particularly constrained) kind of mutability.