Re: ITLA

[Tom Lord <lord@emf.net>]

    > From: Andreas Rottmann <a.rottmann@gmx.at>

    > I'll quote parts of your initial ITLA mail here, adding my view how
    > things would/could look like when *I*'d do this in Guile, building
    > upon/integrating my ITLA stuff.

    > ,----
    > |   Each interactive command will be defined by an ordinary Scheme
    > |   procedure supplemented with a _declaration_.  The declaration lists:
    > |   [....]

    > I'd make the declaration result in registering a GOOPS class instance
    > somewhere. Type declarations would map to classes directly, along with
    > generics that deal with I/O, completion, etc.

"To GOOPS or not to GOOPS" is for me, at this stage, an implementation
detail -- it might or might not be the right thing.

The critical thing, in my view, is to have a data-driven system
(programmers write declarations) such that you can implement various
flavors of Emacs' function "call-interactively" -- for CLIs, for smart
terminals, for GUIs, etc.

Getting the abstraction level of the declarations right is critical --
both for abstraction over interaction environments (e.g., CLI vs. GUI)
and for accessability (e.g., make it possible to write  a single
implementation of "read-file-name" for blind users and have that used
for _all_ commands that read file names).

Ok, I exaggerate slightly -- I'm not quite agnostic about using GOOPS
in this particular area.  Really, I'm mostly against it except as it
helps "internally" in various modules.  And the reason has to do with
(surprise!) modularity.  Here's why:

Declarations are going to be _written_ as simple list structures
following some (extensible) syntax -- just as they are in emacs (the
"interactive" declaration mechanism).    There's a choice here between
having all the dependent code process that data directly, in that
simple form, and trying to make an abstraction around it.

Now, we're talking about making _extensible_ applications (like
Emacs).  So we should imagine lots of different people and code bases
here.  There are:

   ~ many, many people writing declarations.   Some of these wind up
     in the core distribution but many do not.    Therefore, it's
     important to Get Right, early on, a declaration syntax that will
     be stable for a very long time -- we can't afford to continuously 
     tweak it and then tell people "update your declarations".

   ~ a few people writing the core interaction engines.   There will
     be a _little_ bit of code to do things like CLI processing based
     on declarations.   This goes in the main distribution.   The
     challenge for this group is to build an interaction framework
     that is extensible in _unanticipated_ ways.

   ~ interaction customizers:  people who make local customizations of
     interaction loops (such as for accessibility)

The disaster that can happen here is if the code bases of these three
groups becomes two tightly interdependent or interdependent in too
complex ways.  There's no room in this wildly distributed and
uncollected style of development (the kind that characterizes
extensible applications) to make a "global change".  So, while it
might be ok if, say, the interaction engine uses GOOPS internally, it
would be disasterous if every little change to the interaction engine
classes required users in the other two classes to update their code
correspondingly.

One way to avoid such disasters is the "lego approach to lisp
programming".  People sometimes compare object oriented programming to
legos but it's a poor analogy.  Legos classically have a finite number
of types of parts, all of which plug together in simple ways.
Object-oriented style, on the other hand, winds up with hundreds or
thousands of parts, with lots of complex rules about what fits
together with what.  A better lego analogy than object oriented
programming is programming just using basic lisp types for everything
and taking great care to specify extensible syntaxes for data
structures built on top of those.  Perhaps you are familiar with the
famous debate between Jamie Zawinski and RMS about whether events and
keymaps should be built up out of simple lisp types (RMS) or should be
a special disjoint type (jwz).  RMS was, in effect, applying the "lego
principle" and I think his was the superior idea.

It's kind of a situation where K.I.S.S. is the dominant design
consideration.


-t



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user