GNU bug report logs - #7146
(make-symbol "") issues

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7146 in the body.
You can then email your comments to 7146 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Frank <some.frank <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: (make-symbol "") issues
Date: Fri, 01 Oct 2010 22:19:10 -0600

;;; "GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600) of 2010-05-08 on G41R2F1"

;; When I byte compile this file and load it and try to evaluate (foo)
;; Emacs will either crash or (foo) returns some odd number on my machine.

(defmacro bar (&rest body)
 (let ((v (make-symbol "")))         ; Crashes with "" as name.
   `(let ((,v (catch :eof
        ,@body)))

      (when (not (eq ,v :eof))
    ,v))))

(defun foo ()
 (bar (message "Hello World!")))


;; (disassemble 'foo)
;;
;; byte code for foo:
;;   args: nil
;; 0    constant  (message "Hello World!")
;; 1    constant  (out-of-range 2)
;; 2    catch
;; 3    dup
;; 4    varbind      #::eof
;; 5    constant  (message "Hello World!")
;; 6    eq
;; 7    not
;; 8    goto-if-nil-else-pop 1
;; 11    varref      #::eof
;; 12:1    unbind      1
;; 13    return
;;
;; Looks like there's a problem in line 4 & 11.

Message #8 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Frank <some.frank <at> gmail.com>
To: 7146 <at> debbugs.gnu.org
Subject: (make-symbol "") issues
Date: Sat, 02 Oct 2010 18:44:19 -0600

Well I further found out that you have to actually (byte-compile-file) 
the above code in order for the bug to show up; compiling via 
(compile-defun) seems to work OK;

Message #11 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Frank <some.frank <at> gmail.com>
Cc: 7146 <at> debbugs.gnu.org
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sat, 02 Oct 2010 21:32:03 -0400

Frank <some.frank <at> gmail.com> writes:

> Well I further found out that you have to actually (byte-compile-file)
> the above code in order for the bug to show up; compiling via
> (compile-defun) seems to work OK;

I can't reproduce this.  Could you detail the *exact* steps you took,
starting with `emacs -Q'?  Your description is too vague.

Message #14 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Frank <some.frank <at> gmail.com>
Cc: 7146 <at> debbugs.gnu.org
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sun, 03 Oct 2010 00:05:52 -0400

Frank <some.frank <at> gmail.com> writes:

> 1) Start `emacs -Q'
> 2) Load the file bug.el into a buffer via the menu
> 3) <M-x> byte-compile-file
> 4) <M-x> load-file bug.elc
> 5) <C-x b> *scratch*
> 6) (foo) *** emacs crashes or foo returns some odd number ***

I assume by (foo) you mean typing "(foo)" and doing C-j or C-x C-e.

I'm afraid I don't see any crash.  The number 6 appears in the echo
area, that's all.

Message #17 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Frank <some.frank <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7146 <at> debbugs.gnu.org
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sat, 02 Oct 2010 21:44:00 -0600

[Message part 1 (text/plain, inline)]

Chong Yidong schrieb:

>Frank <some.frank <at> gmail.com> writes:
>
>  
>
>>Well I further found out that you have to actually (byte-compile-file)
>>the above code in order for the bug to show up; compiling via
>>(compile-defun) seems to work OK;
>>    
>>
>
>I can't reproduce this.  Could you detail the *exact* steps you took,
>starting with `emacs -Q'?  Your description is too vague.
>
>  
>
1) Start `emacs -Q'
2) Load the file bug.el into a buffer via the menu
3) <M-x> byte-compile-file
4) <M-x> load-file bug.elc
5) <C-x b> *scratch*
6) (foo) *** emacs crashes or foo returns some odd number ***

(disassemble 'foo) looks like this (done between point 5 and 6)

byte code for foo:
 args: nil
0    constant  (message "Hello World!")
1    constant  (out-of-range 2)
2    catch     
3    dup     
4    varbind      :eof
5    constant  (message "Hello World!")
6    eq     
7    not     
8    goto-if-nil-else-pop 1
11    varref      :eof
12:1    unbind      1
13    return     

I attached the file I used for testing this and also it's byte compilation

[bug.elc (application/octet-stream, attachment)]

[bug.el (text/plain, inline)]

(defmacro bar (&rest body)
 (let ((v (make-symbol "")))         ; Crashes with "" as name.
   `(let ((,v (catch :eof
        ,@body)))

      (when (not (eq ,v :eof))
    ,v))))

(defun foo ()
 (bar (message "Hello World!")))

Message #20 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Frank <some.frank <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7146 <at> debbugs.gnu.org
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sat, 02 Oct 2010 22:14:53 -0600

Chong Yidong schrieb:

>Frank <some.frank <at> gmail.com> writes:
>
>  
>
>>1) Start `emacs -Q'
>>2) Load the file bug.el into a buffer via the menu
>>3) <M-x> byte-compile-file
>>4) <M-x> load-file bug.elc
>>5) <C-x b> *scratch*
>>6) (foo) *** emacs crashes or foo returns some odd number ***
>>    
>>
>
>I assume by (foo) you mean typing "(foo)" and doing C-j or C-x C-e.
>
>I'm afraid I don't see any crash.  The number 6 appears in the echo
>area, that's all.
>
>  
>
Yes I type (foo) in the *scratch* buffer and then <C-x C-e>

Well if everything runs good then "Hello World" should appear in the 
echo area, everything else is wrong!!!

As I said sometimes it crashes, sometimes it returns some number!

Message #23 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7146 <at> debbugs.gnu.org, Frank <some.frank <at> gmail.com>
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sun, 3 Oct 2010 06:36:31 +0200

On Sun, Oct 3, 2010 at 06:05, Chong Yidong <cyd <at> stupidchicken.com> wrote:

> I'm afraid I don't see any crash.  The number 6 appears in the echo
> area, that's all.

I see it on Windows, with the current trunk.

    Juanma


Program received signal SIGSEGV, Segmentation fault.
0x0102bfb6 in find_symbol_value (symbol=2) at data.c:1059
1059      switch (sym->redirect)
(gdb) bt
#0  0x0102bfb6 in find_symbol_value (symbol=2) at data.c:1059
#1  0x0102c150 in Fsymbol_value (symbol=2) at data.c:1082
#2  0x01038edf in Feval (form=2) at eval.c:2231
#3  0x01036eef in internal_catch (tag=53471294, func=0x1038eb2
<Feval>, arg=2) at eval.c:1204
#4  0x01283183 in Fbyte_code (bytestr=74807729, vector=50925637,
maxdepth=12) at bytecode.c:854
#5  0x0103c9e7 in funcall_lambda (fun=50106437, nargs=0,
arg_vector=0x88f1b0) at eval.c:3174
#6  0x0103c41d in apply_lambda (fun=50106437, args=48474138,
eval_flag=1) at eval.c:3100
#7  0x01039eed in Feval (form=74931054) at eval.c:2394
#8  0x0103bb72 in Ffuncall (nargs=2, args=0x88f3f4) at eval.c:2990
#9  0x0128285f in Fbyte_code (bytestr=21103025, vector=21103077,
maxdepth=12) at bytecode.c:679
#10 0x0103c9e7 in funcall_lambda (fun=21102989, nargs=1,
arg_vector=0x88f624) at eval.c:3174
#11 0x0103c0f9 in Ffuncall (nargs=2, args=0x88f620) at eval.c:3036
#12 0x0128285f in Fbyte_code (bytestr=21103369, vector=21103421,
maxdepth=12) at bytecode.c:679
#13 0x0103c9e7 in funcall_lambda (fun=21103341, nargs=1,
arg_vector=0x88f8a4) at eval.c:3174
#14 0x0103c0f9 in Ffuncall (nargs=2, args=0x88f8a0) at eval.c:3036
#15 0x01281929 in Fcall_interactively (function=49029794,
record_flag=48474138, keys=48495365) at callint.c:849
#16 0x0103bcb2 in Ffuncall (nargs=4, args=0x88fb30) at eval.c:2996
#17 0x0103b10f in call3 (fn=48643962, arg1=49029794, arg2=48474138,
arg3=48474138) at eval.c:2820
#18 0x0102294e in Fcommand_execute (cmd=49029794,
record_flag=48474138, keys=48474138, special=48474138) at
keyboard.c:10330
#19 0x0100863d in command_loop_1 () at keyboard.c:1737
#20 0x010374d0 in internal_condition_case (bfun=0x1007058
<command_loop_1>, handlers=48527722, hfun=0x100678d <cmd_error>) at
eval.c:1460
#21 0x01006c63 in command_loop_2 (ignore=48474138) at keyboard.c:1338
#22 0x01036eef in internal_catch (tag=48525842, func=0x1006c40
<command_loop_2>, arg=48474138) at eval.c:1204
#23 0x01006c1b in command_loop () at keyboard.c:1317
#24 0x01005e7f in recursive_edit_1 () at keyboard.c:940
#25 0x010063a3 in Frecursive_edit () at keyboard.c:1002
#26 0x010026af in main (argc=2, argv=0xb72c50) at emacs.c:1718

Lisp Backtrace:
"foo" (0x88f1b0)
"eval" (0x88f3f8)
"eval-last-sexp-1" (0x88f624)
"eval-last-sexp" (0x88f8a4)
"call-interactively" (0x88fb34)
(gdb)

Message #26 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Johan Bockgård <bojohan <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7146 <at> debbugs.gnu.org, Frank <some.frank <at> gmail.com>
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sun, 03 Oct 2010 12:28:55 +0200

Chong Yidong <cyd <at> stupidchicken.com> writes:

> Frank <some.frank <at> gmail.com> writes:
>
>> 1) Start `emacs -Q'
>> 2) Load the file bug.el into a buffer via the menu
>> 3) <M-x> byte-compile-file
>> 4) <M-x> load-file bug.elc
>> 5) <C-x b> *scratch*
>> 6) (foo) *** emacs crashes or foo returns some odd number ***
>
> I assume by (foo) you mean typing "(foo)" and doing C-j or C-x C-e.
>
> I'm afraid I don't see any crash.  The number 6 appears in the echo
> area, that's all.

The problem is that there is no read syntax for a symbol with an empty
name, so it can't reliably be printed to a string (file) and read back.

  (symbol-name (aref [#: x] 0)) => "x" ; This is what happens in the report.

  but (symbol-name (aref [#:] 0)) => ""

You could change the reader to somehow recognize the first case. The
problem would come back if you changed `make-symbol' to `intern',
though, since it really prints as nothing at all.

Message #29 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Frank <some.frank <at> gmail.com>
Cc: 7146 <at> debbugs.gnu.org
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sun, 03 Oct 2010 10:55:17 -0400

Johan Bockgård <bojohan <at> gnu.org> writes:

> The problem is that there is no read syntax for a symbol with an empty
> name, so it can't reliably be printed to a string (file) and read back.
>
>   (symbol-name (aref [#: x] 0)) => "x" ; This is what happens in the report.
>
>   but (symbol-name (aref [#:] 0)) => ""
>
> You could change the reader to somehow recognize the first case. The
> problem would come back if you changed `make-symbol' to `intern',
> though, since it really prints as nothing at all.

I guess we could make intern and make-symbol signal errors for the empty
string.

Message #32 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: 7146 <at> debbugs.gnu.org
Cc: Chong Yidong <cyd <at> stupidchicken.com>
Subject: bug#7146: (make-symbol "") issues
Date: Sun, 3 Oct 2010 14:45:39 -0400

Chong Yidong wrote:

> I guess we could make intern and make-symbol signal errors for the empty
> string.

That would be great!

So, IIUC is the rationale for doing this is that there aren't really
any particularly
good reasons to intern the empty string given that the reader is incapable of
reading it correctly? If so, maybe, along similar (inverted) lines the forms:

 (make-symbol "nil")/(intern-soft "nil")(intern "nil")

should signal errors as well?

I.e as it's impossible to correctly re-intern (with read or otherwise) an
uninterned `nil' there should be no reason that one should need to
make-symbol/intern-soft/intern "nil" either?

Note however there is this:
bug#5672: 23.1; (intern-soft "") returns non-nil
(URL `http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-03/msg00026.html')

Which may not comport with your decision to have
`intern'/`make-symbol' signal error.
In bug#5672 Stefan states that interning the empty string is not a bug
because it might not always be done purposefully (IIUC).

But note there is this more recent discussion:

Date: 	Sat, 11 Sep 2010 19:33:07 -0400
Subject: Save `nil' from the mutant void, preserve the truth of
	 falsehood, prevent the falsehood of truth
(URL `http://lists.gnu.org/archive/html/emacs-devel/2010-09/msg00464.html')

Where it is pointed out that `intern-soft'ing the emtpy string with e.g.:

 (prog1 #1=(intern-soft "") (unintern #1#))

is potentially problematic (at either compile or runtime).

Note that the new `unintern' semantics requiring provision of an
`obarray' account
for some part of the problem. (This said, IMHO I still consider the form above a
source of myriad potential security holes and abuse, new obarray
semantics or no.)

Whatever, b/c is difficult to prove formally that these potentialities for abuse
exist without dialogue them publicly and b/c doing so is currently an
exercise in self-flagellation given the absence of a willingness for honest
public examination of the shortcomings of the Elisp reader the best one can do
is hint at their possible implementation and home someone "gets it"...

From from the same thread:
(URL `http://lists.gnu.org/archive/html/emacs-devel/2010-09/msg00494.html')

There is also this example (relevant to the current bug) which provides an
illustration of the vagaries of `intern-soft' w/re the empty string.

The more salient portion included below for completeness:

,----
|
| > since `intern' only takes a string rather than a symbol.
|
| Yeah, but again there is the weird corner case of interning the 0
| length string.  Which, as shown in previous mail causes additional
| headaches when attempting to re-intern a symbol.
|
|
| emacs -Q
|
| (prin1
| (let ((s1 (intern (symbol-name (make-symbol ""))))
|      (s2 (intern (symbol-name '#:)))
|      cmp)
|  (setq cmp `((,#1=s1 ,#1#) (,#2=s2 ,#2#)))
|  `(:S1-LEN ,(length (car cmp))
|    :S1-LEN ,(length (cadr cmp))
|    :S1-IS-S1 ,(eq (caar cmp) (car (cdar cmp)))
|    :S2-IS-S2 ,(eq (car (cadr cmp)) (cadr (cadr cmp)))
|    :CAR-S1-IS-CAR-S2 ,(eq (caar cmp) (car (cadr cmp)))
|    :CADR-S1-IS-CADR-S2 ,(eq (car (cdar cmp)) (cadr (cadr cmp)))
|    :S1-IDENTITY ,(identity s1)
|    :S1-IDENTITY ,(identity s1)
|    :S1-SYM-NAME ,(symbol-name s1)
|    :S2-SYM-NAME ,(symbol-name s2)
|    :S2-UNINTD   ,(unintern (car (cadr cmp)))
|    :S1-UNINTD   ,(unintern (caar cmp))))
| (current-buffer))
|
| (:S1-LEN 2 :S1-LEN 2
|  :S1-IS-S1 t :S2-IS-S2 t
|  :CAR-S1-IS-CAR-S2 t :CADR-S1-IS-CADR-S2 t
|  :S1-IDENTITY  :S1-IDENTITY  ;; <- Note, that _is_ an identity
|  :S1-SYM-NAME "" :S2-SYM-NAME ""
|  :S2-UNINTD t :S1-UNINTD nil)
|
`----

Maybe too, `make-symbol' and `intern' should also have mandatory
obarray arguments in keeping with the new semantics for `unintern'?

--
/s_P\

Message #35 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 7146 <at> debbugs.gnu.org
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sun, 03 Oct 2010 14:56:53 -0400

MON KEY <monkey <at> sandpframing.com> writes:

> So, IIUC is the rationale for doing this is that there aren't really
> any particularly good reasons to intern the empty string given that
> the reader is incapable of reading it correctly?

The only reason is that it can lead to a crash.  There are plenty of
reasons to shoot yourself in the foot in Lisp in you're determined to do
so; it's not profitable to address them unless a real world problem
surfaces.

Message #38 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7146 <at> debbugs.gnu.org, Frank <some.frank <at> gmail.com>
Subject: Re: bug#7146: (make-symbol "") issues
Date: Mon, 04 Oct 2010 01:12:36 +0200

> I guess we could make intern and make-symbol signal errors for the empty
> string.

No, we should make them write some non-empty representation.


        Stefan

Message #41 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7146 <at> debbugs.gnu.org
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sun, 3 Oct 2010 19:48:51 -0400

On Sun, Oct 3, 2010 at 2:56 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> MON KEY <monkey <at> sandpframing.com> writes:
>
>> So, IIUC is the rationale for doing this is that there aren't really
>> any particularly good reasons to intern the empty string given that
>> the reader is incapable of reading it correctly?
>

> The only reason is that it can lead to a crash.

So the potential for a crashed Emacs is rationale enough, whereas
potential for an inexplicably hung and thoroughly corrupted Emacs is
just grist for the mill?

>  There are plenty of
> reasons to shoot yourself in the foot in Lisp in you're determined to do

And a good deal of these apply equally even for the undetermined and
un-intentioned, not to mention the ill-intentioned.

> so; it's not profitable to address them unless a real world problem
> surfaces.
>

OK.

--
/s_P\

Message #44 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7146 <at> debbugs.gnu.org, Frank <some.frank <at> gmail.com>,
	Chong Yidong <cyd <at> stupidchicken.com>
Subject: Re: bug#7146: (make-symbol "") issues
Date: Thu, 14 Jul 2011 16:25:06 +0200

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

>> I guess we could make intern and make-symbol signal errors for the empty
>> string.
>
> No, we should make them write some non-empty representation.

Even though this is obscure, this is a bug that can crash (some builds
of) Emacs.  So I rather think this should be fixed.  Was any work done
towards adding a printed representation of empty-string symbols?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #47 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 7146 <at> debbugs.gnu.org, Frank <some.frank <at> gmail.com>,
	Chong Yidong <cyd <at> stupidchicken.com>,
	Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#7146: (make-symbol "") issues
Date: Thu, 14 Jul 2011 18:24:13 +0200

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:

> Even though this is obscure, this is a bug that can crash (some builds
> of) Emacs.  So I rather think this should be fixed.  Was any work done
> towards adding a printed representation of empty-string symbols?

What would be a good mnemonic?  We need two different representations
(interned and uninterned), perhaps ## and #= ?

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #50 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 7146 <at> debbugs.gnu.org, Frank <some.frank <at> gmail.com>,
	Lars Magne Ingebrigtsen <larsi <at> gnus.org>,
	Chong Yidong <cyd <at> stupidchicken.com>
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sat, 16 Jul 2011 23:16:02 -0400

>> Even though this is obscure, this is a bug that can crash (some builds
>> of) Emacs.  So I rather think this should be fixed.  Was any work done
>> towards adding a printed representation of empty-string symbols?
> What would be a good mnemonic?  We need two different representations
> (interned and uninterned), perhaps ## and #= ?

"#:" is the obvious choice for the uninterned representation.
It already works for printing, but is not understood by the reader.

CommonLisp has a |....| syntax for interned symbols which trivially
allows empty symbols, and some Scheme iumplementations adopted it as
well, although R6RS didn't (it did add a \xNNNN notation which allows
for non-ASCII chars, but it doesn't seem to include a notation for empty
symbols).


        Stefan

Message #53 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7146 <at> debbugs.gnu.org, Frank <some.frank <at> gmail.com>,
	Lars Magne Ingebrigtsen <larsi <at> gnus.org>,
	Chong Yidong <cyd <at> stupidchicken.com>
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sun, 17 Jul 2011 10:15:17 +0200

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

> "#:" is the obvious choice for the uninterned representation.
> It already works for printing, but is not understood by the reader.

That works now.

> CommonLisp has a |....| syntax

I don't think it is a good idea to add a new special character, so ##
would still be my choice.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #56 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7146 <at> debbugs.gnu.org, Frank <some.frank <at> gmail.com>,
	Lars Magne Ingebrigtsen <larsi <at> gnus.org>,
	Andreas Schwab <schwab <at> linux-m68k.org>,
	Chong Yidong <cyd <at> stupidchicken.com>
Subject: Re: bug#7146: (make-symbol "") issues
Date: Sun, 17 Jul 2011 22:41:19 +0100

On 17/07/11 04:16, Stefan Monnier wrote:

> "#:" is the obvious choice for the uninterned representation.
> It already works for printing, but is not understood by the reader.
>

Is it? If you mean just a "#:" on its own it looks a bit odd to me, but 
as usual I'm coming from CL.

> CommonLisp has a |....| syntax for interned symbols which trivially
> allows empty symbols,

That's not just for interned symbols.  #:|| is read as an uninterned 
empty-string named symbol in common lisp, #:|hello world| as an 
uninterned symbol with a space in the name etc.

Message #59 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 7146 <at> debbugs.gnu.org, Frank <some.frank <at> gmail.com>,
	Lars Magne Ingebrigtsen <larsi <at> gnus.org>,
	Chong Yidong <cyd <at> stupidchicken.com>
Subject: Re: bug#7146: (make-symbol "") issues
Date: Mon, 18 Jul 2011 11:30:35 -0400

>> CommonLisp has a |....| syntax
> I don't think it is a good idea to add a new special character, so ##
> would still be my choice.

Another approach is to follow the same idea as with "#:" ("#: is
immediately followed by <sym> so if it's followed by something that's
not appropriate it means <sym> is empty").
I.e. "#N=" could be used for the empty interned symbol.


        Stefan

Message #62 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7146 <at> debbugs.gnu.org, Frank <some.frank <at> gmail.com>,
	Lars Magne Ingebrigtsen <larsi <at> gnus.org>,
	Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#7146: (make-symbol "") issues
Date: Thu, 21 Jul 2011 15:25:32 -0400

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

>>> CommonLisp has a |....| syntax
>> I don't think it is a good idea to add a new special character, so ##
>> would still be my choice.
>
> Another approach is to follow the same idea as with "#:" ("#: is
> immediately followed by <sym> so if it's followed by something that's
> not appropriate it means <sym> is empty").
> I.e. "#N=" could be used for the empty interned symbol.

This is inconvenient to implement with the current print_object code,
and anyway #N= is not a good conceptual match with empty symbols.

I don't have any objection to using ##.

Message #65 received at 7146 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7146 <at> debbugs.gnu.org, Frank <some.frank <at> gmail.com>,
	Lars Magne Ingebrigtsen <larsi <at> gnus.org>,
	Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#7146: (make-symbol "") issues
Date: Thu, 28 Jul 2011 23:11:02 +0200

Chong Yidong <cyd <at> stupidchicken.com> writes:

> I don't have any objection to using ##.

This is now implemented.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.