From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tom Lord Newsgroups: gmane.lisp.guile.user,gmane.comp.version-control.arch.user,gmane.lisp.guile.devel Subject: Re: ITLA Date: Mon, 1 Mar 2004 18:50:23 -0800 (PST) Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <200403020250.SAA21846@morrowfield.regexps.com> 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> <87fzcs3y6v.fsf@alice.rotty.yi.org> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1078209139 15518 80.91.224.253 (2 Mar 2004 06:32:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 2 Mar 2004 06:32:19 +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 07:32:12 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 1Ay3Rr-0000rT-00 for ; Tue, 02 Mar 2004 07:32:11 +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 1Ay3Rj-0002NE-3b for guile-user@m.gmane.org; Tue, 02 Mar 2004 01:32:03 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1AxzfV-00056o-3G for guile-user@gnu.org; Mon, 01 Mar 2004 21:30:01 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1Axzey-0004de-GT for guile-user@gnu.org; Mon, 01 Mar 2004 21:29:59 -0500 Original-Received: from [206.40.45.221] (helo=morrowfield.regexps.com) by monty-python.gnu.org with esmtp (Exim 4.30) id 1Axzew-0004bM-Cl; Mon, 01 Mar 2004 21:29:26 -0500 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id SAA21846; Mon, 1 Mar 2004 18:50:23 -0800 (PST) (envelope-from lord@morrowfield.regexps.com) Original-To: a.rottmann@gmx.at In-reply-to: <87fzcs3y6v.fsf@alice.rotty.yi.org> (message from Andreas Rottmann on Tue, 02 Mar 2004 01:11:20 +0100) 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:2877 gmane.comp.version-control.arch.user:22119 gmane.lisp.guile.devel:3475 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3475 > From: Andreas Rottmann > 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. [....] > Sure, a clean seperation between surface syntax (for declarations) and > the internal workings is, to say the least, desirable. I basically agree with all of that but with a caveat. The distinction between "interface" and "internals" in the command processor of an extensible systems is bound to be fuzzy. I'm not saying that the coder of the command processor has to support every gross hack that anyone ever thinks of --- just that having a really simple design that promises to be stable and that invites and rewards "suprising" hacks on top of it is a good thing. > > 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? Oh, foo. Google around for Xemacs, and jwz, and rms until you get bored. The way it's gotten "recorded in history" really obscures the underlying technical issues and tends to come out as some kind of clash of personalities. (But there's some funny, albeit ironic, commentary around 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". The last paragraph is probably the most important. Keep in mind, too, that someone might want to write extensions that crawl over the set of commands -- perhaps to format a help message or perhaps to make some new kind of menu-driven interface. Keeping all the relevent data in the simplest format (e.g., s-exps following an extensible syntax over basic types) makes that easy. For example, since you have the basic idea of a command processor of the sort we're discussing, can you: (a) imagine an implementation (b) presume the implementation is built, has at least a CLI a front-end and maybe a GUI front end. (c) assume that lots of people have written code against this implementation. and then: (d) imagine implementing something like: http://segusoland.sourceforge.net in a way that everybody's existing code "just works" with the new input method? -t _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user