*READ-SUPPRESS* doesn't do a job good enough

[Samium Gromoff]

deepfire@auriga:~$ sbcl --eval '(read-from-string "#+foo(#+foo:foo t) t")'
This is SBCL 1.0.44, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.

debugger invoked on a SB-INT:SIMPLE-READER-PACKAGE-ERROR in thread #<THREAD
                                                                     "initial thread" RUNNING
                                                                     {1002AD5001}>:
  SB-INT:SIMPLE-READER-PACKAGE-ERROR at 15 (line 1, column 15) on #<SB-IMPL::STRING-INPUT-STREAM

                                                                    {100328A631}>:
    package "FOO" not found

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE] Ignore runtime option --eval "(read-from-string \"#+foo(#+foo:foo t) t\")".
  1: [ABORT ] Skip rest of --eval and --load options.
  2: Skip to toplevel READ/EVAL/PRINT loop.
  3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process).

(SB-IMPL::READ-TOKEN #<SB-IMPL::STRING-INPUT-STREAM {100328A631}> #\f)
0] *

[Roman Marynchak (roman-marynchak)]

*READ-SUPPRESS* is false by default, so the above example is slightly incomplete.

AFAIK, *READ-SUPPRESS* does not hide the package errors (or I cannot find anything about that in CLHS), so I am not sure whether such behavior is buggy (also, CLISP and LW show the same error). Could you please provide some additional information about this issue (some CLHS references which are related to the problem) ?

[Samium Gromoff (deepfire)]

Well, http://www.lispworks.com/documentation/HyperSpec/Body/v_rd_sup.htm says:

> This variable is intended primarily to support the operation of the read-time conditional notations #+ and #-. It is important for
> the reader macros which implement these notations to be able to skip over the printed representation of an expression despite
> the possibility that the syntax of the skipped expression may not be entirely valid for the current implementation, since #+ and #-
> exist in order to allow the same program to be shared among several Lisp implementations (including dialects other than
> Common Lisp) despite small incompatibilities of syntax.

How to interpret "small incompatibilities of syntax" is an arguable issue, I do agree.

However, my general impression is that the current behavior is somewhat undesirable.

[Nikodemus Siivola (nikodemus)]

Prettier test-case:

(let ((*read-suppress* t)) (read-from-string "#+foo:foo foo"))

[Douglas Katzman (dougk)]

Part of this problem (unresolvable, I think) is an ill-defined interplay with the ambiguity of consecutive conditionals.

Nesting with explicit parentheses is clear enough in meaning.
  #-hork (anything #+baz whatsoever #-foo mum)
Here we can ignore ignore everything inside the parentheses if "hork" is absent.

But the meaning of "#-foo #-bar form1 form2" very much depends on what we think it means to "ignore one form" after starting to ignore one form. Under differing interpretations it might be essential to fully parse the expression after a "#-"
Something like this was mentioned in sbcl-devel (subject line "Disappearing code in 'compiler/dump.lisp' through incorrect use of read-time conditional" on 2013-09-16)