Re: Flexichain library specification

Hello, 

Luke Gorrie writes:
 > > We decided to write this library because something with this
 > > functionality is often needed, as is evident from the numerous times
 > > people (including myself) have come up with less efficient and less
 > > general code for a subset of this functionality. 
 > 
 > I don't think it's always a subset though. Your interface looks
 > similar to Emacs (one linear chunk of text with markers/cursors), but
 > different to Hemlock and Goatee (doubly-linked list of 'line' objects
 > each containing some text). 

Well, as it turns out, a flexichain can be used instead of the
doubly-linked list; in fact it was designed that way.  Goatee and
Hemlock would typically use a flexichain containing line objects, each
line object being essentially another flexichain.  

 > Other possibilities exist too --
 > e.g. immutable (copy on change) versions which can give you 'undo' for
 > "free" (check out Boehm's 'cord' structure [1]). Each design makes
 > some things easier, some harder, and some just different.

Right.  I was not trying to imply that flexichain would be for
everyone. 

 > I reckon that experimenting to find the best interface to build the
 > rest of the editor around is the worthwhile part of editor hacking --
 > it would be a shame to standardise it away. 

Nobody is trying to prevent editor hackers who so desire to come up
with the buffer representation of their dreams.  Some resulting
representations can use flexichain for certain parts, others can not.

I think the best way to view this proposal is to think of it as a
generalization of 4 existing different representations (Goatee buffer,
Hemlock buffer (though I have not looked closely at Hemlock), Emacs
buffer, and Gsharp buffer).  There is therefore hope that we could
eliminate such duplication of effort and concentrate on something more
interesting.  If there are more than 4 potential clients, that's even
better; if not that's still a substantial gain in maintenance effort. 

 > (I also prefer the Hemlock
 > interface to the Emacs one, and hear tell that the Dylan editor has
 > improved things further, so I'm not sure that Emacs would make the
 > best model in either case.)

See above.  The flexichain could be used to represent individual
lines. 

 > Performance could be an argument in favour of a premade library, but
 > don't the simple data structures tend to have adequate performance in
 > practice?

I am sure they do.  However, I look at things the other way around.
Why write your own simple data structure (the way I did for Gsharp)
which will have to be written, maintained, extended, debugged, etc.,
and which will most likely not be terribly abstract, so tends to
expose implementation details to the rest of the application, instead
of using a library that is more general, probably faster,
independently maintained and documented, and which has a cleaner
interface? 

Hell, even if I turn out to be the ONLY client of it, it was worth it,
just to pin down the abstract interface as opposed to exposing
implementation details.  

Take care, 
-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------