[Larceny-users] Char - Printed Representation

[Felix]

Ray-

On Oct 17, 2007, at 4:48 PM, Ray Racine wrote:

> I've noticed a slightly odd behavior which I've not yet run down.
>                 When compiling Larceny I noticed the following after a
>                 (load-compiler)
>
>                 (...)
>                 src/Compiler/common.imp.sch
>                 WARNING from macro expander:
>                 Redefining
>                 \x2e;call
>                 src/Compiler/iasn.imp.sch
>                 src/Compiler/iasn.imp2.sch
>                 (...)
>
> Its the hex representation of the ascii '.' char I'm referring to.
> i.e., Why am I not seeing
>
>                 .;call
>
> instead of
>
>                 \x23;call
>
> I noticed it again last night when I got the SSAX parser up and  
> running
> on Larceny.
>
>> (ssax:xml->sxml (open-text-input-file "SyncPurchaseOrder.xml")
>                 '())
>
>         (...)
>         (http://www.openapplications.org/oagis/9:UnderQuantity
>                (\x40; (unitCode "normalizedString"))
>                "3.1415926535897932384626433832795")
>
>          (http://www.openapplications.org/oagis/9:OverQuantity
>               (\x40; (unitCode "normalizedString"))
>               "3.1415926535897932384626433832795"))
>         (...)
>
> Here again the ascii '@' is printing as \x40;?
>
> All on an Intel, Linux FC7 box running the latest Larceny from SVN.
>
> Clues?????

Larceny's writer has been changed.  It will no longer render symbols  
with leading characters that would not be valid to read back in  
according to the R6RS.

The intention is to ensure that if you output an S-exp from Larceny  
via the write procedure, the output will be able to be read back in  
by any R6RS-compatible reader.  To ensure this, we need to render  
certain characters (like #\.) using escape sequences; otherwise they  
would not be legal initial characters for symbols.

You can interactively experiment with the different reader modes in  
Larceny to see how Larceny's default behavior extends the acceptable  
input specified in the R6RS.  I've included a sample interaction  
illustrating this at the end of this message.

-Felix

% ~/bin/larceny
Larceny v0.94 "Doomsday Device" (Oct 10 2007 14:26:05,  
precise:Linux:unified)
larceny.heap, built on Wed Oct 10 12:13:31 EDT 2007

 > (display '.a)
.a
 > (write '.a)
\x2e;a
 > '.a
\x2e;a

 > #!r6rs ; put reader into R6RS mode
          ; (the preceding #!r6rs token is treated as a comment by  
the reader)
   3
3

 > (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.


Error: get-datum: Lexical Error: Illegal symbol syntax: .a
   #<INPUT PORT *console-input*>
Entering debugger; type "?" for help.
debug> q

 > #!larceny ; returning the reader to Larceny's default mode

 >           ; the preceding #!larceny token is treated as an expression
             ; that produces 0 values (or perhaps the unspecified value;
             ; Felix doesn't remember)
   3
3

 >