# Canonical LLVM starter language is concatenative...

## William Tanksley, Jr — 2011-04-23 17:50:16

    http://llvm.org/releases/1.1/docs/Stacker.html

    I just found this... As of 1.1, LLVM includes as one of its primary

    examples a "Forth-like" language that might possibly serve as the

    foundation for a more complete concatenative language. It's very

    Forthlike, I'd say.

    Just in case anyone wants to start a new project :-).

    Personally, I'm a little busy learning the J language, which isn't

    concatentive but is from a remarkably different genre of languages

    than the conventional ones. I'm starting this now because I just found

    that JSoftware released it completely as free software (licensed under

    GPL 3), so at last I can learn a complete APL and know that I'll be

    able to use it effectively in my job if I want. (As a side note,

    someone also recently released an open source reimplementation of the

    related "K" language, named "Kona"; I'd start with that, but it's

    currently much less complete.)

    -Wm

## eas lab — 2011-04-24 13:31:03

    Good advice that I once got from a lawyer was "don't vague out".

    I.e. don't talk in 'hints'. Give the reader/listener something concrete.

    Add value. BTW if N readers all add value independantly, that's like

    a compositional N-stage data-transformation.

    Can your new find/s, compositionally [i.e. serially data-transforming like]:

     find all the files in dir-tree:T |

     which are less than D days old |

     and which have fileName *Name* |

     and which have a line which _starts_ with "Subject:" |

     and where _that_ line has "dog" and has "cat"

     OR where _the Subject: line_ has "fish" AND "cow".

     On 4/23/11, William Tanksley, Jr <wtanksleyjr@...> wrote:

    > http://llvm.org/releases/1.1/docs/Stacker.html

    >

    > I just found this... As of 1.1, LLVM includes as one of its primary

    > examples a "Forth-like" language that might possibly serve as the

    > foundation for a more complete concatenative language. It's very

    > Forthlike, I'd say.

    >

    > Just in case anyone wants to start a new project :-).

    >

    > Personally, I'm a little busy learning the J language, which isn't

    > concatentive but is from a remarkably different genre of languages

    > than the conventional ones. I'm starting this now because I just found

    > that JSoftware released it completely as free software (licensed under

    > GPL 3), so at last I can learn a complete APL and know that I'll be

    > able to use it effectively in my job if I want. (As a side note,

    > someone also recently released an open source reimplementation of the

    > related "K" language, named "Kona"; I'd start with that, but it's

    > currently much less complete.)

    >

    > -Wm

    >

## William Tanksley, Jr — 2011-04-25 03:17:20

    eas lab <lab.eas@...> wrote:

     > Good advice that I once got from a lawyer was "don't vague out".

    > I.e. don't talk in 'hints'. Give the reader/listener something concrete.

    > Add value. BTW if N readers all add value independantly, that's like

    > a compositional N-stage data-transformation.

     What on earth are you talking about?

     > Can your new find/s, compositionally [i.e. serially data-transforming like]:

    >  find all the files in dir-tree:T |

    >  which are less than D days old |

    >  and which have fileName *Name* |

    >  and which have a line which _starts_ with "Subject:" |

    >  and where _that_ line has "dog" and has "cat"

    >  OR where _the Subject: line_ has "fish" AND "cow".

     One of the "finds" is a demo language, so in order to do that stuff

    you'd have to add support for that to the language's library -- not

    worth your time, if that's the only programming task you have to do

    (which it clearly is). The other two (Kona and J) can definitely do

    all that, trivially; except for the minor point that they don't work

    serially, but rather in parallel.

    I haven't learned either one (and BTW, I'm not recommending them, but

    rather pointing them out), so I can't help there. If you want to know

    more, go to comp.lang.apl and ask (or go to one of their mailing

    lists).

    -Wm

## chris glur — 2011-04-25 14:24:30

    > One of the "finds" is a demo language, so in order to do that stuff

    > you'd have to add support for that to the language's library -- not

    > worth your time, if that's the only programming task you have to do

    > (which it clearly is). The other two (Kona and J) can definitely do

    > all that, trivially; except for the minor point that they don't work

    > serially, but rather in parallel.

     That's OK, if it examines the further attributes of the file, once

    it's found that the 1st one is satisfied. But the *conceptually* serial

    is AFAIK fundamewntal to compositional - or ?

    Depth-first or breadth-first search could both probably do it.

    The power [ie. economy of human effort] comes from the ability to

    'string/pipe proven functions together'. And the clean incremental

    development possiblity, by the fact that while developing satge N-1,

    you don't need to worry/know how the previous N stages work.

    And that is essentially serially CONCEPTUALLY.

    Oh, and the next stage of this task, is to:

    print out the <Subject: field> and the <location field> of the lines

    that 'match'.

    This is just a scheme that I dreamed up to:

    be able to locate my paper docos which are dispersed over several locations,

    filing cabinets, ...etc.

    What made me so enthusiatic was the realisation that 'physical location'

    maps PERFECTLY to the [*nix] file directory tree.

    So if I move docoN from /roomR/shelfS/concertinaFile/pocketP to

    /roomR2/FilingCabinet3/Drawer2/............

    I just need to move the sub-tree. Which is one operation.

    And with mc [my constant tool], I can *SEE* it move to its new location.

    -----------------

    That was  wrong, but leaving the 'true log' adds value. Literate programming.

    A doco is a node of the tree; which is less spectacular to move.

    It's moving a parent node [sub tree] that impresses me.

    Eg. moving the whole <S pocket> of the concertina file.

    Which is an unlikely/senseless move.

    Hey, I'm designing this while I'm writing - NOW.

    Thanks for the opportunity to help solve this BIG problem.

    How would you do it?

    BTW *nix officionados write such one-liners all the time.

    == Chris Glur.