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

[Tomas Hlavaty]

On Tue 17 Nov 2020 at 09:32, Drew Adams <drew.adams@oracle.com> wrote:
>> `thunk-force' is equivalent to `funcall' - thunks are functions.  I
>> wonder if we could/should officially document that fact?

> FWIW, that makes sense to me.  Why not tell users this?
> It's fine to have an abstraction, but in Lisp it can
> help to know the implementation, especially in a
> straightforward case like this.

what is the reason for thunk.el in the first place?

it is not used in emacs at all.

it does not work in buffers without lexical-binding:

   (setq delayed (thunk-delay (message "this message is delayed")))
   (thunk-force delayed)
   -> Debugger entered--Lisp error: (void-variable forced)

   (setq lexical-binding t)
   (setq delayed (thunk-delay (message "this message is delayed")))
   (thunk-force delayed)
   -> "this message is delayed"

(this is probably general problem with macros which assume
lexical-binding)

thunk is about delaying computation.  thunk.el mixes in memoization.

it obscures the essence:

   (setq delayed (lambda () (message "this message is delayed")))
   (funcall delayed)

memoization would be better separate:

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

(let* ((i 0)
       (f (lambda () (message "hi %d" (incf i)))))
  (funcall f)
  (funcall f)
  (funcall f))

(let* ((i 0)
       (f (memoize (lambda () (message "hi %d" (incf i))))))
  (funcall f)
  (funcall f)
  (funcall f))