Re: Using libunistring for string comparisons et al

[Noah Lavine <noah.b.lavine@gmail.com>]

Hello all,

>> Furthermore, such a default would not restrict our users at all -- they
>> can always use the non-_c_ variants with a symbol explicitly constructed
>> with (e.g.) scm_from_utf8_symbol.
>
> 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.

I'm afraid I don't know enough about this issue to understand it
completely, but some idea seemed a little off. I think there are two
questions being conflated here: what Guile's internal string
representation should be, and what convenience functions should be
provided for users to easily make symbols.

The string representation is a somewhat difficult choice involving
tradeoffs. However, it seems to me that the functions provided to make
symbols should be more or less independent of that. After all, these
are *convenience* functions, whose functionality could always be
implemented in the more general underlying API. So I think the thing
to do here is make a list of what string formats you think people
should easily be able to use, and then make convenience functions for
each of them. Clearly ASCII is one. Perhaps UTF-8 is another.

(Unless of course you mean macros that need to define things at
compile time. In that case, you're really limited by C's lack of
compile-time computation ability, and I think the only real solution
would be to implement a preprocessor that can convert strings to
different formats. For instance, Guile could easily be such a
preprocessor.)

Noah