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

[Tom Lord]

    > From: address@hidden (James Blackwell)

    > I *think* we can go home early. My belief was only simple assignments
    > and lists. 

No, expressions too.   However, only expressions that can be reduced
with a finite tree traversal --- no recursive definitions.

Perhaps look at it this way...  suppose that using the generic reader 
I found that I was often writing:

        '#( type => point
            x    => 13
            y    => 42 )

So, I want to extend the reader so that the shorthand:

        (point 13 42)

is a synonnym for the longer expression.

Is that a reasonable generalization of x0?   How about
abbreviating:

        '#( type => segment
            a => '#( type => point x => 1 y => y )
            b => '#( type => point x => 13 y => 42 ) )

as

        (segment (point 13) (point 42))

I think it would be incoherent for anyone to argue that such
expression-like definitions are unreasonable.

The place where opinions diverge, though, is on the topic of
variable references.   The expressions above have leaf parameters 
which are constants.   But what about something like:


        (define origin (point 0 0))

        (define north (segment origin (point 0 1)))
        (define east  (segment origin (point 1 0)))
        (define south (segment origin (point 0 -1)))
        (define west  (segment origin (point -1 0)))

Here, each of the direction vectors is defined in terms of some other
variable, introducing the concern about dependencies between values
that abentley was raising.

Internally, that's a trivial addition.  Modifying the
"reader"/evaluator to understand variable references would add nearly
no new code (10s of lines).   Sure -- one has to be careful to 
precisely define the semantics (e.g., can a variable be "forward
referenced";  what does a reference to an undefined variable produce)
-- but that doesn't increase the complexity.

That small change, plus some others I'll be describing later, making
the resulting "xl0++" a very expressive language that, as I said, 
can help with "modular" development of arch configurations.  Why in 
the world would we not provide that functionality?

    > Tom has promised that its going to remain simple. 

That's the key thing.  I didn't mean to promise you that it's:

        (define <name> <constant>)

just that it's:

        (define <name> <thing>)

where <thing> is understood to be not significantly harder to evaluate
than a constant.

-t