[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Re: ITLA

From: Andreas Rottmann
Subject: [Gnu-arch-users] Re: ITLA
Date: Mon, 01 Mar 2004 20:14:29 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Tom Lord <address@hidden> writes:

>     > I'm not totally clear what you mean here, and how that relates to an
>     > Arch<->CVS gateway. Anyway, you might be interested in my ITLA
>     > thingy[0].
> You appear to have left out the footnote.
Indeed: [0]

> I'd like to point out some info about the ITLA idea.  ITLA is not, at
> it's core, tla specific -- it's a generic engine for making
> interactive Scheme programs, both CLI and GUI.
> See: 
I obviously missed the initial discussion. Big thanks for pointing
this out.

> The ITLA framework is one of the target applications for Pika Scheme
> but it will be a long time before Pika is ready to start implementing
> it.   There's no reason not to start on the framework earlier, using
> Guile (and many good reasons to do so).
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:
|   ~ the name of the command
|   ~ a documentation string for the command
|   ~ a list of options and parameters to the command, each
|     specified by:
|         + a parameter name
|         + a "type declaration" (e.g., "string", or "new-archive-name",
|           or "existing-archive-name", or "archive-name".)
|         + a description of how it is parsed from options and
|           arguments provided on command lines
|         + a default value
|         + an optional prompt string
|         + an optional help string for the parameter
|   ~ a "type declaration" for the output of the command
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.

|   The "main loop" of itla reads partially specified command lines,
|   looks up the interactive command, parses any options and arguments
|   already provided, and enters a generic "argument editor" that
|   prompts for the remaining arguments
|   Once the parameter editor is done collecting parameters, the 
|   procedure that defines the command is called.   Typically, it
|   works by running tla as a subprocess.
This is the part on which "my" ITLA focuses currently: Offering a
GOOPS-based scripting interface to tla.

|   It can also recursively
|   invoke the command loop to run particular commands (e.g., import 
|   might recursively call "prepare-tree" and/or "make-archive").
Right now, I use the Guile repl (as can be seen from the screen-shot
at [0]), which is of course not the most user-friendly thing to do

|   The rationale for this approach is four-fold:

Full ACK here.

| * Usefulness for GUIs
|   There is nothing that says that the parameter editor and output 
|   handler have to be TTY programs -- nothing that says they have
|   to do their work by printing prompts and reading keyboard input.
|   For example, a GUI might include an alternative form of the 
|   parameter editor that knows how to translate _any_ command 
|   declaration into a "form".
|   That approach can make writing a complete GUI a much smaller task
|   and effort can focus on generic parts that help the entire 
|   interface (such an an "archive name selector").
|   It also means that a GUI can automatically just "work" as new
|   commands are added to itla.   For example, after I load a set
|   of extensions defining commands specific to the tla project,
|   these can automatically appear on a menu or toolbar and immediately
|   have a GUI interface.

I'd use Guile-GObject[1] here. 


Cheers, Andy
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden      | GnuPG Key:
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Latein ist das humanoide Äquivalent zu Fortran.
   -- Alexander Bartolich in at.linux

reply via email to

[Prev in Thread] Current Thread [Next in Thread]