3 ms·
> With immutable objects, forward references aren't possible. This aligns well with a tree of backup objects (immutable append-only acyclic graph data structur
by MaxBarraclough 6y ago
> With immutable objects, forward references aren't possible.
This aligns well with a tree of backup objects (immutable append-only acyclic graph data structure) but this approach wouldn't work for general programming, right?
My understanding is that LISP's letrec and the equivalent in other functional languages, means that even seemingly immutable abstractions aren't really immutable from the point of view of the GC, and cycles are a possibility. I don't think it would be possible to properly implement Haskell using ordinary reference-counting, for instance. The purity of the language wouldn't save you from reference-cycles.
See also: https://stackoverflow.com/q/791437/ https://stackoverflow.com/q/791437/
- reitzensteinm 6y agoRight, that's true that it's possible to "tie the knot" with laziness and build circular or self references in functional languages. I didn't mean to make a claim that extended past the limits of the system I built and it's important to note that.
- MaxBarraclough 6y ago> that's true that it's possible to "tie the knot" with laziness and build circular or self references in functional languages I wonder if it would be possible to construct a practical functional language that never does so. I imagine not. > I didn't mean to make a claim that extended past the limits of the system I built I don't think you did, I was just wondering how much further the idea could be taken.