On 07/15/2016 07:59 AM, John Cowan wrote:
> Marc Nieper-Wißkirchen scripsit:
>
>> As an analogue, consider `#(1 2)' and `(vector 1 2)'. The literal is
>> immutable, the vector returned by the procedure application is
>> mutable. However, there is no predicate distinguishing between the
>> two cases.
>
> That's because implementations are not required to make a distinction
> between the two, and some do not.  Chicken and Chibi, for example, have
> only mutable versions of either strings or vectors.  *Users* must make
> the distinction in portable code, but that's a different matter.

I don't think any implementation that allows over-writing literals is a good
candidate for "Scheme-large".  I know Fortran allowed it in the 50s,
but that has not been considered kosher since then.

> As far as I can tell, implementations like Chibi, where the internal
> representation is UTF-8 and no mutable/immutable distinction is
> made, can't implement SRFI 140 without changing that, because SRFI
> 140 guarantees that string operations on literal strings are O(1).
> That seems to me to be a high barrier to the adoption of SRFI 140,

So is the goal for WG2 to only add features that can be implemented
as pure-library additions?  If so, why is SRFI-124 (ephemerons) even
in contention?

> and the chief reason why SRFI 140 is not just a blanket rename of
> SRFI 135.

Of course.  The point of SRFI-140 is to evolve the Scheme language's
handling of strings in a way that that is coherent and breaks as little
code as possible.  (My proposal is that no code that uses strict R7RS libraries
will be broken; only possibly code that uses an informal "default" library.)

SRFI-135's goal is to be implementable as a pure-library that can be imported
on existing implementations.  SRFI-140 may require more fundamental changes.
However, it is not something that is difficult to implement - unlike ephemerons.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/