#+ reader should insist on seeing a next form

Bug #1454400 reported by Douglas Katzman on 2015-05-12
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Undecided
Unassigned

Bug Description

(read-from-string "(let ((foo 3) #+sbcl) wat)") => (LET ((FOO 3)) WAT)

This is not a regression. The bug is present in ancient versions of SBCL going all the way back to CMUCL.

All other Lisp implementations I tested reported an unmatched parenthesis.

The negative case works fine because the reader *must* eat and discard one form.

Douglas Katzman (dougk) on 2015-05-12
tags: added: reader
Douglas Katzman (dougk) wrote :

This is fixed, but it adds one more way in which "mismatched parentheses" is printed, when in fact there is no mismatch.
Nikodemus seems to hate that (see bug 558465). I don't mind it as much, but I do have a way to fix all such things, I think.
In fact it will be more robust than the hack that was implemented in 32c95570fd8253caca74ed16cde242b9ed3d08ab because the one-char-lookahead trick falls on its face when there is intervening virtual whitespace.

In other words, a peek-char at this #\' would not inform you that you effectively have "(foo ')":
"(foo ' #+other-lisp bar #+other-other-lisp baz)

Changed in sbcl:
status: New → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers