Email list hosting service & mailing list manager

New draft of SRFI 130: Cursor-based string library Arthur A. Gleckler (14 May 2016 16:07 UTC)
Re: New draft of SRFI 130: Cursor-based string library Alex Shinn (14 May 2016 22:44 UTC)
Re: New draft of SRFI 130: Cursor-based string library William D Clinger (21 May 2016 06:53 UTC)
Re: New draft of SRFI 130: Cursor-based string library Alex Shinn (21 May 2016 16:38 UTC)
Re: New draft of SRFI 130: Cursor-based string library John Cowan (21 May 2016 17:01 UTC)
Re: New draft of SRFI 130: Cursor-based string library William D Clinger (21 May 2016 17:36 UTC)
Re: New draft of SRFI 130: Cursor-based string library John Cowan (22 May 2016 04:23 UTC)
Re: New draft of SRFI 130: Cursor-based string library William D Clinger (21 May 2016 17:23 UTC)
Re: New draft of SRFI 130: Cursor-based string library John Cowan (22 May 2016 06:38 UTC)
Re: New draft of SRFI 130: Cursor-based string library Alex Shinn (23 May 2016 02:49 UTC)
Re: New draft of SRFI 130: Cursor-based string library John Cowan (23 May 2016 03:50 UTC)
Re: New draft of SRFI 130: Cursor-based string library William D Clinger (23 May 2016 04:30 UTC)
Re: New draft of SRFI 130: Cursor-based string library Alex Shinn (23 May 2016 04:56 UTC)
Re: New draft of SRFI 130: Cursor-based string library John Cowan (23 May 2016 13:19 UTC)
Re: New draft of SRFI 130: Cursor-based string library William D Clinger (23 May 2016 15:45 UTC)
Re: New draft of SRFI 130: Cursor-based string library John Cowan (23 May 2016 16:52 UTC)
Re: New draft of SRFI 130: Cursor-based string library William D Clinger (23 May 2016 18:01 UTC)
Re: New draft of SRFI 130: Cursor-based string library John Cowan (23 May 2016 20:32 UTC)

Re: New draft of SRFI 130: Cursor-based string library John Cowan 23 May 2016 03:50 UTC

Alex Shinn scripsit:

> I initially thought immutable texts was the way to go, but from a
> practical standpoint using disjoint cursors on the same basic string
> type minimizes API fragmentation.  In particular, any API that just
> wants a piece of "text" and doesn't need cursors/indexes doesn't need
> two versions.  When you _do_ care about indexing you can make the API
> polymorphic on just the cursors, avoiding string conversions.

What I have in mind is to provide a rope API, where a rope is a Scheme
list whose members are either strings or ropes.  This could be much
simpler, make use of cursors only in a few spots, and be able to leverage
regular list operations.  Indeed, a Scheme tree API has been needed since
SRFI 1, when Olin decided to exclude tree operations, so maybe ropes
would just be supported with a few additional operations beside the
mainstream tree API.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
One art / There is / No less / No more
To do / All things / With sparks / Galore   --Douglas Hofstadter