Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to")

[tomas]

On Wed, Jun 30, 2004 at 04:49:19PM -0700, Pierce T.Wetter III wrote:

[...]

>   Let's say I want to add a submit rule.
> 
>  "Builds correctly" or "if make"
> 
>  That seems like a logical use for a shell script, because all I really 
> want
> to do is run make and get the result.
> 
>   So I suppose that there are two ways to go here. In one case, the 
> config file for
> submit rules could be a complete language like Python (I'm using Python 
> since I don't know furth):

[Python example]

> So tla would look for "Rules.py", and it would look for definitions of 
> specific Python routines (like submit) which it would call in certain 
> cases.
> 
> Now this would force tla users to learn Python, which besides causing a 
> flamefest, would require only using tla where python is available. On 
> the other hand, I see several benefits:
> 
>  1. Since Rules.py is only read once per tla command, and probably only 
> compiled once in a great while when Rules.py changes, this would make 
> tla pretty fast at reading and processing the rules.
> 
>  2. Personally, I hate shell scripting, and much prefer doing things in 
> Perl or Python then I do
> .sh files. Plus as Tom points out, all config files are a language of 
> some sort, and I'd rather not learn yet another one.
> 
>  3. tla could set certain variables and read others, making it easy to 
> pass information back and forth between the rule code and the main 
> code.
> 
>  Or, there's this alternative. Tla will execute any file named 
> .rules.submit. So this file could
>  look like this:
> 
> #!/usr/bin/python

[...]

> The advantages of this are:
> 
>    1. User can use anything: Perl, Python, Shell scripts, c programs.
>    2. Tla has to launch a whole process to ask one question, which while
>       easy for a global operation like submit, its bad for any per file
>       thing.

And since many people would contribute scripts the user would end
up depending on Python 2.1 *and* Python 2.3 *and* Perl 5.6 *and*
(oh, well).

> The third alternative would be of course:
> 
>    arch implements some ad-hoc configuration language, which has 
> whatever
> features the arch users felt we're needed, and which gradually gets 
> hacked
> on, but is actually harder to learn then Perl/Python etc.
> 
> So that's where you're coming from, except you came with with a fourth
> alternative:
> 
>    Given Tom's experience with creating a language, Tom creates his own
> VM, with the theory being that people can write code in multiple 
> languages
> which compile down to this code. Tom will probably write a scheme 
> compiler
> for instance. (See Emacs/Lisp/Richard Stallman)
> 
>  So I think that's where you're coming from. My feedback as a user is 
> that:
> 
>   1. I don't want to learn a new language.
>   2. I don't want to learn a new config file format either.
> 
>  But of the two, I would rather choose #2 then #1.

I think there won't be any difference between #1 an #2.
At least not if you squint a bit ;-)

[...]

>  So I don't disagree entirely with your decision to integrate a 
> language into tla,
> I disagree with your decision to invent a new one, or even a new VM. It 
> would be much
> better if you integrated a language that there was an O'Reilly book 
> available for, or

OK, so let's write one ;-)

> >You seem to think I'm going to stop everything and immediately
> >completely rewrite arch in some strange language that I made
> >up on the spot.   That's not the plan.   Reacting against that
> >non-plan is really off topic.
> 
>   No, I think that you like working on languages so you're thinking of
> creating one for use in arch rule files. I don't disagree with having
> a language in rule files, I disagree with having a language you made
> up in the rule files...
> 
>  So while many people's first reaction to all this was, "why a 
> language?",
> my reaction is "why YOUR language?".

It'll be the right one, I'm sure.

Regards
-- tomás