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 _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users