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
