Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to")

[Tom Lord]

    > From: William Dode <address@hidden>

    > Tom Lord <address@hidden> writes:

    > >        William Dode:

    > >        Could you explain briefly why the others langages doesn't fit ?
    > >        specialy lua wich is an embeddable langage. Maybe the answer
    > >        will be in 3) ?

    > > Lua is awefully close and is an inspriation for Furth. 
(http://www.lua.org/)

    > > Shriram Krishnamurthi in a talk called "The Swine Before Perl" laid
    > > out a list of 5 "gems" -- great ideas in language design, found in
    > > Scheme, commendable to designers of new little languages.

    > My question was more to know why Arch need a so specific embedded
    > langage. But i should wait for your third roadmap !

No, it won't delve into that so I'll give a quick answer.

I want a very tiny and tractable interpreter which rules most of the
current ones right out.  A core furth interpreter seems to add about,
oh, maybe 32K over and above libhackerlab -- yet it has all the "gems"
(continuations, closures, etc.)  That's one reason to want furth,
specifically.

Another reason is that furth _isn't_ "so specific embedded language".
It's a VM on which tiny languages for many different paradigms can be 
implemented nicely.

Here's an example of how the issue of the need for a language creeps
into arch.  Consider our configuration files.   We have:

        ~/.arch-params/hooks

        ~/.arch-params/signing/*

        $proj/{arch}/=tagging-method

        $library/=greedy

        $library/=sparse


_These_ all have "ad hoc" syntaxes and semantics, and all different.

Are we going to just keep adding such things, indefinately?  Or 
start making a systematic way to manage them?

I want to add a whole bunch of new configs, some of which can be 
pretty complicated.   It'd be a good idea to get systematic about this
lest we demostrate Greenspun's 10th law....

-t




eenspun's Tenth Rule of Programming: "Any sufficiently complicated C
                           or Fortran program contains an ad-hoc,
                           informally-specified bug-ridden slow
                           implementation of half of Common Lisp."