Re: ITLA

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

Tom Lord <lord@emf.net> 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:
>
>         http://segusoland.sourceforge.net
>
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.


[0] http://article.gmane.org/gmane.comp.version-control.arch.user/18334

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

Say NO to Software Patents! -- http://petition.eurolinux.org/



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