This page is part of the web mail archives of SRFI 13 from before July 7th, 2015. The new archives for SRFI 13 contain all messages, not just those from before July 7th, 2015.
In article <199912151957.LAA14546@xxxxxxx>, Tom Lord <lord@xxxxxxx> wrote: > * Permitting string indexes everywhere encourages programmers > seeking to write portable code to use string indexes when > shared substrings would be simpler and less error prone. > This makes it awkward to incorporate the code such > programmers write into systems which support shared > substrings. Moreover, manipulating string indexes is > notoriously error prone and so should not be a prominent > feature of portable Scheme style. I agree, it's not a good idea to have indexes everywhere. > * The CHAR/CSET/PREDICATE convention complicates the > implementation of every procedure which uses it. Future > extensions to the library are similarly complicated. > > * The addition of a single procedure to the character set > library could simplify the convention: > > (char-set-membership cset) => predicate > > where > > (predicate c) => #t ; if c is in cset > #f ; otherwise > > With `char-set-membership', the convention should be > simplified to CHAR/PREDICATE. This sounds like a good idea. It has also the advantage that it decouples this SRFI from the charset SRFI. >Another secondary issue is whether symbols should be acceptable as >arguments to procedures that expect strings but that do not modify >those strings. I don't agree. Symbols and strings are different things, don't mix them up! >A final secondary issue is whether procedures that construct strings >from individual elements permit the use of strings (and symbols) as >elements. SRFI-13 says they do not but I have found this feature to >be natural, easy to implement, and useful. I don't rellay understand this. Can you give an example?