This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
Or one could more simply reinforce the notion scheme's character type is simply distinct from (although likely a subset of) the definition of a new character type targeted to support more generalized text processing than is minimally necessary to support the definition and processing of the scheme language itself (which is all that scheme's character type is specified/suited to be sufficient for). Where it seems more than reasonable to propose the adoption of the basic 16-bit unicode character set definition (minus eszett interpretation), as the basis for a more generalized character type, which would greatly improve upon the current situation, without suffering from the potential complexities associated with anything fancier with little marginal benefit. Where independently it seems like it wouldn't hurt to tighten up scheme's native character set type and supporting procedure semantics a little as well. (with respect to how does C get at scheme's or unicode character string elements; it seem that although potentially somewhat less optimal at times, they should be accessed through index and/or iterator functions, for the same reasons argued to provide implementation flexibility, and protect C programmers from their potential idiosyncrasies.) -paul-