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 13:55:25 -0800 (PST) Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <200403012155.NAA20825@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> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1078197179 30414 80.91.224.253 (2 Mar 2004 03:12:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 2 Mar 2004 03:12:59 +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 04:12:50 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 1Ay0Kw-0001wS-00 for ; Tue, 02 Mar 2004 04:12:50 +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 1Ay0Kd-0002Mu-0g for guile-user@m.gmane.org; Mon, 01 Mar 2004 22:12:31 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1Axv4C-0001Xq-HA for guile-user@gnu.org; Mon, 01 Mar 2004 16:35:12 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1Axv3f-0001IG-O4 for guile-user@gnu.org; Mon, 01 Mar 2004 16:35:11 -0500 Original-Received: from [206.40.45.56] (helo=morrowfield.regexps.com) by monty-python.gnu.org with esmtp (Exim 4.30) id 1Axv3d-0001FV-Iv; Mon, 01 Mar 2004 16:34:38 -0500 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id NAA20825; Mon, 1 Mar 2004 13:55:25 -0800 (PST) (envelope-from lord@morrowfield.regexps.com) Original-To: a.rottmann@gmx.at In-reply-to: <87r7wc4bxm.fsf@alice.rotty.yi.org> (message from Andreas Rottmann on Mon, 01 Mar 2004 20:14:29 +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:2873 gmane.comp.version-control.arch.user:22109 gmane.lisp.guile.devel:3473 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2873 > From: Andreas Rottmann > 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