<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I believe that a more reasonable approach would be to factor support<br>
for multibyte and multilingual lisps into three components:<br>
<br>
- External formats and primitive encapsulating streams provided by the<br>
implementation.<br>
<br>
- A higher level implementation such as flexi-streams that reuses what<br>
the implementation provides or completes it when lacking. For<br>
implementations that provide almost everything, such as CLISP and<br>
perhaps ECL in the near future, it can indeed be a trivial layer.<br>
<br>
- A library for handling the Unicode database, for tasks such as<br>
normalization, upcasing, etc.<br>
<br>
The real challenge is the last point.</blockquote><div><br><a href="http://www.weitz.de/cl-unicode/">CL-UNICODE</a> may have some of that. The underlying operating systems sometimes also have support for higher-level Unicode tasks such as normalization. For a platform-independent solution, libraries such as <a href="http://icu-project.org/">ICU </a> can be used.<br>
<br>In the implementation of Lisp I'm maintaining (HCL, the Common Lisp which runs inside of CoCreate Modeling), we also followed the approach of implementing encoding support in the core rather than in a streams library. All conversions for predefined encodings are done in C/C++ for better performance.<br>
<br>  Claus<br><br></div></div><br>