[slimpl] some comments about vim internals

[Larry Clapp]

On Sun, Mar 05, 2006 at 10:58:52AM -0800, Brad Beveridge wrote:
> Ok, so I've been busy converting Slime.el -> ooze.lisp.
> It is dead easy, though how well it works I have no idea yet.  I
> have written code that can connect to a running Swank server (just
> as Slime does it), the only "new" code that I've needed to write so
> far has been socket-connect, because Swank only has code to act as a
> socket server, not a socket client.  I used SBCL's sb-bsd-sockets
> module for this.
> I'm out for the rest of the day, but thought others may be
> interested in how the code shapes up if you translate slime.el ->
> common lisp.  It shapes up really really well.  I have just started
> on porting slime-dispatch-event, one of the most basic communication
> blocks.  Once that is done the rest of slime should build easily on
> it.  I am building within the slime directory against CVS, that way
> I get to easily use the Swank backend stuff.

I like what you've done; what follows discusses both your code and my
thoughts on the general design of the project.

Emacs uses slime- and sldb- prefixes because (I assume) Elisp doesn't
have packages.  I think we should take advantage of CL's packages;
don't write ooze-connect, write ooze:connect.  Also, If you need a
class or a structure, use one.  (Maybe Elisp has classes and
structures, but I haven't seen them in slime.el.)

Further, don't just rewrite slime.el in CL; I started that way, but I
wrote in Perl and had no choice.  Elisp and CL have enough
commonalities that it seems like much of slime.el would compile
unchanged in ECL.  So I guess I'd suggest code structure kind of like
this

  Emacs
    <-> presentation layer (Elisp)
      <-> backend interface (Elisp)
	<-> backend implementation (Elisp/CL)
	  <-> swank (CL)

  Vim
    <-> presentation layer (Vim+ECL)
      <-> backend interface (ECL)
	<-> backend implementation (Elisp/CL)
	  <-> swank (CL)
     
The presentation layers would be editor specific and probably totally
divergent, as far as structure or shared code.  

The backend interfaces would be non-presentation-layer-specific, but
would share a lot of structure and both talk to the same backend.  By
non-presentation-layer-specific, I mean that you should be able to
write an Elisp program that drives the backend but never talks to the
user at all, or you should be able to write a stand-alone CL program
that uses the ECL backend interface and never talks to the user -- or
maybe they do talk to the user, but they use their own presentation
layer.  Does that make sense?

The backend would compile in both Elisp and CL.  It would probably
have three sub-parts: a common part, some CL->Elisp glue that let the
common part run on Elisp, and some Elisp->CL glue that let the common
part run on CL.  (Does Elisp have #+ and #-?)


... And now I'd like to comment on my comment  :)  with an excerpt
from http://www.objectmentor.com/publications/dip.pdf:

> The Definition of a "Bad Design"
> 
> Have you ever presented a software design, that you were especially
> proud of, for review by a peer? Did that peer say, in a whining
> derisive sneer, something like: "Why'd you do it that way?". Certainly
> this has happened to me, and I have seen it happen to many other
> engineers too. Clearly the disagreeing engineers are not using the
> same criteria for defining what "bad design" is. The most common
> criterion that I have seen used is the TNTWIWHDI or "That's not the
> way I would have done it" criterion.
> 
> But there is one set of criteria that I think all engineers will
> agree with. A piece of software that fulfills its requirements and
> yet exhibits any or all of the following three traits has a bad
> design.
> 
> 1. It is hard to change because every change affects too many other
> parts of the system.  (Rigidity)
> 
> 2. When you make a change, unexpected parts of the system break.
> (Fragility)
> 
> 3. It is hard to reuse in another application because it cannot be
> disentangled from the current application. (Immobility)
> 
> Moreover, it would be difficult to demonstrate that a piece of
> software that exhibits none of those traits, i.e. it is flexible,
> robust, and reusable, and that also fulfills all its requirements,
> has a bad design. Thus, we can use these three traits as a way to
> unambiguously decide if a design is "good" or "bad".

All that to say, I hope that my comments aren't just another
TNTWIWHDI, and actually increase the flexibility, robustness, and
mobility of our code.

-- Larry