[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6835: 23.2; eval'ing `type-of' with #[abc] as arg gets a Fatal error
bug#6835: 23.2; eval'ing `type-of' with #[abc] as arg gets a Fatal error (11) Segmentation fault
Tue, 10 Aug 2010 23:42:20 -0600
Thunderbird 188.8.131.52 (Macintosh/20100228)
Stefan Monnier wrote:
⇒ 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?
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.
Denver, Colorado, USA