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

[Colin Walters]

On Tue, 2004-07-20 at 12:04 -0700, Tom Lord wrote:

> Oops... you are mistaken.  You contradict yourself.

I don't think so.

> Answer me this.... Why is _this_ an example of a language in use:
> 
> 
>        set-in-version: (upstream "address@hidden/tla--devo--1.3")
> 
> but _this_ is not:
> 
>        X-Upstream: address@hidden/tla--devo--1.3

Because as I said later in the thread, the latter already exists.

> It seems to me that you really wanted to say
> 
>    We already have a langauge for this kind of thing.  The language is
>    (roughly):
> 
>       program := X-<name>: <value>
> 
>         <name> := <alnum and some punctuation>+
> 
>         <value> := <RFC822 header field contents>
> 
> For very simple settings, such as setting "upstream" to a
> fully-qualified version name, that traditional language is, indeed,
> quite ample.

Sure.

> What if, though, the value is supposed to be a list?   Or nested
> lists? or numbers?  or a string that can contain arbitrary characters?
> or a list of such strings?

You know, it's not like programmers have never faced the problem of data
serialization and interchange before.  There are a number of existing
solutions to this problem.  One of them that is very widely deployed and
understood is XML.

But we could take an even simpler route and stay with the existing patch
logs and do what email does - have the value format simply depend on the
key.

> What if the value of the variable isn't a constant but should be
> computed in some way?

Evil.  The value of patch logs shouldn't change depending on external
variables.  I can't think of any reason to do that.  A client can
perform whatever computation they want on the data.

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