From: MON KEY <monkey@sandpframing.com>
To: 6835@debbugs.gnu.org
Cc: kevin.d.rodgers@gmail.com
Subject: bug#6835: 23.2; eval'ing `type-of' with #[abc] as arg gets a Fatal error (11) Segmentation fault
Date: Tue, 10 Aug 2010 02:47:39 -0400 [thread overview]
Message-ID: <AANLkTi=DqTNGAHgaUAPLNg5zOzxXp6=OcrPcQn5+WTRR@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimMCR0hLpsV+f9FL1ehL3zkJHxuEFUn-nzUqj+U@mail.gmail.com>
> 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\
next prev parent reply other threads:[~2010-08-10 6:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-10 1:04 bug#6835: 23.2; eval'ing `type-of' with #[abc] as arg gets a Fatal error (11) Segmentation fault MON KEY
2010-08-10 3:23 ` Kevin Rodgers
2010-08-10 8:27 ` Stefan Monnier
2010-08-11 5:42 ` Kevin Rodgers
2010-08-11 20:20 ` Stefan Monnier
2010-08-10 6:47 ` MON KEY [this message]
2010-08-10 21:14 ` Andreas Schwab
2010-08-12 0:12 ` MON KEY
2010-08-12 7:56 ` Andreas Schwab
2010-08-15 23:45 ` bug#6835: bug#6855: 24.0.50; Bug in tool bar label handling MON KEY
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTi=DqTNGAHgaUAPLNg5zOzxXp6=OcrPcQn5+WTRR@mail.gmail.com' \
--to=monkey@sandpframing.com \
--cc=6835@debbugs.gnu.org \
--cc=kevin.d.rodgers@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).