Re: Using libunistring for string comparisons et al

[Ludovic Courtès]

Hello Unicode fellows!  :-)

Mark H Weaver <address@hidden> writes:

> Andy Wingo <address@hidden> writes:
>>> Ludovic, Andy and I discussed this on IRC, and came to the conclusion
>>> that UTF-8 should be the encoding assumed by functions such as
>>> scm_c_define, scm_c_define_gsubr, scm_c_define_gsubr_with_generic,
>>> scm_c_export, scm_c_define_module, scm_c_resolve_module,
>>> scm_c_use_module, etc.
>>
>> Can we step back a little and revisit this decision?
>>
>> Clearly, we need to specify the encoding for these procedures, and have
>> it not be locale encoding.  However I don't think we would be breaking
>> anyone's code if we simply restricted it to 7-bit ASCII.

[...]

> For those who don't speak English but wish to hack with Guile, being
> able to write code in their own language is a compelling reason.

As Andy said, our intent is to have people write Scheme code, not C.
Scheme code supports native languages.

[...]

> We have those convenience functions for a reason.  You recently proposed
> several more convenience functions, so apparently you prefer to save
> keystrokes like the rest of us.  I'm sure our non-english-speaking
> comrades feel the same way.
>
> Let me ask you this: why would you oppose changing the scm_c_ functions
> to use UTF-8 by default?

I knew adding these C functions would amount to opening a can of worms. :-)

So I understand your comment.  This would have been a non-issue in
Scheme code but in C we’re in troubles.

Up to 1.8 ‘const char *’ in Guile’s API implicitly meant ASCII or
locale-encoded strings; internally, it was only ASCII though.

Thanks,
Ludo’.