[Larceny-users] Char - Printed Representation

[Felix]

On Oct 17, 2007, at 11:15 PM, Jed Davis wrote:

> On Wed, Oct 17, 2007 at 05:06:35PM -0400, Felix wrote:
>>
>>> (display '.a)
>>
>>
>> Error: get-datum: Lexical Error: Illegal symbol syntax: .a)  #<INPUT
>> PORT *console-input*>
>> Entering debugger; type "?" for help.
>> debug>
>> Error: get-datum: Syntax error while parsing a <outermost-datum>
>>    Encountered rparen while expecting something in
>>     backquote boolean bvecstart character comma eofobj id lbracket
>> lparen miscflag number quasisyntax quote splicing string syntax
>> unsyntax unsyntaxsplicing vecstart xbox xfaslb xfaslc xfaslf xfaslg
>> xfaslp xsharpdot xstring #<INPUT PORT *console-input*>
>> Computation is not continuable.
>> debug> q
>>
>>> '.a ; previous response is b/c of two exceptions from the reader.
>> More details on request.
>
> Not that hard: because the reader chokes on the '.a, leaving the ) and
> newline on the input stream to confuse the debugger prompt.
>
> Less comprehensible is this, which I discovered the other night:
>
>> #o9 3
>
>
>   Error: get-datum: Syntax error while parsing a <number>
>     Encountered number while expecting something in
>      number #<INPUT PORT *console-input*>
>   Entering debugger; type "?" for help.
>
> That is, the reader desires to complain about the invalid number,  
> so it
> reads the *next* token and says that that's not a number.  (Try also:
> "#o9 asdf".)  Even after trying to read the reader I'm not sure why
> that is; or perhaps what I don't know is why other error messages are
> correct.

Hmm.  Do many of the other "constructors" (or I suppose "action  
routines" might be more appropriate terminology) besides makeNum and  
makeOctet invoke parse-error?  Some seem to, but I'm not sure how  
often the other pieces of code are exercised...

My current hypothesis is that this is a subtle misbehavior (not sure  
if it qualifies as a bug) caused by parse-error invoking the next- 
token procedure, assuming that it gives us information about the  
current token, when in fact at the point that parse-error is being  
invoked from makeNum, the token in question has already been consumed  
(by the consume-token! procedure) and so the invocation of next-token  
causes the reader to continue lexing the input stream.

One way to test this hypothesis would be to change the following  
pattern of the reader:
     ((number) (begin (consume-token!) (makeNum)))
to
     ((number) (let ((ret (makeNum))) (consume-token!) ret))
which one might recognize as the begin0 special form from other  
schemes. . .

-Felix