On Wed, Jan 25, 2012 at 12:41 PM, Per Bothner <per@bothner.com> wrote:
> 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.

Oh, by all means use a gap buffer (or whatever you want)
for the reference implementation!  But I still fail to see why
that has to be exposed in the API... or even _can_ be in
most cases.

Perhaps you're just referring to the fact that there will
be an implicit cursor, but there are a number of data
structures that make the same assumption.  A good
survey is here:

http://www.cs.unm.edu/~crowley/papers/sds/sds.html

I've used the piece table in my own editor.

More generally than that survery, there are several
very broad APIs depending on cursor behavior:

0.  Zero implicit cursors - all operations take an explicit
cursor (or simple index).

  (text-insert! <text> <i> <string>)
  (text-delete! <text> <i> <j>)

1. A single implicit immovable cursor at the end of the
text, i.e. append only, what fill-pointers give you.  No
deletion or random insertion supported.

  (text-append! <text> <string>)

2. A single implicit moveable cursor, i.e. the current
point in a text editor.

  (text-insert! <text> <string>)

3. Multiple cursors that update correctly as text is
inserted after other cursors (i.e. marks).  There
may be one or more implicit cursors for convenience
(e.g. (point) and (mark)), and the API may require
moving an implicit cursor instead of allowing them
as an argument (i.e. Emacs), though an explicit
API can be built on top of this.

--
Alex

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