Re: thunk.el: Document that thunk-force == funcall?

[Tomas Hlavaty <tom@logand.com>]

On Thu 19 Nov 2020 at 12:50, Mattias Engdegård <mattiase@acm.org> wrote:
> 19 nov. 2020 kl. 00.25 skrev Tomas Hlavaty <tom@logand.com>:
>
>> interesting drawback of thunk.el implementation is that thunk-delay does
>> not allow that and whatever is captured stays captured even after
>> thunk-force.
>
> Not after byte-compilation. The interpreter is very conservative when
> creating closures but the compiler makes more of an effort to capture
> only variables actually used.

this has nothing to do with an effort to capture only variables actually
used

the problem is that current implementation of thunk-delay has memory
leak built-in by design and does not release captured values.

those are captured in the lambda due to ,@body and references to these
captured values are never released.  it is not even possible to
explicitly release those values because it is not known what exactly is
captured.

(let ((huge-data (make-list (expt 2 60))))
  (setq delayed (thunk-delay (count huge-data)))
  ;; huge-data captured by delayed, needed to compute the delayed value
  (thunk-force delayed))
(garbage-collect)
;; huge-data still captured by delayed even though it is not needed anymore

this is bug in thunk-delay

having garbage collection does not eliminate memory leaks

fix would separate thunk and memoization and release the thunk when not
needed anymore:

(let ((void (list nil)))
  (defun memoize (thunk)
    (let ((z void))
      (lambda ()
        (when (eq z void)
          (setq z (funcall thunk)
                thunk nil))
        z))))

(defmacro thunk-delay (&rest body)
  `(memoize (lambda () ,@body)))

at that point thunk-delay is pretty much redundant and it is better not
to pretend that thunk is thunk+memoization and just teach people what
thunk really is (it is just a lambda with zero arguments)

minor note: the example in thunk.el would then also work in buffers
without lexical-binding enabled