Not 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.

Ah, 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.

Lazy 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

Yeah, all definitions are module level unless they are scoped in let or where blocks (someone correct me if I'm mistaken)

It 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.

The key thing missing from the responses so far is that laziness is a (particularly constrained) kind of mutability.

Yes 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

Usually 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.