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

[Aaron Bentley]

James Blackwell wrote:

> That's a lot of stuff to tack onto a revision control system, right?
> Well, this is how we win the game. We make it so easy for a project to
> handle every aspect of revision control (there's a lot more than just
> merging cleanly), that o use anything else would be idioic. Already,
> some of our compeitors, like darcs and bitkeeper, already have some of
> these things in place. 

I disagree here.  Choice is important.  When you glom everything up 
together, you reduce choice, and everyone gets stuck with one solution 
that fits no one perfectly.  I think that changes that would enhance 
Arch at the cost of hobbling other programs are not to be made lightly. 
 Otherwise, feel free to turn Arch into a PQM.

> About the worst that you'll bump into will
> look something like (but not exactly like) this: 
>
>     (define mirror-locations ( '("http://siteone.com";
>                                  "http://sitetwo.com";
>                                  "http://sitethree.com";)))

If that's the case, Tom should stop posting code like this:
tom>                 (define my-default-archive
tom>                   (archive-of my-default-fq-vesion))

If Tom promises we'll never see code like that example, then we can all 
go home early.  But that would raise the question: why go further than xl0?

See, xl0 looks like a perfect balance to me, in terms of its structure. 
 I agree that it's better to have one system for managing configuration 
data, and I can't imagine having difficulty writing a parser for xl0.

> Now, some of you may still be saying "But I don't
> want to do even that much". That's absolutely fine. There's still the
> front-end interface ( the hypothetical "tla add-mirror" command) for the
> nondevelopers. 

Here's my argument: I don't want more than xl0, because beyond that, 
configuration data becomes opaque to programs.  To continue with Tom's 
example, if my-default-archive is defined in terms of 
my-default-fq-version, I must execute the configuration statement in 
order to determine the value.

Let's assume that my default-fq-version is defined as 
"address@hidden/tlacontib--aba--1.3"

What should a GUI display for the value of my-default-archive?

One obvious answer is "address@hidden", but that 
would be false.  Since it's a computed value, it will be affected if I 
change (or delete) my default-fq-version.

Okay, so we can display it like this:"(computed) 
address@hidden".  Now we're telling the truth, but 
it's not the whole truth.  We don't really know where the value came 
from, and what could affect it.  Now, what happens when we want to 
change this value to "(computed) address@hidden"?

1. We could prohibit changing computed values.  The behavour would be 
correct, but users would curse us.
2. We could change the calculation: (define 
my-default-archive(archive-of my-default-fq-version)+1)  (Okay, that's 
not real xl, but it gets the point across.) While it looks pretty dumb 
in this case, I believe there are cases where this makes sense.
3. We could change the value of my-default-fq-version.  This might be 
the right approach, or it could be a nightmare.  Depends on what 
address@hidden contains.  And what if 
my-default-fq-version is, itself, a computed value?
4. We could change the definition to (define my-default-archive 
"address@hidden")

If faced with this situation, I'd probably prompt the user: "Do you wish 
to update your default version?" and pick option 3 or 4 accordingly.

But in the ideal, I think the GUI should look like this:
+-----------------------------------------------------------+
| Default version                                           |
| address@hidden/tlacontib--aba--1.3] |
|                                                           |
| [X] Override default archive                              |
| address@hidden                     |
+-----------------------------------------------------------+

What have I done here?  I've blessed the common cases, and sacrificed 
fringe functionality for the sake of ease of use.  There are no computed 
values; either my-default-archive is assigned to a string, or it's not 
defined.  If it's not defined, there's a rule that conforming Arch 
implementations must substitute the archive of the default version. 
That rule may be implemented in whatever languages the Arch 
implementation is written in, including POSIX shell, C, Furth, xl1, 
Perl, Python, Haskell...

I believe this is an appropriate approch for most kinds of configuration 
data.  How many useful ways can there be to assign a value to 
"upstream"?  Isn't it better to give them first-class support than to 
throw a scripting language at the problem?

For especially strange functionality, people are going to want to use 
their own languages anyhow.

When you treat code as data, you make data opaque to other programs. 
That reduces choice, and in some cases, forces people to execute code in 
their heads in order to evaluate values.  I think that for most cases, 
the cost is not worth it.

And, if you think this just applies to GUIS, ask yourself how you'd deal 
with it in "tla my-default-archive".  Surely "tla my-default-archive 
$(tla my-default-archive)" should be a no-op.

> In
> order to help addres this exact issue, I have created
> address@hidden/tla--devo--1.3, and into that branch I have
> started merging changesets from a variety of sources.

I appreciate you taking this on, and I'll do my best to support you.  I 
have faith in your ability to put out a 1.2.1 release that that's an 
icremental, but useful improvement on 1.2.

But my feeling is that Tom's irreplaceable.  Even if Tom's clone were to 
wander in from the street and offer to take over, I wouldn't hand him 
stuff like the backbuilder, because only Tom knows the archive format 
inside out.  Twice now, I've caught bugs in the backbuilder that would 
not be caught by testing normal archives, because

- no one* tags into a version after committing (but it's valid).
- only larch can do an import after base-0 (but it's valid).

*except David Allouche, and he started long after I wrote the code.

Both of these came as nagging doubts long after I'd written the code in 
question.  There's no way I'd have seen it if someone submitted it to 
me, and even Tom didn't see the deficiency in my proposed interface.

On the other hand, maybe it's a question of which invasive features are 
most important.  I can keep the backbuilder from going stale until Tom's 
ready to look at it.

Aaron