Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc.

[Colin Walters]

On Tue, 2004-07-20 at 13:57 -0700, Tom Lord wrote:

>   The reason to build-in programmability rather than work-around the
>   absense of programmability is to help programmers better cooperate.
>   If everyone has their own solution for programmability of arch
>   configurations then one person's programs won't be useful to another
>   person.  

If your goal is simply configuration programmability, then why don't you
just go and embed pika in tla?  I still don't think that's necessary,
but it's a far cry from creating a new ill-specified "configuration
language" and embedding it in patch logs and elsewhere, and requiring
all new Arch implementations to parse and execute (!) this language.

>               (define maintainers '("joe" "jane" "fred"))
> 
>                 (define upstream
>                   (if (member my-user-name maintainers)
>                       "address@hidden/proj--devo--1.3"
>                       "address@hidden/proj--public--1.3"))

What problem is this solving?  In what situation does it arise?  First,
wouldn't you have the "devo" be in a separate archive not accessible in
the same place "public" is?

>                 (define patch-queue
>                   (if (member my-user-name maintainers)
>                       "address@hidden"
>                       "address@hidden"))

I am unconvinced that people are going to be typing "tla submit" often
enough that it is necessary to create a new configuration language.  And
why in the world do you even need to have different email addresses?  It
should be based on the GPG keyid or the like.  That way there is no need
for client-side configuration that can become stale.

This kind of stuff is why I remain completely unconvinced a new language
is necessary.  You're inventing problems.

>   The examples above show some potentially interesting uses for
>   expressions in xl but may not be terribly compelling.   
>   All that they do, really, is save a little typing.

At best.

>   But the examples suggest a similar use that I, at least, find
>   more significant:  boilerplate configurations.   This comes
>   down to "support for modularity": helping programmers to divide
>   up their work and then combine the pieces.
> 
>   Suppose that I send you (or build into tla, as a default) a 
>   template like:
> 
>     (define my-id "<PUT YOUR ID HERE>")
>     (define my-default-fq-version "<YOUR-ARCHIVE/YOUR VERSION>")
> 
>   and the rest of the program expressed entirely in terms of those:
> 
>       (define my-default-archive (archive-of my-default-fq-version))
>         (define my-default-category (category-of ...))

Wouldn't that all just be built in as sane defaults?

>   I've captured a set of rules that define the most common usage
>   pattern for these variables.   You can apply that common-case usage
>   to your environment just by fixing up the definitions of `my-id'
>   and `my-default-fq-version'. 

Or just change the values of two non-xl config file variables?

>   Your also free to change the
>   definitions and use something besides the common-case rules -- but
>   if you want the common case, it's been captured in a convenient way.

But what other rules would you use?

>   What if you had to read through and follow the instructions in 
>   such comments everytime you want to do something that _should_ 
>   be very simple (like instantiate a new master archive and 
>   patch queue manager for a new project)?

This seems like one of the more pretty trivial parts of starting a new
project, actually.

signature.asc
Description: This is a digitally signed message part