🚀 go-pugleaf

Well, I just finished reading the full "sam" paper from research.att.com,
and I'm driven to try and implement a version of it. A line-oriented-only
subset, based on a "buffer" software component I've been working on. Before
I get started on this project, I'd like to get some feedback: is anyone
else similarly driven? How close should I go to the sam model (I want to
create some regular expression macros since I won't be able to cut and
paste, and I can't see typing "range x/.*\n/ command" all the time)? Should
I do a stream version?

Another consideration is that the implementation details in the paper are
somewhat discouraging... there's obviously a lot of work in it. It would be
SO nice to be able to just get the damn thing... oh well, hopefully it'll
be there in SVR7 or so...

The working name for the project is "ham". The first lightweight version will
be called "turkey", and will implement the barest minimum (I think I'll leave
the {...} construct for version 2, for example).

The buffer code is currently done as a simple buffer gap, with floating
marks on each buffer (every operation is done on marks or pairs of marks).
It works as is, and it should be fairly simple to modify it to use a
different algorithm (such as the structure described in Pike's paper) without
breaking the interface definition. Is anyone interested in that code as is?
If so I'll write it up and post it.
-- 
/L{lineto}def /M{moveto}def 72 72 translate 24 24 scale newpath 0 19 M 0 25 L 4
21 L 0 16 M 5 16 L 8 13 L 4 13 L 1 16 L 8 13 M 8 8 L 12 8 M 12 13 L 10 8 M 12 8
L 10 6 L 8 8 L 10 8 L 20 16 M 15 16 L 12 13 L 16 13 L 19 16 L 20 19 M 20 25 L
16 21 L stroke showpage % Peter da Silva % 77487-5012 USA % +1 713 274 5180