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

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > 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.

To implement xl0 you'll need a parser and a run-time representation
for data (including programs and names).  Your run-time representation
of data will have to come with functions for checking the type of a
value, for accessing the components of a value, and presumably for
reading and writing values.  You'll want functions for constructing
new values both to supply defaults and as a convenient way to generate
the printed form of a value (construct it then hand it to the
printer).

If you have all of those parts at hand, how much additional code do
you think it takes to write an evaluator for simple expressions like

        (define my-default-archive
          (archive-of my-default-fq-vesion))

?  I think it takes very little new code and, if none of the functions
are side-effecting, the result is as much like an application-specific
reader extension as an expression evaluator!

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; for users it's obviously a huge boost in
expressiveness).


    > 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?!?  xl0 configuration data is opaque to
programs unless those programs have an xl0 parser.  But an
xl0+expressions interpreter is not significantly more complicated than
an xl0 parser.  So, what kind of program is it that will have an xl0
parser but can't, for some reason, have an xl0+expressions
interpreter?


    > 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.

And, I claim, that is hardly any different from what you'd have to do
anyway: parse and read 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"?

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?   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.

A particularly thorough GUI might even make the variable reference
in the expression:

      definition: (archive-of my-default-fq-version)
                               ^^^^^^^^^^^^^^^^^

a hyperlink to its definition and the function name:

      definition: (archive-of my-default-fq-version)
                   ^^^^^^^^^^

a  hyperlink to its documentation.

    > When you treat code as data, you make data opaque to other
    > programs. 

That's only true for some values of "code".

-t