Re: Distinguishing `consp` and `functionp`

[João Távora]

On Tue, Jan 30, 2024 at 12:54 PM Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> Yup.  My impression is that this is sufficiently rare that we can afford
> to break it.  Maybe experience will show me wrong, of course.

I've definitely seen users post configs to Eglot's bug tracker where
lambdas appear incorrectly quoted.  i.e.

  (add-to-list 'eglot-server-programs '(foo-mode . (lambda (..) ...)))

I try to always correct them,  but sometimes it'll just silently work until it
doesn't.

> We could also consider an intermediate step where `functionp` returns
> t but emits a warning.

Indeed, though in that case I'd make the funcall warn. I think it's there
that this proposed runtime warning  ultimately matters and is useful
to help users correct their elisp. Runtime warnings are a bit icky though
:-| but better than nothing.

> - it can give a wrong impression to a beginner, encouraging confusion.
> - it can occasionally hide an error, making debugging a bit more difficult.

Wouldn't you add "complicates type propagation, static analysis and
optimization" to that list?

> These seem very marginal to me.

I've definitely seen this error happen more than once:

(defun call-with-oopsie (fn) (funcall fn))

(defmacro with-oopsie (_nil &rest body)
  ;; usually some much more complicated hairy expansion
  `(call-with-oopsie '(lambda () ,@body)))

(defvar x 42)
(with-oopsie () (+ 42 x)) ;; 84, everything's fine, my macro is great

(let ((y 42)) (with-oopsie () (+ 42 y))) ;; oopsie...

The warning would have made the first call work but signal
something is off.

João