||:xxxx syntax.

[Gleefre]

When trying to read ||:xxxx, abcl crashes:

(defpackage ""
  (:use #:cl)
  (:export #:exported-symbol))
; => #<PACKAGE >

'||:exported-symbol
'||::unexported-symbol
; EXPECTED => ||:EXPORTED-SYMBOL  and  ||::UNEXPORTED-SYMBOL
; OR :EXPORTED-SYMBOL  and :UNEXPORTED-SYMBOL

Instead abcl crashes:

java.lang.IndexOutOfBoundsException: fromIndex: 1 > toIndex: 0
	at java.base/java.util.BitSet.checkRange(BitSet.java:369)
	at java.base/java.util.BitSet.get(BitSet.java:648)
	at org.armedbear.lisp.Stream.readToken(Stream.java:1150)
	at org.armedbear.lisp.Stream.processChar(Stream.java:596)
	at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:558)
	at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:567)
	at org.armedbear.lisp.Stream.read(Stream.java:501)
	at org.armedbear.lisp.Stream$15.execute(Stream.java:2456)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:828)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:951)
	at org.armedbear.lisp.top_level_45.execute(top-level.lisp:371)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:805)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:910)
	at org.armedbear.lisp.top_level_46.execute(top-level.lisp:385)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:930)
	at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407)
	at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:795)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:892)
	at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:892)
	at org.armedbear.lisp.Interpreter.run(Interpreter.java:361)
	at org.armedbear.lisp.Main$1.run(Main.java:48)
	at java.base/java.lang.Thread.run(Thread.java:1623)

Tested on abcl 1.9.2 (latest release)

See also s-expressionists/wscl#63 about the general ambiguity of the ||:xxxx syntax.

[easye]

Confirmed as failing in abcl-1.9.3-dev.

Two bugs here (or a bug and a feature):

1. Fixing the reading of such sequences as to not to crash

2. Deciding whether to interpret the reading of ||:xxxx as the symbol xxxx in the package named "" (SBCL, CCL) or as the keyword :xxxx (ECL, CLASP, CLISP)

[Gleefre]

About the 2nd point.

IIUC the standard says that ||:xxxx should be read as a keyword. (See a longer explanation in the WSCL issue.)

However, reading it as a symbol in package named "" could be a useful extension, since it is the only candidate for reading such a symbol. Furthermore, not defining such an extension would lead to losing print-read consistency.

Note also that a third possible resolution -- defining "" to be a global nickname for the keyword package, as Allegro CL does -- is not standard compliant. (EDIT: Although strictly speaking, reading it as a symbol in the package named "" is not standard compliant as well...)