On 01/24/2012 07:26 PM, Alex Shinn wrote:
> On Wed, Jan 25, 2012 at 11:43 AM, John Cowan<cowan@mercury.ccil.org>  wrote:
>> Alex Shinn scripsit:
>>
>>> It has insertion, replacement and deletion operations.
>>> These return new objects, but that doesn't have to be
>>> any less efficient than an explicitly mutable API.
>>
>> I already made that point: immutable string APIs are sufficient.  But if
>> you *want* a truly imperative, not functional, string API, then a buffer
>> gap is your friend.
>
> And my point is that you can have a mutable API without
> exposing the implementation

Of course - but if you don't have an implementation in mind when you
design the
API then you're just blowing hot air.  A variable-length-string API as we're
talking about would not "expose" the implementation - but the reference
implementation would use a specific implementation.  Also any notes
in the specification about performance expectations would be based on
possible implementations that the API writer(s) have considered.

For example the text implementation you linked to has an obvious simple
implementation that was clearly considered when designing the api.  And
adding mutable procedures like you proposed breaks that simple
implementation
and/or would require wholsesale changes to the API: for example the
performance characteristics, when positions are valid, etc.

> - especially a bad choice of implementation.

I'm still awaiting for a better one.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports