Re: guile can't find a chinese named file

[Ludovic Courtès]

Linas Vepstas <address@hidden> skribis:

> On Mon, Jan 30, 2017 at 1:27 PM, David Kastrup <address@hidden> wrote:
>> Marko Rauhamaa <address@hidden> writes:
>>> David Kastrup <address@hidden>:
>>>> Marko Rauhamaa <address@hidden> writes:
>>>>> Guile's mistake was to move to Unicode strings in the operating system
>>>>> interface.
>>>>
>>>> Emacs uses an UTF-8 based encoding internally [...]
>>>
>>> C uses 8-bit characters. That is a model worth emulating.
>>
>> That's Guile-1.8.  Guile-2 uses either Latin-1 or UCS-32 in its string
>> internals, either Latin-1 or UTF-8 in its string API, and UTF-8 in its
>> string port internals.
>
> Which seems to be a bad decision. I've got strings, 10MBytes long, holding
> chinese in UTF8, and guile converts these internally, to UCS-32 which is a
> complete and total waste of CPU time. WTF.  It then has to  convert them
> back to UTF8 before passing them to my C++ code that actually does stuff
> with them.

I see this as an interaction problem: Guile 2.0 uses UCS-32 internally,
and your code uses UTF-8.  It could have been the other way around.

There were discussions to move to UTF-8 internally in 2.2.  As Mike
explained, that was not really an option in 2.0 mostly due to the
requirement to support O(1) random access.

<https://github.com/larcenists/larceny/wiki/StringRepresentations> lists
various options and the tradeoffs involved.

Ludo’.