Re: extending the discussion d96-mst@xxxxxx (16 Dec 1999 21:05 UTC)
Re: extending the discussion d96-mst@xxxxxx 16 Dec 1999 21:05 UTC
In article <199912151957.LAA14546@emf.net>, Tom Lord <firstname.lastname@example.org> 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
> (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
I don't agree. Symbols and strings are different things, don't mix them
>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?