Thank you for the quick reply! That solves my problem.
Actually, your reply led me to read the spec more carefully, and I
realized that since I'm calling read recursively, I should probably
use recursive-p = t, thus:
(defun sharp-bang-read (stream char n)
(declare (ignore char n))
(read stream t nil t)
(read stream t nil t))
That solves the problem, too; I'll probably go with this unless I hear
that it's not a good idea.
Regards, and thanks again,
Matt
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=xcoQgmorEd54v46wec6y8N9Oet7ACI8+R8FCKE3IoEg=;
b=SY03NE/ZsmZlTT9YJeBtFjCnC8Zjqllv4IYVsh+KtIpD+B+JReUr9/63clezFXVj0O
JMmlUGyxuQ0+k+YUvVoIEJMtS5hebu1Ur55bNp97VBBhCqFJdt7ddlQluOF9D8H46SGw
jiovfxh/ZtC7M1o0tpqICNTUl/mukca1H+T5s=
MIME-Version: 1.0
Date: Wed, 19 Oct 2011 01:39:19 +0200
From: Stig Hemmer <stighemmer@...>
Cc: sbcl-help@...
Content-Type: text/plain; charset=ISO-8859-1
The problem is that the last (READ STREAM) reads the following newline
and discards it. The REPL then needs another newline to end the line.
This is in fact according to spec, here is what the description of READ says:
When *read-suppress* is false, read throws away the delimiting
character required by certain printed representations if it is a
whitespace[2] character; but read preserves the character (using
unread-char) if it is syntactically meaningful, because it could be
the start of the next expression.
You can use READ-PRESERVING-WHITESPACE instead to get the effect you want.
Stig Hemmer