Email list hosting service & mailing list manager

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?) Paul Schlie 24 Jan 2004 21:16 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-