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.
> From: Paul Schlie <schlie@xxxxxxxxxxx> > (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; That's a goal -- but only an indirect goal. The proposed changes should remove obstacles to writing Scheme programs that do Unicode text processing using STRING? and CHAR? as basic types. However, the proposed changes are _not_ intended to provide sufficient mechanism to write Unicode text processes in a portable way. It will take additional standards (for which SRFIs are appropriate, I think) to enable portable implementation of Unicode text processes. The proposed R6RS changes are also intended to clarify some points that are arguably ambiguous about R5RS -- the contents of the portable character set and identifier equivalence over that character set, for example. The proposed R6RS changes clarify the meaning of integer string indexes over the portable character set and give guidence about how to extend the meaning of string indexes in Unicode-supporting implementations. This point in particular is critical for a portable FFI (and also for data-exchange between Scheme environments). The proposed R6RS changes are intended to ensure the possibility of writing portable Scheme programs that can process source texts of their host implementations where those source texts consist of standard syntax but an extended character set. > 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); Things such as words and sentences are linguistic concepts. R6RS should enable people to write, for example, SRFIs about these things -- it should not provide those things itself. The kinds of processing needed to handle Scheme source texts is quite a bit simpler than text processing. It would be weird and needlessly restrictive to try to define Scheme source text processing as a specific example of a more general linguistic text processing. > 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. I think you are on the scent of a red herring. -t