[Snow-users-list] snowman-app port problems in Guile
matt.a.martin at gmail.com
Mon Apr 14 22:15:53 EDT 2008
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 at 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 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.
> Snow-users-list mailing list
> Snow-users-list at iro.umontreal.ca
More information about the Snow-users-list