[Snow-users-list] snowman-app port problems in Guile

Marc Feeley feeley at iro.umontreal.ca
Mon Apr 14 21:12:04 EDT 2008

On 14-Apr-08, at 11:36 AM, Ludovic Courtès wrote:
>  (author: "Danny Dub\351 <Danny.Dube at ift.ulaval.ca>")
>  (author: "Adrien Pi\303\251rard <pierarda at iro.umontreal.ca")
> It's these escape sequences that make Guile's reader unhappy.
> However, I don't understand where they come from.  When I download the
> snowballs that contain these strings "by hand" from the Snow  
> website, I
> can see that they do not contain the escape sequences, but rather a
> UTF-8 or Latin-1 representation of these author names.  So I suppose  
> the
> escape sequences get added somehow as the strings are sent over HTTP.
> Can someone shed some light on this?

The escapes are generated by the snowfort server.  The server, a  
Scheme program, serializes the list of packages using "write" and the  
snowman client will deserialize it using "read".  In this case the  
server is running on Gambit and the client is running on Guile.   
Gambit's syntax for strings is compatible with C and the \ooo octal  
notation is how non-ASCII LATIN-1 characters are written.  Although  
this syntax is not universal among Scheme implementations, it is a  
fairly common extension to the standard Scheme syntax (supported by  
Bigloo, Chez, Gambit, Kawa, MzScheme, Scsh and probably others).   
Unfortunately Guile does not implement this extension.  Note that the  
snowfort server could be run using some other Scheme system, but that  
does not solve the problem because the issue is the incompatibility of  
the server's write and the client's read.  That's what standards are  
meant to solve.

So what to do?  There is no standard way in Scheme to write non-ASCII  
characters (in fact one could say that no character can be portably  
written since Scheme does not define the character set!).  Specific  
serializer/deserializer algorithms other than write/read could be  
implemented but that would be a real pain and it would make I/O really  
slow on interpreted systems.

The pragmatic solution is to avoid non-ASCII characters in Scheme  
code, and Snow packages in particular.


More information about the Snow-users-list mailing list