guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using libunistring for string comparisons et al


From: Andy Wingo
Subject: Re: Using libunistring for string comparisons et al
Date: Tue, 29 Mar 2011 15:35:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hi Peter,

On Tue 29 Mar 2011 14:39, Peter Brett <address@hidden> writes:

> Andy Wingo <address@hidden> writes:
>
>> Finally, users are moving away from these functions anyway.  The thing
>> to do now is to write Scheme, not C: and in Scheme we do the Right
>> Thing.
>
> I hope I'm misinterpreting this statement.  Using Guile as an extension
> language for applications depends *heavily* on writing large amounts C
> to provide fundamental API functions in C Scheme code can then invoke to
> manipulate the application's state.  Is this disencouraged with Guile
> 2.0, then?

The short answer is, no, Guile still has a good C API, and its C API is
improving as well.

The long answer is that, given a choice, users should write in Scheme.
In the past there wasn't much of a choice for some things, as Guile was
slower and did not offer any dynamic FFI capability.  But now that Guile
is more capable, people should reconsider, even if they end up staying
with C.

Furthermore, the discussion at hand is about which encoding to choose
for routines taking a const char*.  We all agree that it should not, for
most cases, be the locale.  The thing under discussion is should it be
ASCII or latin1 or utf8.

Note that this dilemma was not to be had with pre-2.0 Guile, as pre-2.0
Guile did not do unicode properly.

>> So let's not let this particular consideration weigh too heavily on our
>> choice of character encoding.
>
> It would certainly make my life as a downstream application maintainer
> much, much easier if all Guile API functions that accept a C string
> argument expected UTF-8.

Understood.  It looks like we'll go that way for 2.2.

> Having to double check (either by an explicit save/restore or by code
> auditing) that whenever a string is passed to Guile that the locale is
> set up correctly is a pain.

This should not be the case now -- you can use scm_from_utf8_string,
etc, and as long as you are referencing ascii identifiers, the locale
shouldn't matter for scm_c_module_ref et al.

Andy
-- 
http://wingolog.org/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]