unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#7146: (make-symbol "") issues
@ 2010-10-02  4:19 Frank
  2010-10-03  0:44 ` Frank
  2010-10-03 18:45 ` MON KEY
  0 siblings, 2 replies; 21+ messages in thread
From: Frank @ 2010-10-02  4:19 UTC (permalink / raw)
  To: 7146

;;; "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.







^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-02  4:19 bug#7146: (make-symbol "") issues Frank
@ 2010-10-03  0:44 ` Frank
  2010-10-03  1:32   ` Chong Yidong
  2010-10-03 18:45 ` MON KEY
  1 sibling, 1 reply; 21+ messages in thread
From: Frank @ 2010-10-03  0:44 UTC (permalink / raw)
  To: 7146

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;






^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-03  0:44 ` Frank
@ 2010-10-03  1:32   ` Chong Yidong
  2010-10-03  3:44     ` Frank
  0 siblings, 1 reply; 21+ messages in thread
From: Chong Yidong @ 2010-10-03  1:32 UTC (permalink / raw)
  To: Frank; +Cc: 7146

Frank <some.frank@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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-03  1:32   ` Chong Yidong
@ 2010-10-03  3:44     ` Frank
  2010-10-03  4:05       ` Chong Yidong
  0 siblings, 1 reply; 21+ messages in thread
From: Frank @ 2010-10-03  3:44 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 7146

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

Chong Yidong schrieb:

>Frank <some.frank@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


[-- Attachment #2: bug.elc --]
[-- Type: application/octet-stream, Size: 775 bytes --]

[-- Attachment #3: bug.el --]
[-- Type: text/plain, Size: 226 bytes --]

(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!")))

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-03  3:44     ` Frank
@ 2010-10-03  4:05       ` Chong Yidong
  2010-10-03  4:14         ` Frank
                           ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Chong Yidong @ 2010-10-03  4:05 UTC (permalink / raw)
  To: Frank; +Cc: 7146

Frank <some.frank@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.






^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-03  4:05       ` Chong Yidong
@ 2010-10-03  4:14         ` Frank
  2010-10-03  4:36         ` Juanma Barranquero
  2010-10-03 10:28         ` Johan Bockgård
  2 siblings, 0 replies; 21+ messages in thread
From: Frank @ 2010-10-03  4:14 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 7146

Chong Yidong schrieb:

>Frank <some.frank@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!










^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-03  4:05       ` Chong Yidong
  2010-10-03  4:14         ` Frank
@ 2010-10-03  4:36         ` Juanma Barranquero
  2010-10-03 10:28         ` Johan Bockgård
  2 siblings, 0 replies; 21+ messages in thread
From: Juanma Barranquero @ 2010-10-03  4:36 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 7146, Frank

On Sun, Oct 3, 2010 at 06:05, Chong Yidong <cyd@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)





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-03  4:05       ` Chong Yidong
  2010-10-03  4:14         ` Frank
  2010-10-03  4:36         ` Juanma Barranquero
@ 2010-10-03 10:28         ` Johan Bockgård
  2010-10-03 14:55           ` Chong Yidong
  2 siblings, 1 reply; 21+ messages in thread
From: Johan Bockgård @ 2010-10-03 10:28 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 7146, Frank

Chong Yidong <cyd@stupidchicken.com> writes:

> Frank <some.frank@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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-03 10:28         ` Johan Bockgård
@ 2010-10-03 14:55           ` Chong Yidong
  2010-10-03 23:12             ` Stefan Monnier
  0 siblings, 1 reply; 21+ messages in thread
From: Chong Yidong @ 2010-10-03 14:55 UTC (permalink / raw)
  To: Frank; +Cc: 7146

Johan Bockgård <bojohan@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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-02  4:19 bug#7146: (make-symbol "") issues Frank
  2010-10-03  0:44 ` Frank
@ 2010-10-03 18:45 ` MON KEY
  2010-10-03 18:56   ` Chong Yidong
  1 sibling, 1 reply; 21+ messages in thread
From: MON KEY @ 2010-10-03 18:45 UTC (permalink / raw)
  To: 7146; +Cc: Chong Yidong

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\





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-03 18:45 ` MON KEY
@ 2010-10-03 18:56   ` Chong Yidong
  2010-10-03 23:48     ` MON KEY
  0 siblings, 1 reply; 21+ messages in thread
From: Chong Yidong @ 2010-10-03 18:56 UTC (permalink / raw)
  To: MON KEY; +Cc: 7146

MON KEY <monkey@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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-03 14:55           ` Chong Yidong
@ 2010-10-03 23:12             ` Stefan Monnier
  2011-07-14 14:25               ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2010-10-03 23:12 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 7146, Frank

> 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







^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-03 18:56   ` Chong Yidong
@ 2010-10-03 23:48     ` MON KEY
  0 siblings, 0 replies; 21+ messages in thread
From: MON KEY @ 2010-10-03 23:48 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 7146

On Sun, Oct 3, 2010 at 2:56 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> MON KEY <monkey@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\





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2010-10-03 23:12             ` Stefan Monnier
@ 2011-07-14 14:25               ` Lars Magne Ingebrigtsen
  2011-07-14 16:24                 ` Andreas Schwab
  0 siblings, 1 reply; 21+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-07-14 14:25 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 7146, Frank, Chong Yidong

Stefan Monnier <monnier@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/





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2011-07-14 14:25               ` Lars Magne Ingebrigtsen
@ 2011-07-14 16:24                 ` Andreas Schwab
  2011-07-17  3:16                   ` Stefan Monnier
  0 siblings, 1 reply; 21+ messages in thread
From: Andreas Schwab @ 2011-07-14 16:24 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: 7146, Frank, Chong Yidong

Lars Magne Ingebrigtsen <larsi@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2011-07-14 16:24                 ` Andreas Schwab
@ 2011-07-17  3:16                   ` Stefan Monnier
  2011-07-17  8:15                     ` Andreas Schwab
  2011-07-17 21:41                     ` David De La Harpe Golden
  0 siblings, 2 replies; 21+ messages in thread
From: Stefan Monnier @ 2011-07-17  3:16 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: 7146, Frank, Lars Magne Ingebrigtsen, Chong Yidong

>> 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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2011-07-17  3:16                   ` Stefan Monnier
@ 2011-07-17  8:15                     ` Andreas Schwab
  2011-07-18 15:30                       ` Stefan Monnier
  2011-07-17 21:41                     ` David De La Harpe Golden
  1 sibling, 1 reply; 21+ messages in thread
From: Andreas Schwab @ 2011-07-17  8:15 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 7146, Frank, Lars Magne Ingebrigtsen, Chong Yidong

Stefan Monnier <monnier@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2011-07-17  3:16                   ` Stefan Monnier
  2011-07-17  8:15                     ` Andreas Schwab
@ 2011-07-17 21:41                     ` David De La Harpe Golden
  1 sibling, 0 replies; 21+ messages in thread
From: David De La Harpe Golden @ 2011-07-17 21:41 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: 7146, Frank, Lars Magne Ingebrigtsen, Andreas Schwab,
	Chong Yidong

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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2011-07-17  8:15                     ` Andreas Schwab
@ 2011-07-18 15:30                       ` Stefan Monnier
  2011-07-21 19:25                         ` Chong Yidong
  0 siblings, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2011-07-18 15:30 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: 7146, Frank, Lars Magne Ingebrigtsen, Chong Yidong

>> 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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2011-07-18 15:30                       ` Stefan Monnier
@ 2011-07-21 19:25                         ` Chong Yidong
  2011-07-28 21:11                           ` Andreas Schwab
  0 siblings, 1 reply; 21+ messages in thread
From: Chong Yidong @ 2011-07-21 19:25 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 7146, Frank, Lars Magne Ingebrigtsen, Andreas Schwab

Stefan Monnier <monnier@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 ##.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#7146: (make-symbol "") issues
  2011-07-21 19:25                         ` Chong Yidong
@ 2011-07-28 21:11                           ` Andreas Schwab
  0 siblings, 0 replies; 21+ messages in thread
From: Andreas Schwab @ 2011-07-28 21:11 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 7146, Frank, Lars Magne Ingebrigtsen

Chong Yidong <cyd@stupidchicken.com> writes:

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

This is now implemented.

Andreas.

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2011-07-28 21:11 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-02  4:19 bug#7146: (make-symbol "") issues Frank
2010-10-03  0:44 ` Frank
2010-10-03  1:32   ` Chong Yidong
2010-10-03  3:44     ` Frank
2010-10-03  4:05       ` Chong Yidong
2010-10-03  4:14         ` Frank
2010-10-03  4:36         ` Juanma Barranquero
2010-10-03 10:28         ` Johan Bockgård
2010-10-03 14:55           ` Chong Yidong
2010-10-03 23:12             ` Stefan Monnier
2011-07-14 14:25               ` Lars Magne Ingebrigtsen
2011-07-14 16:24                 ` Andreas Schwab
2011-07-17  3:16                   ` Stefan Monnier
2011-07-17  8:15                     ` Andreas Schwab
2011-07-18 15:30                       ` Stefan Monnier
2011-07-21 19:25                         ` Chong Yidong
2011-07-28 21:11                           ` Andreas Schwab
2011-07-17 21:41                     ` David De La Harpe Golden
2010-10-03 18:45 ` MON KEY
2010-10-03 18:56   ` Chong Yidong
2010-10-03 23:48     ` MON KEY

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).