[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] fresh empty strings

Per Bothner scripsit:

>> I am far from convinced of that.  I think the arguments for providing
>> mutable strings only
> I assume s/mutable/immutable/ above.

Oops, yes.

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

Please do, or else as an R7RS-large package (send it to me and I'll post

>> Emacs buffers is the obvious prior art.
> I mean a Scheme API.  Emacs buffers are much more heavy-weight than
> strings.

Indeed.  However, my experience is that it's easier to start with a
heavyweight but complete API and cut it back by removing things that
aren't essential.

> 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.)

Common Lisp, and following it MIT Scheme, have fill pointers.  In MIT
Scheme it is always provided when a string is allocated, so you can
effectively shrink a string from its initial size, but not grow it.  The
MIT interface is just string-maximum-length and set-string-length!.  It
isn't defined whether the contents of a string past the current length
are preserved, but simple tests suggest that they are.  Unlike CL,
characters beyond the current length are fully inaccessible.

John Cowan           http://www.ccil.org/~cowan            cowan@x
One of the oil men in heaven started a rumor of a gusher down in hell.  All
the other oil men left in a hurry for hell.  As he gets to thinking about
the rumor he had started he says to himself there might be something in
it after all.  So he leaves for hell in a hurry.    --Carl Sandburg

Scheme-reports mailing list