Re: ITLA

[Andreas Rottmann <a.rottmann@gmx.at>]

Tom Lord <lord@emf.net> 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] http://stud3.tuwien.ac.at/~e9926584/ITLA

> 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: 
>
>      http://mail.gnu.org/archive/html/gnu-arch-users/2003-11/msg00291.html
>
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:
| 
[sip]

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. 

[1] http://www.gnu.org/software/guile-gtk/docs/

Cheers, 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

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


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user