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@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. Marc

Hi Marc, Marc Feeley <feeley@iro.umontreal.ca> writes:

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.

Thanks for the explanation.

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.

That's one solution, but as someone with an accent in his name, I don't like it so much. ;-) I can think of two solutions: 1. provide a `read' replacement for implementations that are known to not support this syntax (but as you say, this may result in much slower I/O, especially on Guile); 2. implement said syntax in Guile. The latter is doable (and makes sense if everyone else does it), but the former would allow Snow to run with current versions of Guile. Thanks, Ludovic.