From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.user,gmane.comp.version-control.arch.user,gmane.lisp.guile.devel Subject: Re: ITLA Date: Tue, 02 Mar 2004 01:11:20 +0100 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <87fzcs3y6v.fsf@alice.rotty.yi.org> References: <200402292232.51103.clinton@unknownlamer.org> <87r7wdma3d.fsf@alice.rotty.yi.org> <87n0707icl.fsf_-_@alice.rotty.yi.org> <200403011904.LAA20046@morrowfield.regexps.com> <87r7wc4bxm.fsf@alice.rotty.yi.org> <200403012155.NAA20825@morrowfield.regexps.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1078206673 11929 80.91.224.253 (2 Mar 2004 05:51:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 2 Mar 2004 05:51:13 +0000 (UTC) Cc: gnu-arch-users@gnu.org, guile-user@gnu.org, ttn@glug.org, guile-devel@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Mar 02 06:51:02 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ay2o1-0007qj-00 for ; Tue, 02 Mar 2004 06:51:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1Ay2kn-00013R-Bj for guile-user@m.gmane.org; Tue, 02 Mar 2004 00:47:41 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1AxyoH-0005Zy-5B for guile-user@gnu.org; Mon, 01 Mar 2004 20:35:01 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1Axymv-0005Dq-A0 for guile-user@gnu.org; Mon, 01 Mar 2004 20:34:10 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.30) id 1Axymt-0005D0-S9 for guile-user@gnu.org; Mon, 01 Mar 2004 20:33:36 -0500 Original-Received: (qmail 18826 invoked by uid 65534); 2 Mar 2004 01:26:51 -0000 Original-Received: from chello212186006140.401.14.univie.teleweb.at (EHLO garibaldi) (212.186.6.140) by mail.gmx.net (mp007) with SMTP; 02 Mar 2004 02:26:51 +0100 X-Authenticated: #3102804 Original-Received: from ivanova.rhinosaur.lan ([192.168.1.9] helo=ivanova) by garibaldi with esmtp (Exim 4.30) id 1AxxVI-0002kc-Kb; Tue, 02 Mar 2004 01:11:20 +0100 Original-Received: from andy by ivanova with local (Exim 4.30) id 1AxxVI-0004v4-7l; Tue, 02 Mar 2004 01:11:20 +0100 Original-To: Tom Lord In-Reply-To: <200403012155.NAA20825@morrowfield.regexps.com> (Tom Lord's message of "Mon, 1 Mar 2004 13:55:25 -0800 (PST)") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) X-Spam-Score: -3.2 (---) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:2876 gmane.comp.version-control.arch.user:22116 gmane.lisp.guile.devel:3474 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2876 Tom Lord 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 () (cwd #:init-thunk getcwd #:accessor working-directory) (flags #:init-value '() #:getter flags)) (define-method (invoke (tla ) (command ) (args )) "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 )) (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