() Daniel Krueger <keen...@googlemail.com> () Sat, 28 Apr 2012 20:29:22 +0200
i think there shouldn't be any transcoding of guile's strings, as strings are internal representation of characters, no matter how they are encoded. So the only time when encoding matters is when it passes it's `internal boundarys', i mean if you write the string to a port or read from a port or pass it as a string to a foreign library. Indeed, iconv(1) converts external representations (files). How it does that internally is an implementation detail. That's the main reason why i suggested it as a model for exercising Guile's internals -- it's very easy to check correctness. For the ports all transcoding is available, and as said, the real representation of guile strings internally is as utf8, which can't be changed. IIUC, the internal representation of strings is not UTF-8 (at least, not all the time), but anyway, that doesn't matter at all. The proposed task is to use procedures and features provided by Guile (i.e., its public API) to do mimic iconv. The only additional thing i forgot about are bytevectors, if you convert a string to an explicit representation, but afaik there you also can give the encoding to use. Am I wrong? I don't know.
