1. 21
  1.  

  2. 2

    I don’t understand the details, but now I want to build an elisp interpreter in Haskell. Maybe I’ll understand this better then?

    1. 1

      it doesn’t leak memory […] there is no freeing of unused memory

      pick one

      1. 2

        It reuses the memory for future allocations, like how if you have a vector and shrink it it won’t realloc itself to be smaller. Whether or not that counts as a leak depends on how you define it, I guess.

        1. 1

          That is no mastery. The interesting definition of ‘leak’ is that memory is not reclaimed in a pathological manner. The memory management glossary’s definition is also fine.

          A memory leak is where allocated memory is not freed although it is never used again.

          In manual memory management, this usually occurs because objects become unreachable without being freed.

          In tracing garbage collection, this happens when objects are reachable but not live.

          […]

          Repeated memory leaks cause the memory usage of a process to grow without bound.

          If I CONS, and then I make that cons unreachable, and then I CONS again, it should be possible that the memory used by the first cons is reused by the second. If there is no such possibility, then memory usage will grow over time without bound. An implementation for which this is true leaks memory.