Re: guile can't find a chinese named file

[Eli Zaretskii <eliz@gnu.org>]

> From: Marko Rauhamaa <marko@pacujo.net>
> Cc: dak@gnu.org,  guile-user@gnu.org
> Date: Thu, 16 Feb 2017 20:38:31 +0200
> 
> Eli Zaretskii <eliz@gnu.org>:
> 
> > In any case, this is unrelated to how strings are implemented, because
> > the basic level of string implementation _must_ support binary,
> > character by character (and byte by byte) comparison. Otherwise, you
> > won't be able to compare file names equal, for example, at least on
> > Unix and Windows (macOS is another matter).
> 
> Your statement is true only if you want to use character strings when
> interfacing the operating system.

Why, because I mentioned comparison of file names?  That's just one
example that came to my mind within 5 sec of thought; there are many
others.

My point is that there's place for both types of string comparisons,
and therefore both should be available.  Which means the lowest level
of string implementation should not automatically normalize strings.
(You could also have a separate string variant where normalization
happens automatically, but that has a disadvantage that you need to
decide which variant you want in advance, where you don't necessarily
know enough yet.)

> You could leave character strings to application libraries for
> newsreaders, IRC clients etc, and have a separate byte string data
> type for the system interface.

I don't know what you mean by "application libraries", but if that's
something applications should provide, and Guile shouldn't, then I
disagree: application writers will generally not know enough to
implement this non-trivial functionality.

> If emacs managed to restore a binary/text unification (and infect Guile
> in the process), that would be quite an accomplishment.

I don't understand what "binary/text unification" means, sorry.

> Now, if we only could get rid of locales while we are at it...

Dream on.