[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 02 Mar 2004 01:11:20 +0100
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
Tom Lord <address@hidden> 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
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
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".
Andreas Rottmann | address@hidden | address@hidden | address@hidden
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.
- Re: Extended -e syntax, Andreas Rottmann, 2004/03/01
- Message not available
- Arch and Guile, Andreas Rottmann, 2004/03/01
- ITLA (was Re: Arch and Guile), Tom Lord, 2004/03/01
- Re: ITLA, Andreas Rottmann, 2004/03/01
- Re: ITLA, Tom Lord, 2004/03/01
- Re: ITLA,
Andreas Rottmann <=
- Re: ITLA, Tom Lord, 2004/03/02
- Re: ITLA, Andreas Rottmann, 2004/03/02
- Re: ITLA, Miles Bader, 2004/03/02
- Re: ITLA, Neil Jerram, 2004/03/04
- Re: ITLA, Andreas Rottmann, 2004/03/04