[Top][All Lists]

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


From: Andreas Rottmann
Subject: Re: ITLA
Date: Tue, 02 Mar 2004 15:04:28 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Tom Lord <address@hidden> writes:

>     > 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.
If you have a brief glance at the codebase, you'll see that there is a
(itla ui) module. This currently is a crude wrapper around a single
<tla> instance, using the Guile REPL and GOOPS for user-interaction. I
just came up with this as a quick hack to have something to play
around with, not intending it as a permanent solution. So my question
is: do you feel comfortable with this design (a low-level interface,
using GOOPS, designed for maximum flexibility) and an eventual command
processor/UI built on top of that?

I think this seperation is warranted, to quote you[0]:

| (define-command (init-tree version dir nested?)
|         (help-message   (category tree)
|                           (% tla init-tree -H))
|           (parameters   (version      new-fq-version-name)
|                         (dir          (extended existing-directory))
|                         (nested?      (extended y-or-n)))
|           (output     plain-text)
|         (run-tla "init-tree"
|                    (if dir (list "-D" dir))
|                    (if nested? (list "--nested"))
|                    version))

I think there might be concepts apparent in this code that don't
belong into the low level interface: new-fq-version-name, for instance
(if I understand correctly) will cause the user to be prompted for a
*new* version name. I would consider the knowledge about existing
versions not something to be located at the low level interface (but
easily extracted using it). Also, prompting, as indicated by y-or-n
doesn't belong there.

But, on the other hand, this separation turns up the issue of
duplication: Since you'd want access most TLA commands also through
the low-level interface, you'd define most commands in two places,
which is unfortunate.

> 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:
Looks and sounds interesting, this segusoland stuff.

>       in a way that everybody's existing code "just works" with
>       the new input method?
I hope you didn't mean for me now to come up with an implementation
plan (cough), but I'll try to keep that in the back of my mind.


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

Say NO to Software Patents! --

reply via email to

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