Re: Distinguishing `consp` and `functionp`

[Daniel Mendler]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Rather I'm annoyed at the corner cases where
>>>
>>>     (functionp (mapcar ...))
>>>
>>> can occasionally return t, simply because the returned list happens to
>>> start with the symbol `closure` or `lambda`.
>>
>> So you want this to return nil, but still allow 'funcall' of
>> said returned lists?
>
> That's right: for compatibility reasons, I think we have to support the
> `funcall` case for the foreseeable future (and really, it costs very
> little to do so), but I think the `functionp` case doesn't need that
> level of backward compatibility.

What about only dropping the list-based closure representation as a
first step, switching it over to a vector-based one?

(functionp '(closure (t) nil t)) => nil (currently t)
(funcall   '(closure (t) nil t)) => error (currently t)

Unfortunately quoted lambdas are still common in packages which have not
been updated for longer. Don't you intent to preserve the following
coherent behavior of functionp and funcall?

(functionp '(lambda () t)) => t
(funcall   '(lambda () t)) => t

Would it make sense to introduce a byte compiler warning, triggered if a
quoted lambda is detected? There will be occasional false positives
however.

>         Stefan