bug#6835: 23.2; eval'ing `type-of' with #[abc] as arg gets a Fatal error (11) Segmentation fault

[Kevin Rodgers <kevin.d.rodgers@gmail.com>]

Stefan Monnier wrote:
>> (functionp #[abc])
>> ⇒ t
> 
>> (funcall #[abc])
>> ⇒ Debugger entered--Lisp error: (invalid-function #[abc])
> 
>> Shouldn't anything that satisfies functionp be a valid argument to funcall?
> 
> Yes and no.  Should (lambda 3) be accepted by functionp?  What about
> (lambda () . 3) ?  What about (lambda () (+ . 1)) and other errors?

Hi Stefan,

I don't see why those examples should satisfy functionp.  The Elisp manual says:

  -- Function: functionp object
      This function returns `t' if OBJECT is any kind of function, i.e.
      can be passed to `funcall'.  Note that `functionp' returns `nil'
      for special forms (*note Special Forms::).

I think your examples are merely cons objects that look like lambda expressions
(a function subtype) but are not.

Note that type-of returns cons for both valid lambda expressions and those
examples, i.e. it does not distinguish special list structures as separate
types (e.g. alists, lambda expressions).  Likewise, type-of does not distinguish
obarrays from non-obarray vectors.

I think type-of should either return the most specific type that the object
satisfies or the most general type, but not the most specific for some things
(e.g. functions) and the most general for others (e.g. lists, vectors).

> #[abc] is an object of "function type", which is why functionp
> returns t.  I don't think that it's terribly important if when calling
> it, you get an error, since that can happen for syntactically valid
> functions as well.

But it is useful to know whether the error is signaled by funcall or
by the function.  And a careful programmer ought to be able to avoid
the former by guarding the funcall form with functionp.

-- 
Kevin Rodgers
Denver, Colorado, USA