Re: ITLA

[Andreas Rottmann <a.rottmann@gmx.at>]

Tom Lord <lord@emf.net> writes:

> "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).
>
So far, I agree.

> 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".
>
I also agree here, but IMO, this doesn't speak against using GOOPS as
a "back end"; i.e. making the declarations create GOOPS instances, but
not letting that shine thru at the surface.

>    ~ 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.
>
Sure, a clean seperation between surface syntax (for declarations) and
the internal workings is, to say the least, desirable.

> One way to avoid such disasters is the "lego approach to lisp
> programming".  [...]
>
> 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.
>
Do you have any references to this discussion?

> It's kind of a situation where K.I.S.S. is the dominant design
> consideration.
>
If you talk just about the "declarative level", I could well agree, if
stuff doesn't get too awkward because of it.

For instance, I just find that generics are just too damn convienent
for managing the namespace, so I don't really want to miss them: You
get away with short names, since generics are mergable (should names
ever collide) if you just keep prefixes for the classes. A short
example out out the (itla tla) module is:

(define-class <tla> ()
  (cwd #:init-thunk getcwd #:accessor working-directory)
  (flags #:init-value '() #:getter flags))

(define-method (invoke (tla <tla>) (command <string>) (args <list>))
  "Returns the output of the tla command as a list of lines."
  (if (flag-set? tla 'verbose)
      (format #t "invoking tla: ~S ~S\n" command args))
  (let ((check (if (string= command "changes")
                   (lambda (val) (<= 0 val 1))
                   (lambda (val) (= 0 val)))))
    (if (flag-set? tla 'dry-run)
      '()
      (apply command-output/check check "tla" (cons command args)))))

So you can just:

(define *tla* (make <tla>))

(invoke *tla* "get" '("--link" "foo--bar--1.0" "some-dir"))

Without using GOOPS, this would probably look more like:

(define *tla* (make-tla))

(tla-invoke *tla* "get" '("--link" "foo--bar--1.0" "some-dir"))

The tla- prefix in this case is not that inconvient, so this is a bad
example, but there are types, for which no suitable
(i.e. readable/easily recognicable) short prefixes can be found.

Of course, this is just low-level stuff, and would never shine thru up
to the "declarative level".

Regards, Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.


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