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

[Aaron Bentley]

Tom Lord wrote:
>     > From: Aaron Bentley <address@hidden>

>     > 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.
>
> I really don't see where the superstition arises that the boundary
> between xl0 and xl0+expressions has much practical significance at all
> (for implementors

Sorry I was unclear.  My argument wasn't "xl1 is too hard to implement". 
 I meant to say "there's no point implementing xl1 if all you're going 
to use is the xl0 subset".

> for users it's obviously a huge boost in expressiveness).

I'm saying that increase in expressiveness has costs in terms of 
iteroperability, user comprehension, ease of use, and that I don't 
believe those costs are appropriate for the domain of Arch configuration.

I use procmail.  I'd be crushed under a mountain of kipple if I didn't. 
 The other day, I was editing my rules files, and I made an error.  The 
result was that it created a new folder called "From:", and started 
sticking most of my mail in there.

Procmail's expressive, but it has downsides, too.  It's got a higher 
barrier to entry than the Outlook rules wizard.  You've got to 
understand regexes.  You've got to understand procmail syntax.  You need 
access to a mail server.  It doesn't have a lot of trigger guards.

For my purposes, Procmail is overkill.  But even the Outlook rules 
wizard is more than I really need.

See, the mountain of kipple is spam.  I deal with it by having SpamProbe 
scan messages and categorize them.  I dump uncaught spam into my 
"makespam" folder, and a cron job uses that folder to update SpamProbe's 
database.

All of that's nifty, but it's excessive.  Mozilla Thunderbird has spam 
scanning built in, and it uses the same detection approach.  But all you 
have to do is point and click.  No wizards, no regexes.  Simple and easy.

Not nearly as powerful, but the gains are worth the lost functionality. 
   Anyone can use that, not just techies like me.

That's just an analogy, of course: I hold that, in general, more 
powerful tools are harder to use, and introduce more possibilities for 
confusion and error.  Sometimes powerful tools are warranted-- 
especially when needs are diverse.  But when common use cases are 
prevalent, it makes sense to simplify functionality for those cases.

>     > Here's my argument: I don't want more than xl0, because beyond that, 
>     > configuration data becomes opaque to programs.  
>
> Why do you believe that?!?  
...
> So, what kind of program is it that will have an xl0
> parser but can't, for some reason, have an xl0+expressions
> interpreter?

What I mean is that when all you have is assignment, all the rules for 
how values are used can be known in advance, and programmed into the 
programs that use the data.  Programs can use this knowlege to display 
it in ways that make sense to users, and manipulate it in ways that are 
based on a deep understanding of the way the data is used.

When expressions get involved, you can no longer display the data based 
on how it's used.  Sure, you can evaluate the expression.  And you may 
be able to get a parse tree, and allow people to query and manipulate 
the expression's structure like a good IDE can.

> Why can't the GUI say:
>
>     my-default-archive
>
>       value: address@hidden
>
>       definition: (archive-of my-default-fq-version)
>
> and allow users to edit the definition but not the value?

It certainly can, but I don't believe that's appropriate for this 
domain.  I can only think of two or three ways that users would generate 
my-default-archive.  It would be better to have a UI tailored to those 
options, but I question the value of computing it in the first place. 
Is it going to make anyone's life any easier?

>   Of course, 
> that would be the generic display.   Read the discussion between 
> Jeremy Shaw and I for some hints about how some config files could
> wind up with customized interfaces that implement domain-specific
> rules for editting definitions in high-level ways.

I don't see anything in that discussion that could come close to the 
simplicity of the alternative I proposed.  Some of it requires custom 
data types, so I don't think xl0+expressions will cut it.

In order for programs to intelligently handle previously-unknown Arch 
configuration data, you'll need types like those implemented by PyArch: 
Archive, Patchlog, WorkingTree, etc.  Then you can have an Archive-list 
dropdown or a Revision browser.

Aaron

--
Aaron Bentley
Director of Technology
Panometrics, Inc.