Re: [Scheme-reports] fresh empty strings Ray Dillinger (24 Jan 2012 16:53 UTC)
Re: [Scheme-reports] fresh empty strings John Cowan (24 Jan 2012 19:05 UTC)
Re: [Scheme-reports] fresh empty strings Per Bothner (24 Jan 2012 19:25 UTC)
Re: [Scheme-reports] fresh empty strings John Cowan (24 Jan 2012 20:26 UTC)
Re: [Scheme-reports] fresh empty strings Per Bothner (24 Jan 2012 20:46 UTC)
Re: [Scheme-reports] fresh empty strings John Cowan (24 Jan 2012 21:20 UTC)
Re: [Scheme-reports] fresh empty strings Alex Shinn (25 Jan 2012 00:26 UTC)
Re: [Scheme-reports] fresh empty strings Per Bothner (25 Jan 2012 01:09 UTC)
Re: [Scheme-reports] fresh empty strings Alex Shinn (25 Jan 2012 02:08 UTC)
Re: [Scheme-reports] fresh empty strings John Cowan (25 Jan 2012 02:31 UTC)
Re: [Scheme-reports] fresh empty strings Alex Shinn (25 Jan 2012 02:35 UTC)
Re: [Scheme-reports] fresh empty strings John Cowan (25 Jan 2012 02:44 UTC)
Re: [Scheme-reports] fresh empty strings Alex Shinn (25 Jan 2012 03:26 UTC)
Re: [Scheme-reports] fresh empty strings Per Bothner (25 Jan 2012 03:43 UTC)
Re: [Scheme-reports] fresh empty strings Alex Shinn (25 Jan 2012 12:58 UTC)
Re: [Scheme-reports] fresh empty strings Per Bothner (25 Jan 2012 19:59 UTC)
Re: [Scheme-reports] fresh empty strings Alex Shinn (25 Jan 2012 23:49 UTC)
Re: [Scheme-reports] fresh empty strings John Cowan (25 Jan 2012 21:00 UTC)
Re: [Scheme-reports] fresh empty strings Ray Dillinger (25 Jan 2012 18:57 UTC)
Re: [Scheme-reports] fresh empty strings John Cowan (25 Jan 2012 01:38 UTC)

Re: [Scheme-reports] fresh empty strings Per Bothner 24 Jan 2012 20:45 UTC

On 01/24/2012 12:25 PM, John Cowan wrote:
> Per Bothner scripsit:
>
>> In other words: mutable fixed-length strings are effectively useless,
>> but we have to have mutable strings.
>
> I am far from convinced of that.  I think the arguments for providing
> mutable strings only (simplicity, thread safety, sharability, memory

I assume s/mutable/immutable/ above.

> efficiency, no ownership issues, no copying) are quite convincing,
> and I favored that position, but I couldn't get enough support in
> WG1 to remove them from the language, since they are an IEEE feature.
> (Just putting them in a separate module, especially a mandatory module
> as is done in R6RS, doesn't really help implementers or users.)
>
>> That just requires adding a few functions like string-replace-substring
>> to make mutable strings into something actually usable.  The normal
>> implementation could be a simple buffer-gap.
>
> I'd be happy to have a buffer-gap package in R7RS-large.  I've added
> it to the RevoteDocket (somewhat paradoxically named; it is really the
> "input hopper" for new ideas).

I thinking a simple buffer-gap implementation might be cheap enough
that it could serve as the standard implementation of mutable strings.
This especially makes sense if an implementation uses a variable-length
string representation, like UTF-8 or UTF-16, since in that case you
kind of need it anyway.

I agree this is (at least) premature for R7RS-small.  I might experiment
with it in Kawa and if so write up a SRFI.

>> Is there an prior art for doing anything like that?
>
> Emacs buffers is the obvious prior art.

I mean a Scheme API.  Emacs buffers are much more heavy-weight than
strings.  Even better prior art would be a Scheme (or at least Lisp-family)
dialect where mutable strings are variable-length.  (Common Lisp
allows adjustable arrays and thus adjustable strings, but it doesn't
have the kind of API I'm talking about, nor is buffer-gap normally used.)
--
	--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