Re: string-map arg order

[Alex Shinn]

>>>>> "thi" == Thien-Thi Nguyen <address@hidden> writes:

    thi> obguile: are there any aspects of guile that you are
    thi> particularly interested in hacking?

Possibly multi-byte character support.  I know there's been some
discussions, but has anyone put together any concrete plans or
requirements?  Almost certainly modify read/write to use utf8, but the
internal representation is not so obvious.  utf16 sounds nice, and
would be most commonly used in other applications and libraries
(important since Guile is meant to be easy to extend and embed with
C), but there are a small percentage of characters that require two
code units.  This would probably mean two char types: immediate and
non-immediate.  It also means that (without clever optimizing when
there are no two code chars) accessing a character in a string is no
longer constant time.  An alternative, since we have 24 bits to work
with, is to use our own encoding like Emacs does (not very compatible
with other libs and probably a lot of work), or maybe (*big* maybe) we
can do some clever tagging and fit ucs4 into an immediate.

Another important question is whether this should be an optional
feature, such as having people do (use-modules (unicode)) if they want
unicode enabled Guile.

We'd need a clean API for converting to/from normal C strings.  This
is where wrapper generators are really nice: gnucash, guile-gtk and
anything using SWIG will have very little problem with the change :)
Harder to deal with are places where people use strings as byte
arrays; probably the cleanest way to solve this is require they use
srfi-4 u8vectors and offer a read-bytes!/partial as an alternative to
read-string!/partial.

Thoughts?

-- 
Alex Shinn <address@hidden>