Re: strings draft Paul Schlie (23 Jan 2004 02:48 UTC)
|
Re: strings draft
tb@xxxxxx
(23 Jan 2004 03:45 UTC)
|
Re: strings draft
Paul Schlie
(23 Jan 2004 12:16 UTC)
|
Re: strings draft (musings)
Paul Schlie
(23 Jan 2004 14:15 UTC)
|
Re: strings draft
tb@xxxxxx
(23 Jan 2004 18:53 UTC)
|
Re: strings draft
Paul Schlie
(23 Jan 2004 21:26 UTC)
|
Re: strings draft (premature, need first class type definition support first?)
Paul Schlie
(24 Jan 2004 21:16 UTC)
|
Re: strings draft (premature, need first class type definition support first?)
Tom Lord
(24 Jan 2004 22:05 UTC)
|
Re: strings draft (premature, need first class type definition support first?)
Paul Schlie
(24 Jan 2004 22:17 UTC)
|
Re: strings draft Paul Schlie 23 Jan 2004 02:48 UTC
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-