Re: Distinguishing `consp` and `functionp`

[Stefan Monnier <monnier@iro.umontreal.ca>]

> It sure seems to suggest many many others do the same: start by
> calling functionp.

Indeed, the current representation of interpreted functions tends to
encourage it.

> Won't they _all_ be broken if users have been
> putting lists in those user vars by mistake?

Could be.  That's one of the reasons why my patch doesn't change
`functionp` (yet).

> One thing it'd be nice to have for runtime warnings is some kind of
> file location hint.

Alan has plans to work on that, tho I strongly suspect that it won't
help for this problem: the functions for which we need this info are the
functions which Emacs thought were lists, so Alan's plan to try and keep
some source info along with function wouldn't help here (unless we keep
source info for cons cells, which I guess could be a possibility: it
would be expensive to do for all cons cells read from files, but if we
limit it to cons cells whose `car` is `lambda` is might even be doable).

> Maybe check the calling frame?

I suspect that most cases will look like your Eglot example, where by
the time you get to the `funcall/functionp` the backtrace doesn't
immediately tell you where that function comes from (it can still be
helpful info to trace it back, but it may require digging into someone
else's code).

> Dunno.  SBCL's compiler is pretty good, it propagates types  and warns
> say, when using generic+ instead of must faster fixum+.

Knowing "this is a function" isn't terribly better than "this is
either a function or a cons cell starting with `lambda`": it will rarely
let you turn a generic+ into a fixnum+.


        Stefan