BRL reader problem.

[Per Bothner]

On 08/25/2009 09:17 AM, Dan Stanger wrote:
> I have reproduced the problem with the following line:
> [(brl ]lorem[)]
>  From the command line, the value lorem is returned from BRLReaderString
> as the token.  However in the servlet, the read loop sees 10 (newline),
> and then -1, returning the newline as the token. I have determined that
> when line 79 in BRLReaderString, saveReadState='\n' is commented out,
> the reader does not see the newline.  This variable is used to set
> readState in the finally block.  Is the purpose of readState, and how
> the reader works normally documented somewhere?

The readState is primarily used for the prompt string in a REPL,
to give a visual clue when starting a continuation line that you're
nested inside something.

I think it's probably used for some error detection/reporting,
but I don't remember for sure.  It is obviously also used by the
BRL reader.

Changing saveReadState in line 79 does seem strange.  It seems to be
needed for REPL mode; without it you get some bad behavior:

$ bin/kawa --brl
<!--BRL:1-->[(+ 3 4)]
<!--BRL:2-->
(+ 3 4)]
<!--BRL:3-->

Note that (+ 3 4) is not evaluated.

When what we want is:

$ bin/kawa --brl
<!--BRL:1-->[(+ 3 4)]
7
<!--BRL:2-->

Perhaps we can fix the BRL reader so that the default/initial state
is '\n' (which is the default for Scheme) rather than ']'.   I did a
quick experiment - see the attached patch.  However, that doesn't
work either, but it might be worth exploring.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: brlread.patch
Type: text/x-patch
Size: 1626 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/kawa/attachments/20090825/8873e6af/attachment.bin>