On 06/07/2016 11:19 AM, John Cowan wrote:
> Per Bothner scripsit:
>
>> So?  Why can't we don't define the type of a string literal to have the
>> type 'text' or 'istring' or whatever?  R7RS already informally has a
>> type 'immutable string', which is a subtype of 'string'.  I suggest
>> we formalize and extend this concept, rather than add a new 'text' concept.
>
> Because we don't want texts to be merely R7RS-immutable, which means that
> mutation may succeed, may fail, or may crash your Scheme.  We want them
> to be fully immutable so that they can be reliably shared.  And that
> concept is neither a subtype nor a supertype of mutable strings, as I
> explained in an earlier post.

Let me try again.  R^RS/R7RS effectively have this type hierarchy:

string
- immutable strings (string-set! throws exception)
- mutable strings (string-set! allowed - need not be O(1)))

For R7RS-large I'm proposing a extension/modification:

string
- immutable strings (string-set! throws exception)
   - SRFI-135 text - guaranteed O(1) string-ref
   - possibly other immutable strings (e.g. java.lang.String on JVM)
     (However, a pure portable R7RS-large would not use such strings)
- mutable strings (string-set! allowed - need not be O(1)))

Once we have this hierarchy, we can discuss naming conventions:
I would recommend renaming 'text' to something like 'istring' or
something else that makes it clear that it is a sub-type of string.
Maybe 'fstring' for "fast/fixed string".

The SRFI-135 uses 'textual' for the common supertype of 'string' and 'text'.
I suggest using 'string' for this common supertype, as that matches past history
better IMO.

On 06/07/2016 12:46 PM, Taylan Ulrich Bayırlı/Kammer wrote:> Per Bothner <xxxxxx@bothner.com> writes:
> I would say the main problem is that so long as various standard
> operations are guaranteed to return mutable strings in R7RS, we need a
> different type with corresponding operations.

We need a different type, with possibly different operations,
but that doesn't prevent 'text' (or whatever we call it) from being
a subtype of a 'string' type.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/