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

[MON KEY]

> GNU Emacs 23.2.1 (i386-apple-darwin8.11.1, NS apple-appkit-824.48) of
> 2010-05-14
> and
> GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600) of 2010-05-08
> don't crash, but they both produce these results:

I'm able to reproduce this w/ 23.2 on a second machine:

"GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.14.7)
 of 2010-05-10"

> Shouldn't anything that satisfies functionp be a valid argument to
> funcall?

I think it is the wrong question.

Why can't/shouldn't the `#' read restrictions be made less
"complicated"?

> Shouldn't the COMPILEDP macro in lisp.h be more strict about the
> number and type of vector elements?  The "Byte-Code Function
> Objects" node of the Elisp manual says:

Yes well, this may bring us circuitously semi-circle to bug#6486
(URL `http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-06/msg00486.html')

Abstractly, I just don't understand the rationale for the nuanced
restrictions placed on the reader w/re `#'. It seems to cause just as
many "complicated problems" as presumably it was intended to solve.

Moreover, we now have a new hash-table read-syntax so... WTF?

,---- (info "(elisp)Creating Hash")
|    You can also create a new hash table using the printed
| representation for hash tables.  The Lisp reader can read this
| printed representation, provided each element in the specified hash
| table has a valid read syntax (see Printed Representation).  For
| instance, the following specifies a new hash table containing the
| keys `key1' and `key2' (both symbols) associated with `val1' (a
| symbol) and `300' (a number) respectively.
|
|      #s(hash-table size 30 data (key1 val1 key2 300))
`----

(setq bubbas-hash #s(hash-table size 30 data (key1 val1 key2 300)))
;=> #s(hash-table {...} ))

bubbas-hash
;=> #s(hash-table {...} ))

(gethash 'key1 bubbas-hash)
;=> val1

(type-of (symbol-value 'bubbas-hash))
;=> hash-table

IOW, I can successfully interrogate a hash-table type and this
pathological corner-case too:

(type-of #'(lambda))
;=> cons

but woe be it to she who slips up and does:

(type-of #[say goodbye to your current-session ... now])

Which reminds me, how are the the Guile folks planning on handling
this with Guile-Elisp?

There may be some _nasty_ bugs/headaches working around the current
elisp reader restrictions e.g. #t and #f and more specifically
#:keywords.

Following from a fairly recent draft of the Guile manual:

,----
| (read-set! keywords 'prefix)
|
| #:type
| ;=> #:type
|
| :type
| ;=> #:type
|
| (read-set! keywords 'postfix)
| type:
| ;=> #:type
|
| :type
| ;=> :type
|
| (read-set! keywords #f)
| #:type
| ;=> #:type
`----

Did you catch that last one?
We eval #f -- the Scheme equivalent of nil and/or '(); and we get a
potentially bogus error prone elisp on return.

Whoopee. Looks likes someone's syntactic jujitsu (most likely born of
political infighting and vengeful bone to pick) might wind up biting
back 20+ years later.

> Kevin Rodgers

--
/s_P\