chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] ditching syntax-case modules for the utf8 egg


From: Alex Shinn
Subject: [Chicken-users] ditching syntax-case modules for the utf8 egg
Date: Thu, 28 Jun 2007 12:25:54 +0900

Hi all,

Following up on trac ticket #258:

 http://trac.callcc.org/ticket/258

I'm considering changing the utf8 egg to no longer use syntax-case
modules, so that it would work like the numbers egg.

The way this would work is that, naturally, if you wanted to use utf8
semantics you'd just (use utf8), this time with no need for syntax-case
and nothing to import.

External modules, by default, would integrate standard string procedures
and not be affected.  However, if you wanted to make an extension
optionally work with utf8 semantics you could compile it with

 (declare (not usual-integrations))

or alternately

 (declare (not usual-integrations string-ref string-set! ...))

for all the utf8-specific string procedures.

Apart from allowing other eggs to optionally work with utf8, this seems
to be more in line with Chicken's style, would make the utf8 egg
lighter-weight, and would allow using utf8 with other macro systems.

The only way I see any problems arising is if someone writes some
8-bit-char-specific code (like, e.g. using READ-CHAR to access bytes of
binary data), and at the same time declares (not usual-integrations).
I checked and it doesn't look like this is a problem for any eggs.

The bigger issue is that any existing code that uses utf8 currently will
break on the (import utf8) form.  In the eggs we have only two uses:

 gl-display-glx/gl-display-glx.scm:(import utf8)
 levenshtein/levenshtein-utf8-means.scm:  (import utf8)

but I don't know how much personal code would be affected.  Please let
me know if you're currently using the utf8 egg and what you would think
of this change.

--
Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]