Re: [Gnu-arch-users] empty commits, wrappers, and version control frawemork

[chth]

> David Allouche: 
> >     Currently, a lot of convenience features need to be built into
> >     tla because there is no way to implement them with decent
> >     perfomance on top of the stateless CLI. For example, "tla
> >     replay" is getting a heck lot of options and understanding how
> >     they relate and interact is getting tricky.
> >
> >     The wrappers/front-ends are limited because they can only use
> >     the CLI interface, and that makes them very wasteful. Something
> >     closer to what they need, and not quite painful as implementing
> >     libtla.so, would be "shell bindings to libtla". That might be
> >     implemented as a butt-simple REPL, usable as a coprocess, which
> >     gives access to the libtla features, and would allow reusing pfs
> >     connections and other expensive resources. It seems that
> >     Christion Thäther has something like that in mind.
> >
> >     It's getting time to start saying "no" to new convenience
> >     features into tla and push people towards aba, raw (the python
> >     shell from Rob Weir, soon to be released) and mala (the macro
> >     language from Christian Thäther, still "almost vapor" according
> >     to the author).
> 
> This may be where we part ways.
> 
> I see tla itself as the one place where we have a guarantee of some
> sort of consistancy of interface across heterogenous machines. Aba may
> be on one machine, raw on another and mala on yet another. However, no
> matter where I go, tla will be there. 


Mala will be there if tla is there.

Ok it's prolly time to explain it a bit:

MaLa is a very small macro language linked to an application (tla in
this case) which processes words sequentially. In it's most basic
invocation it's just a easy to maintain getopt alternative, optargs are
passed to the MaLa engine and are evaluated. Evaluation is based on
buildin or user supplied parsers.
This Parsers can do things like (layman examples):
 * definition of new macros 
    --DEF -V --version
 * expansion of macros
    -V becomes --version
 * side-effects 
   --version will call safe_printfmt("blah %d.%d\n",version,revision)

There will be alot of predefined parser modules which users can choose
from such as: accessing variables, imperative control structures,
arithmetic, interfacing C functions and so on.

Further there will be modules for reading config-files and an
interactive toplevel which is just the mala engine with some syntactic
convenience and readline stuff enhanced.

I hope thats enough to get an idea about it...

How about enhancing tla with it (some things which could be done with
MaLa, some of them should prolly not be done):
 - tla exposes its lowlevel interface to MaLa
   (initiate pfs connections, delta operations, etc...)
 - MaLa glues the lowlevel stuff to the stable CLI interface which
   is required by other applications and scripts (part of the existing  
 CLI)
 - the existing rest (compatibility cruft) CLI will be implemented in   
MaLa (how about deprecation warnings?)
 - Users can define their own convenience options in ~/.tlarc or similar
 - tla gets a consistent interactive mode with no problems of volatile  
   environments such as shells.
 - other applications can upload batch jobs and macros into tla
   thus it will be possible that a frontend forks tla only once
   and uses MaLa as ipc interface, which leads to a stateful instance
   of tla.
 - tree config files can be parsed by MaLa, with more options prolly
 - any other config from ~/.arch-params/ can be evaluated by MaLa too


        Cheers
                Christian Thäter