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)
|
(maybe scheme should first be refined to enable the definition of new first class types/subtypes, prior to requesting any particular new type support?) Upon further consideration of the proposed Unicode character support enhancements, which I presume are desired to enable more generalized language/script-system text processing; I suspect that the targeted level of abstraction of the proposed solution is likely wrong, or at least minimally premature. As I believe had been cited in discussion, possibly rather than worrying initially about how to extend scheme to more natively peek or poke at strings composed of one new extended character set type or another (which one could/should even arguably use vectors as a proxy for strings for); such a proposal likely needs to focus on language/script centric solutions, which may themselves utilize whatever character set is most applicable to that language and/or associated target platform/application requirements. Where the interface level of abstraction I would guess should be more capable of being able to manipulate words, sentences, capitalization, punctuation, justification, etc., and determine if whole words are lexically and/or syntactically equivalent, plural, etc. within a given language and script system for example (including the SCHEME language); not how many different ways one can encode some arbitrary letter of a particular alphabet, which I don't suspect should even be part of a core programming language any more than minimally necessary. As any given programming language should be capable of manipulating arbitrary data types, which the language itself should enable the native definition of, without that data type needing to itself be native to the language. This I suspect is possibly really what folks should be spending their time to refine, because if scheme more natively supported the ability to define new first-class data types/sub-types, and correspondingly extend it's core procedures to be aware of them; numerous new facilitates and features could be experimented with and refined, without having to require a language revision or new implementation to enable it. -paul-