Email list hosting service & mailing list manager

extending the discussion Tom Lord (15 Dec 1999 19:57 UTC)
Re: extending the discussion d96-mst@xxxxxx (16 Dec 1999 21:20 UTC)

Re: extending the discussion d96-mst@xxxxxx 16 Dec 1999 21:05 UTC

In article <199912151957.LAA14546@emf.net>, Tom Lord <xxxxxx@emf.net> 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?