headers
William Tanksley, Jr | 23 Apr 2011 19:50
Picon

[stack] Canonical LLVM starter language is concatenative...

 

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

__._,_.___
Recent Activity:
    .

    __,_._,___
    Permalink | Reply |
    headers
    eas lab | 24 Apr 2011 15:31
    Picon

    Re: [stack] Canonical LLVM starter language is concatenative...

     

    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 <at> gmail.com> 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
    >

    __._,_.___
    Recent Activity:
      .

      __,_._,___
      Permalink | Reply |
      headers
      William Tanksley, Jr | 25 Apr 2011 05:17
      Picon

      Re: [stack] Canonical LLVM starter language is concatenative...

       

      eas lab <lab.eas <at> gmail.com> 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

      __._,_.___
      Recent Activity:
        .

        __,_._,___
        Permalink | Reply |
        headers
        chris glur | 25 Apr 2011 16:24
        Picon

        Re: [stack] Canonical LLVM starter language is concatenative...

         

        > 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.

        __._,_.___
        Recent Activity:
          .

          __,_._,___
          Permalink | Reply |

          Gmane