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

[Tom Lord]

    > From: "Tobias C. Rittweiler" <address@hidden>

    > On Monday, June 28, 2004 at 9:55:09 PM, 
    >     Tom Lord <address@hidden> wrote:

    > >   At one end of a spectrum, it would be easy to write primitive furth
    > >   commands to read one line of input, create a string value from that,
    > >   and push it on the tuple stack.   It would be easy to add commands
    > >   to compare that string to a regular expression, perhaps edit it, 
    > >   and so forth.    Combined with very simple flow of control and a
    > >   use-by-convention of $env as a "hold register", Furth would become
    > >   a virtual machine for the programming language of "/bin/sed".

    > Why exactly do you consider furth more suitable for such mini
    > languages than the macro-system of scheme (or CL)?

Scheme macros are great for creating little langauges like that,
but Scheme implementations are lousy at producing tiny and fast
executables for such little languages.   No practical implementation
that I'm aware of can come close to competing with a /bin/sed or
similar language written directly in a lower-level language.   

Meanwhile, such tiny languages are often about as easy to implement in
a lower-level environment as they are to implement in Scheme, provided
that the lower-level environment has some decent libraries.  If a tiny
executable is your goal, there is no apparent advantage to imposing a
requirement that there be a sufficiently complicated and sophisticated
optimizing Scheme compiler to compile your Scheme implementation into
a tiny executable.   It's easier and clearer and often more
maintainable to just do it by hand.

/bin/sed is an easy example for demonstrating the trade-offs: it's
very clearly at an extreme end of the spectrum that shows how
a fancy Scheme compiler is _not_ the right answer for everything.

I believe that there's a spectrum there, though.  Between /bin/sed and
Scheme itself are a lot of intermediate points.  It isn't always clear
which ones are best coded by "dumbing down" (specializing) a
high-level language like Scheme and which are best coded by building
up a lower-level environment.   Perhaps some tools are best
implemented using a mixture of the two strategies.

Therefore, it seems to me that a good programming environment is one
that gives you access to the full range of options, from "raw C" to "C
with a sophisticated library" to "Scheme".   A good environment should
let you mix and match these approaches and switch between them without
too much pain.   A good environment should encourage parsimony so
that, for example, a new "primitive command" you add for /bin/sed also
doubles as a new "primitive procedure" in Scheme.

-t