On Wed, Jul 9, 2014 at 7:00 AM, Alex Shinn <[email protected]> wrote:
> However, I don't think that's the real problem. The issue as I > understand is that although Chicken has both strings and > bytevectors in the core, historically and for continued simplicity > strings are abused as bytevectors in many cases. This allows > you to use the plentiful string libraries (e.g. srfi-13 and regex) > on binary data, whereas there are few bytevector utils. ... > So as you see the change is contagious. We can update the core > efficiently and easily, but then we have to fix the string abusers, > and then we have to replace existing index-oriented APIs. Hi Alex, I am not an expert here, so take it easy. You seem to suggest this kind of approach: 1) move abusers to bytevectors (bytevector API needing a major boost for that) 2) update string functions to support utf-8 but afterwards move to new cursor-oriented functions Wouldn't be simpler and more effective this other path? 1) keep current string functions as they are (i.e. byte-oriented) and keep "abusers" abusing (and happy) 2) provide new utf8/cursor-oriented functions where needed (e.g. utf8-string-ref but not utf8-string-append) Regards, Michele _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
