Re: Distinguishing `consp` and `functionp`

[João Távora]

On Mon, Jan 29, 2024 at 8:00 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The patch I sent doesn't change `functionp`, but indeed makes way for
> such a change (and changing `functionp` is the driving force behind it).

I've now briefly checked Common Lisp land.  Allegro CL is the
only one approaching Elisp's level of salad.  But at least functionp
does what you want it to do.

CL-USER> (funcall (list 'lambda nil 42))
42 (6 bits, #x2a, #o52, #b101010)
CL-USER> (functionp (list 'lambda nil 42))
NIL

But then there's the common pattern in libraries:

  (let ((value (if (functionp user-visible-variable)
                   (funcall user-visible-variable)
                 user-visible-variable)))
    ...)

Won't this break a user's config containing:

  (setq user-visible-variable '(lambda () 42))

?

> > Alright.  I wouldn't be surprised if I wasn't passing lists as lambdas
> > around in that extension.  I used to do that, and saw many fall prety
> > to this, when their lisps allow it.  The result is harder to debug code
> > and harder to instrument.
>
> I suspect all long-time Lispers have committed such sins at some point.
> I'm to blame for the godawful `vc-exec-after` example I sent earlier today.

I'd guess that's another class of blunder. Confusion about how lists
and lambda work is much more common in newcomers.

You can't forbid (funcall (list 'lambda)) without breaking lots of user
code, but do sth like coopt the existing "lexical-binding" variable to
introduce a  JS-like "strict mode".  I'm betting there's a correlation
between files with lexical-binding=nil and where these funcalls are
attempted or encouraged.

That's if you're interested in fixing this bit at all, which you don't
seem to be.

João