Guile supports SRFI-14, as do most of the other "big" implementations. Gambit isn't listed at http://srfi.schemers.org/srfi-implementers.html at all though. Might it help?
"This library is designed to be portable across implementations that use different character types and representations, especially ASCII, Latin-1 and Unicode."
On Mon, Apr 14, 2008 at 8:12 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
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
Snow-users-list mailing list Snow-users-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/snow-users-list