CHICKEN Scheme

Summary

Chicken reader does not maintain quotes on |#:|

Metadata

Id: c7661af6d8bc90e87032eb756e0d8b1be732c1a7
Trac id: 562
Type: defect
Reporter: zbigniew
Owner: felix
Cc:
Status: closed
Component: core libraries
Estimated difficulty:
Resolution: duplicate
Priority: major
Milestone: 4.9.0
Version: 4.6.x
Changetime: 2012-09-24 21:47:48 UTC
Created: 2011-04-08 23:58:22 UTC
Keywords: the colossal colon caper

Description

string->symbol on |#:| works, but reading it does not. See comment below.

This causes node (chicken read-syntax #:) to be not properly indexed. It can be accessed directly but not via the index, because the index entry looks like (: (chicken read-syntax)) instead of (|#:| (chicken read-syntax)). Although it is written out correctly initially, once the index goes through a read/modify/write cycle (on a different symbol) the |#:| becomes #: and then eventually :.

Indirectly noticed by mario.

Changes and comments

[2011-04-09 00:00:13 UTC] zbigniew wrote:

Specifically this apparently leads to a 500 internal error when doing an empty regex search on chickadee. However searching for ^# does not error (but does not show #:, as expected).

[2011-04-09 02:12:03 UTC] zbigniew changed status from new to assigned

[2011-04-09 02:12:03 UTC] zbigniew changed owner from zbigniew to felix

[2011-04-09 02:12:03 UTC] zbigniew changed component from extensions to core libraries

[2011-04-09 02:12:03 UTC] zbigniew changed description

[2011-04-09 02:12:03 UTC] zbigniew changed summary

[2011-04-09 02:12:03 UTC] zbigniew wrote:

This is a bug in core. string->symbol on |#:| works, but reading it does not. It works fine for other symbols, such as |#?|. This appears to be a bug in the reader not the writer.

 #;7> (string->symbol "#:")
  ; => |#:|
 
 (with-input-from-string "((|#:|))" read)
   ; => ((#:))
 
 #;4> '((|#:|))
  ; => ((#:))
 
 #;5> '|#:|
  ; => #:
 
 #;12> (write '|#:|)
  ; => #:
 
 #;13> (write (string->symbol "#:"))
  ; => |#:|
 
 (with-input-from-string "((|#?|))" read)
   ; => ((|#?|))
 
 #;6> '|#?|
  ; => |#?|

[2011-04-11 08:41:57 UTC] felix wrote:

This is invalid syntax. I don't see the bug.

[2011-04-11 08:45:52 UTC] felix wrote:

In fact, the reader should report an error in this case.

[2011-04-11 10:08:52 UTC] felix wrote:

Ok, I got it now, I think. "#:" will trigger a read-error, |#:| will be printed escaped.

[2011-04-11 10:23:40 UTC] felix wrote:

BTW, there is a general problem with escaped colons and read/write invariance (see #322). This has to be solved for a correct handling of this problem.

[2011-04-11 12:10:33 UTC] felix changed status from assigned to closed

[2011-04-11 12:10:33 UTC] felix set resolution to fixed

[2011-04-11 12:10:33 UTC] felix wrote:

I have applied the changes to "experimental". #322 is not fixed, yet.

[2011-04-11 22:37:36 UTC] zbigniew changed status from closed to reopened

[2011-04-11 22:37:36 UTC] zbigniew removed resolution fixed

[2011-04-11 22:37:36 UTC] zbigniew wrote:

I just tried experimental and I see no difference in any of the erroneous test cases above. What am I doing wrong?

[2011-04-11 22:48:02 UTC] zbigniew wrote:

If I understand you correctly, the primary problem cannot be fixed without fixing #322, that is:

 (with-input-from-string
   (with-output-to-string
    (lambda () (write (string->symbol "#:"))))
   read)

currently results in #: but should result in |#:|.

If so, what change did you make other than having #: result in a reader error? Your reply indicates an escaping change was made, but I don't see any difference there.

[2011-04-12 11:06:18 UTC] felix changed status from reopened to closed

[2011-04-12 11:06:18 UTC] felix set resolution to duplicate

[2011-04-12 11:06:18 UTC] felix wrote:

Replying to zbigniew: > If so, what change did you make other than having #: result in a reader error? Your reply indicates an escaping change was made, but I don't see any difference there.

Right, that second change was pointless as `(string->symbol "#:")` is already handled. Now #332 needs to be fixed.

[2011-04-12 11:06:45 UTC] felix wrote:

Replying to felix: > Replying to zbigniew: > > If so, what change did you make other than having #: result in a reader error? Your reply indicates an escaping change was made, but I don't see any difference there. > > Right, that second change was pointless as `(string->symbol "#:")` is already handled. Now #332 needs to be fixed.

#322, not #332