# The Killer Application for Concatenative Languages....

## John Carter — 2006-08-04 04:45:12

    I have long had a gut feel that the ability to algebraic

    refactoring/rewriting/simplification of programs is a killer feature of

    Joy / concatenative languages.

    I just noted an practical application for this...

    Out here in the embedded computing world there is a vast body of Legacy

    assembler applications which cannot be ported to new CPU's as the old

    parts go obselete.

    So how about this for a solution....

    Write in a concatenative language of your choice fragments that exactly

    duplicate each machine instruction.

    "assemble" the assembler source into the concatenative language.

    Algebraically simplify as much as possible. (Quite like to something

    even simpler than the original source!)

    Compile the concatenative language to new CPU.

    Done.

    John Carter                             Phone : (64)(3) 358 6639

    Tait Electronics                        Fax   : (64)(3) 359 4632

    PO Box 1645 Christchurch                Email : john.carter@...

    New Zealand

    Carter's Clarification of Murphy's Law.

    "Things only ever go right so that they may go more spectacularly wrong later."

    From this principle, all of life and physics may be deduced.

## Christopher Diggins — 2006-08-04 05:03:13

    This in an excellent idea! I really hope this will be possible some time

    soon with Cat. Have you taken a look at the slides at

    http://www.cdiggins.com/cat/cat.pdf ? I think it would be ideally suited for

    this, though the language isn't quite ready.

     On 8/3/06, John Carter <john.carter@...> wrote:

    >

    >    I have long had a gut feel that the ability to algebraic

    > refactoring/rewriting/simplification of programs is a killer feature of

    > Joy / concatenative languages.

    >

    > I just noted an practical application for this...

    >

    > Out here in the embedded computing world there is a vast body of Legacy

    > assembler applications which cannot be ported to new CPU's as the old

    > parts go obselete.

    >

    > So how about this for a solution....

    >

    > Write in a concatenative language of your choice fragments that exactly

    > duplicate each machine instruction.

    >

    > "assemble" the assembler source into the concatenative language.

    >

    > Algebraically simplify as much as possible. (Quite like to something

    > even simpler than the original source!)

    >

    > Compile the concatenative language to new CPU.

    >

    > Done.

    >

    > John Carter Phone : (64)(3) 358 6639

    > Tait Electronics Fax : (64)(3) 359 4632

    > PO Box 1645 Christchurch Email : john.carter@...<john.carter%40tait.co.nz>

    > New Zealand

    >

    > Carter's Clarification of Murphy's Law.

    >

    > "Things only ever go right so that they may go more spectacularly wrong

    > later."

    >

    > From this principle, all of life and physics may be deduced.

    >

    >

    [Non-text portions of this message have been removed]

## Chris Double — 2006-08-04 05:59:39

    >  Write in a concatenative language of your choice fragments that exactly

    >  duplicate each machine instruction.

     I was planning to do something similar with my space invaders emulator

    written in Factor.

    The instruction set in the emulator is actually defined declaratively:

    INSTRUCTION: RET  NZ      ; opcode C0 cycles 05

    INSTRUCTION: POP  BC      ; opcode C1 cycles 10

    INSTRUCTION: JP   NZ,nn   ; opcode C2 cycles 10

    INSTRUCTION: JP   nn      ; opcode C3 cycles 10

    INSTRUCTION: CALL NZ,nn   ; opcode C4 cycles 11

    At parse time this is used to actually generate the Factor source for

    the instructions buy using  a pattern matcher for instruction

    families:

    { "JP-NN"   [ [ cpu-pc ] keep [ read-word ] keep set-cpu-pc ]  }

    { "JP-(RR)"      [ [ $1 ] keep set-cpu-pc ] }

    { "CALL-NN"         [ (emulate-CALL) ] }

    { "LD-RR,NN"     [ [ next-word ] keep $2 ] }

    { "LD-RR,RR"     [ [ $3 ] keep $2 ] }

    The $1,$2,$3, etc are replaced by the code to set/get cpu registers

    depending on what was used in the INSTRUCTION: statement.

    The end result is compiled factor code to emulate all the instructions.

    It would be an interesting project to jit compile or ahead of time

    compile the 8080 instructions to Factor code and run that.

    The original plan was not not only generate the emulator instruction

    words, but also to generate disassembler and assembler instructions to

    provide an 8080 development environment in Factor. I never quite got

    around to it though - too much time actually playing Space Invaders

    once I got it running I think!

    The code for the 8080 emulator portion is here:

    http://www.bluishcoder.co.nz/repos/factor/Factor/contrib/space-invaders/cpu-8080.factor

    It can be run in the current 'darcs' version of factor by doing:

      "space-invaders" require

      USE: space-invaders

      run

    Chris.

    --

    http://www.bluishcoder.co.nz

## Martin Young — 2006-08-04 10:38:44

    The same thing occurred to me when I first started playing with Joy,

    and my own concat languages.  There are a few applications I had in mind:

    1. As a compiler target for general purpose programming languages.  I

    wondered if a concatenative language might be simple enough to ease

    the implementation of a global optimiser yet expressive enough to

    retain all the high level information which would be lost to a

    canonical p-code optimiser.

    2. As an extension of 1, a source code level optimiser whereby the

    "shape" of the original source code is retained during manipulation so

    that the optimised (or refactored if you like) version is returned to

    the original source language in a recognisable form.

    3. As an extension of 2, a general purpose aspect weaver where the

    aspects are all compiled down to a concatenative language, woven and

    returned to the original source language for examination, compilation

    and source level debugging using the normal dev tools.

    Sadly I've not had the time to pursue any of these although I'm aware

    that a company local to me had also thought about 2 and intended to

    try something similar.  Not sure how far they got.

    I've yet to be convinced that concatenative languages are good for

    general purpose programming by humans.  I know there is a sizable body

    of Forth programmers but I suspect they're the deviants, not the pack

    leaders in this context.

     --- In concatenative@yahoogroups.com, John Carter <john.carter@...> wrote:

    >

    > I have long had a gut feel that the ability to algebraic

    > refactoring/rewriting/simplification of programs is a killer feature

    > of Joy / concatenative languages.

    >

    > I just noted an practical application for this...

    >

    > Out here in the embedded computing world there is a vast body of

    > Legacy assembler applications which cannot be ported to new CPU's as

    > the old parts go obselete.

    >

    > So how about this for a solution....

    >

    > Write in a concatenative language of your choice fragments that

    > exactly duplicate each machine instruction.

    >

    > "assemble" the assembler source into the concatenative language.

    >

    > Algebraically simplify as much as possible. (Quite like to something

    > even simpler than the original source!)

    >

    > Compile the concatenative language to new CPU.

    >

    > Done.

## William Tanksley, Jr — 2006-08-04 13:50:23

    Martin Young <martin@...> wrote:

     > I've yet to be convinced that concatenative languages are good for

    > general purpose programming by humans.

     Purely anecdotal evidence is that people who get into Forth and a pure

    functional language report similar positive subjective experiences

    between the two. Forth, in spite of its extremely low-level and

    non-theoretical background, FEELS like a highly designed language. I

    know Chuck Moore is a genius :-), but I think this is more due to

    concatenativity than it is to clean language design (doubly so because

    most Forth is written using the ANS Forth dialect, which was designed

    by a committee).

    So I suspect that they ARE good for general purpose use by humans. I'm

    sure that for some uses they're inferior, of course, but again, I'm

    speaking in general. (I'm not claiming that non-concatenative

    languages are bad, or even less good; I'm not making any relative

    examinations, really.)

     > I know there is a sizable body

    > of Forth programmers but I suspect they're the deviants, not the pack

    > leaders in this context.

     Ya, I don't even know how sizable the number of Forth programmers is.

    I do believe there are more non-programmers who use Forth than there

    are programmers: engineers, technicians, scientists, etc.

    I suspect the reasons for this include the total lack of computer

    science knowledge about Forthlike languages. This suspicion of mine is

    one reason I've been happy to see the progress in the study of

    concatenative languages.

    By the way, Chuck Moore helped start and is working on a new company

    now: Intellasys (www.intellasys.net). Interesting extremely low power,

    high speed 24-core CPUs, with each core running at about 1GHz (and for

    a change, including a multiply instruction). They run something like

    machineForth, of course. I haven't managed to get the details yet on

    the language. There's definitely one new thing that's been missing in

    Forth: libraries (he calls them 'forthlets').

    -Billy