# A Joy VM in OCaml

## Tom Schouten — 2009-08-25 07:48:51

    Hello list,

    Something I'd like to share: a small interpreter for an (intensional)

    Joy dialect, that has helped me to clarify some conversation about

    implementation of concatenative languages.

    http://zwizwa.be/darcs/libprim/pf/joy.ml

    What I found remarkable is that the continuation of such an intensional

    VM _really is just an intensional quotation_.

    This is mostly to contrast the PF VM, an early-bound extensional Joy dialect

    with linear core memory and nonlinear code memory.  I.e. it uses linear

    lists for data, delimited continuations, and partial applications, and

    nonlinear memory for the code graph.

    I think I finally found a way to combine linearity and some form of

    reflection by using a staged approach.

    http://zwizwa.be/darcs/libprim/pf/pf.ml

    Cheers,

    Tom

## Tom Schouten — 2009-08-26 13:30:17

    ... and another one: extensional, non-linear Joy stack machine that

    works using binary tree representation of code, and a binary tree

    rotation in the interpreter, with again the continuation = a quotation.

    http://zwizwa.be/darcs/libprim/pf/seq.ml

## chris glur — 2009-09-01 05:02:29

    What is this good for ?

    The answer that I didn't get directly, but which hints led to,

    for my previous question: "what is cat-style good for";

    could have been "it facilitates successive refinement, which

    aids software productivety".

    Unix shell programming, which amazingly is several decades old,

    allows remarkable economy in effort by using the 'data view'

    [vs. procedural or OO views], by merely passing the data through

    multiple stages of simple filters.

    Successive-refinement applies  [which allows the programmer to

    confirm each step] because the data transformation can be confirmed

    at the output of each serial-filter.

    == Chris Glur.

     On 8/26/09, Tom Schouten <tom@...> wrote:

    > ... and another one: extensional, non-linear Joy stack machine that

    > works using binary tree representation of code, and a binary tree

    > rotation in the interpreter, with again the continuation = a quotation.

    >

    > http://zwizwa.be/darcs/libprim/pf/seq.ml

    >

    >

## Don Groves — 2009-09-01 06:01:45

    I have always found stack programming and Unix shell programming

    to be very similar, the stack being a LIFO pipe connecting successive

    refinements rather than the FIFO pipe used in Unix. As with the Unix

    shell, the transformations of the stack can be verified at each step of

    the process.

    --

    don

     On Aug 31, 2009, at 10:02 PM, chris glur wrote:

    > What is this good for ?

    > The answer that I didn't get directly, but which hints led to,

    > for my previous question: "what is cat-style good for";

    > could have been "it facilitates successive refinement, which

    > aids software productivety".

    >

    > Unix shell programming, which amazingly is several decades old,

    > allows remarkable economy in effort by using the 'data view'

    > [vs. procedural or OO views], by merely passing the data through

    > multiple stages of simple filters.

    >

    > Successive-refinement applies  [which allows the programmer to

    > confirm each step] because the data transformation can be confirmed

    > at the output of each serial-filter.

    >

    > == Chris Glur.

    >

    >

    > On 8/26/09, Tom Schouten <tom@...> wrote:

    >> ... and another one: extensional, non-linear Joy stack machine that

    >> works using binary tree representation of code, and a binary tree

    >> rotation in the interpreter, with again the continuation = a

    >> quotation.

    >>

    >> http://zwizwa.be/darcs/libprim/pf/seq.ml

    >>

    >>

    >

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## Tom Schouten — 2009-09-01 08:35:56

    Indeed.

    I've been pondering for a while about whether this is useful to

    actually turn into an application:  to build a unix shell that _is_

    a concatenative language.  It's a lot of work to get right though.

    However, starting with scsh this might not be so far-fetched..

     On Mon, Aug 31, 2009 at 11:01:45PM -0700, Don Groves wrote:

    >

    >

    >    I have always found stack programming and Unix shell programming

    >    to be very similar, the stack being a LIFO pipe connecting successive

    >    refinements rather than the FIFO pipe used in Unix. As with the Unix

    >    shell, the transformations of the stack can be verified at each step of

    >    the process.

    >    --

    >    don

    >

    >    On Aug 31, 2009, at 10:02 PM, chris glur wrote:

    >

    >    > What is this good for ?

    >    > The answer that I didn't get directly, but which hints led to,

    >    > for my previous question: "what is cat-style good for";

    >    > could have been "it facilitates successive refinement, which

    >    > aids software productivety".

    >    >

    >    > Unix shell programming, which amazingly is several decades old,

    >    > allows remarkable economy in effort by using the 'data view'

    >    > [vs. procedural or OO views], by merely passing the data through

    >    > multiple stages of simple filters.

    >    >

    >    > Successive-refinement applies [which allows the programmer to

    >    > confirm each step] because the data transformation can be confirmed

    >    > at the output of each serial-filter.

    >    >

    >    > == Chris Glur.

    >    >

    >    >

    >    > On 8/26/09, Tom Schouten <tom@...> wrote:

    >    >> ... and another one: extensional, non-linear Joy stack machine that

    >    >> works using binary tree representation of code, and a binary tree

    >    >> rotation in the interpreter, with again the continuation = a

    >    >> quotation.

    >    >>

    >    >> http://zwizwa.be/darcs/libprim/pf/seq.ml

    >    >>

    >    >>

    >    >

    >    >

    >    > ------------------------------------

    >    >

    >    > Yahoo! Groups Links

    >    >

    >    >

    >    >

    >

    >

## chris glur — 2009-09-01 21:22:33

    > I've been pondering for a while about whether this is useful

    > to actually turn into an application: to build a unix shell

    > that _is_ a concatenative language. It's a lot of work to get

    > right though.

    >

    > However, starting with scsh this might not be so far-fetched..

     I'd like to see a collaborative project in that direction;

    which was very transparent.

    I.e. doesn't just publish the final products hand-book, but

    rather exposes all steps of the design process.

    OTOH perhaps such "democratic committee" projects aren't feasible.

    I recently read some man/info * which gave a nice example of how

    the simple 'transformers' can be serially piped together to achieve

    a task.  I'm sorry that I didn't read this 15 years ago.

    -------

    .. continued if my web-crap posts this !

    == Chris Glur

## Tom Schouten — 2009-09-03 11:10:47

    On Wed, Sep 02, 2009 at 12:22:33AM +0300, chris glur wrote:

     >

    >

    >    > I've been pondering for a while about whether this is useful

    >    > to actually turn into an application: to build a unix shell

    >    > that _is_ a concatenative language. It's a lot of work to get

    >    > right though.

    >    >

    >    > However, starting with scsh this might not be so far-fetched..

    >    I'd like to see a collaborative project in that direction;

    >    which was very transparent.

    >    I.e. doesn't just publish the final products hand-book, but

    >    rather exposes all steps of the design process.

    >

    >    OTOH perhaps such "democratic committee" projects aren't feasible.

     I believe good results require a sufficiently annoying `itch' locally

    applied to a single implementor / designer.

    Committees are probably only useful if there are too many people with the

    same itch but different ways of scratching, or if a sufficiently

    annoying itch doesn't emerge spontaneously.

    Considering joy vs. shell programming, I do have a couple of ideas though,

    while I think it's far from trivial to do it right.

     - If you can figure out how to map programs, program arguments, and

       pipes to clearly defined Joy function and data objects, and figure

       out how to mesh the different name spaces the job seems half way done.

       The rest is the long tail of infinite refinement and bug hunting.

       I.e. the shell language could be a combination of

         - Joy combinators

         - Programs (can they be joy combinators? how to mix function

           and file system namespaces?)

         - Command lines of most sufficiently complex programs behave as

           `mini-DSLs'.  Can they be mapped to combinators, or should they

           be abstract data?  Can you brush this away into a wrapper

           by treating providing some kind of compiler/interpreter for

           each sufficiently complex external app (a good example would

           be mplayer/mencoder).

     - It might be a playing field where the original highly reflective

       intensional Joy approach is workable.  In all other practicaly

       applications of concatenative languages I see, extensional approach

       seems to be better from both modularity and efficiency viewpoints

       (i.e. where you want play with static code properties).

## eas lab — 2009-09-03 15:47:10

    .. continued fron previous post, because the mailer objected to the

    complete text.

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

    Because I'm an isolated researcher, I appreciate when others expose

    the route to their results, rather than just giving the 'show-room'

    end product.  Perhaps some see this as indiscreet exhibitionism ?

    As an example of how I'd like open-collaborative projects to be,

    I'm going to NOW try to expose how I partially achieved a nasty task

    using unix's cat-like facilities.

    TASK DESCRIPTION: find which [if any] Desktop, VT pair is currently 'open' at

    the correct directory, to process the newly arrived email, news, http ...etc.

    Think of a system from 200 years ago, where 10 to 20 sheets for 6 to 8

    categories are distributed between 4 clerks. Clerk1 may have 4 sheets for:

    vegetables, meat, clothing, meat.

    When a transaction for meat arrives, it should be directed to the clerk

    who currently has the/a 'meat' sheet.

    Since this is a computer and not paper-sheets, multiple clerks/processes

    can have the same sheet/directory open.  And muliple copies of a sheet/directory

    may be open for reading/editing its files. And always allocating new

    sheets/VirtualTerminals to the new topic as they arrive would give an explosive

    growth of redundant sheets/VTs.

    If you had 20 copies of a book, all open, mostly at different pages

    and you had to switch between books to see which, if any book was open at

    the 'meat page', this would be frustrating; compared to scanning down a list

    of (book, page-topic) pairs, to find the/a 'meat' book/page.

    So the 1st REFINED TASK DESCRIPTION is:

    find which Desktop/VT, if any, has the directory for the newly arrived item.

    Then the 2nd REFINED TASK DESCRIPTION 'became':

    generate a list of the open directories for the 10 to 20 mc-tasks,

    and generate info which relates the (D,V) pair to the  task-directory,

    so that by visually scanning the 2 lists the D/V which matches the mc-task

    can be found.

    As an example this task that I'm writing now, will be in a path/directory

    *cat* or *Cat*; and I can see that it's using desktop1, VT4; which I

    designate as D,V=1,4.

    But when I switch out of this D,V to some other jobs and new info arrives for

    the 'cat' topic, I'll have forgotten/lost D,V=1,4.  In fact possibly D,V=1,4

    will have been allocated to a different topic.

    The 2 sets of info look like this [where I just have to remember that they're

    call PT & DV] :-

    --> # PT

    mc         1477   /mnt/cdrom/Inet

    mc         1549   /mnt/cdrom

    mc         1593   /mnt/cdrom/Legal/TLC/Aug09

    mc         1824   /mnt/cdrom/Legal/TLC/Aug09

    mc         2429   /mnt/cdrom/Inet/RSS

    mc         8952   /mnt/cdrom/Legal/TLC/UKdefaultJ

    mc         9837   /mnt/cdrom/Legal/TLC

    mc        13406   /mnt/cdrom/Legal/TLC/UKdefaultJ

    mc        13529   /mnt/cdrom/Legal

    mc        13570   /mnt/cdrom/Legal/TLC/PreApr09

    mc        13925   /mnt/cdrom/AI/Catamorfic

    mc        17614   /mnt/cdrom/Legal/TLC/PreApr09/CCnewJudges

    mc        24024   /mnt/cdrom/Legal/AudtrFiduc

    --> # DV

    |-kdeinit(1186)-+-su(1196)---bash(1271)---mc(13529)---bash(13531)

    |               |-su(1199)---bash(1303)---linux.oberon.no(14102)

    |               |-su(1201)---bash(9009)---mc(13570)---bash(13572)

    |               `-su(1203)---bash(9805)---mc(9837)---bash(9839)

    |-kdeinit(1188)-+-su(1204)---bash(1335)---mc(1593)---bash(1595)---less.bin(19649)

    |               |-su(1207)---bash(1367)---mc(1824)---bash(1826)

    |               |-su(1209)---bash(1399)---linux.oberon.no(1431)

    |               `-su(1211)---bash(9481)---lynx(17276)

    |-kdeinit(1189)-+-su(1213)---bash(2075)---mc(17614)---bash(17616)

    |               |-su(1215)---bash(2107)---mc(2429)---bash(2431)

    |               |-su(1218)---bash(2139)---mc(13406)---bash(13408)

    |               |-su(1222)---bash(2171)---sob(9671)---oberon(9712)

    |               `-su(1225)---bash(8919)---mc(8952)---bash(8954)

    |-kdeinit(1192)-+-su(1221)---bash(1235)---linux.oberon.no(1441)

    |               |-su(1226)---bash(1445)---mc(1477)---bash(1479)

    |               |-su(1265)---bash(1517)---mc(1549)---bash(1551)

    |               `-su(13889)---bash(13893)---mc(13925)---bash(13927)

    This can look a bit overwhelming, but searching for the 'cat', we find

     /mnt/cdrom/AI/Catamorfic

    as the 3rd last element, and with a pid-number of: 13925.

    And the 2nd info-set has mc(13925) in the 4th/last branch of the node

    which has linux.oberon.no(1441) as it's 1st branch.

    Which means DV=1,4 as we already know !

    Similarly we see that the 2 'tree-branches' which are already allocated

    to "Aug09", are D,V=3,1 & D,V=3,2 , via pid=1593 and pid=1824 .

    Up till now, I've had to use the hack of puting the 'oberon' in the

    N-th VT of the Nth Desktop, in order to see which Desktop a set of

    branches represent. Obviously I'd like some kind of 'artificial

    intelligence' method to further proccess and just place the D/V pair

    next to the corresponding directory-path.  Like so:-

    1,2= /mnt/cdrom/Inet

    1,3= /mnt/cdrom

    1,4= /mnt/cdrom/AI/Catamorfic

     ...etc.

    But ! by using successive refinement, one can get the benefit of the

    partially working product and finish it later --  or never.

    Finally ! let's see [by exposing the details of my thought process]

    how this came from cat-style linux facilities.

    1. Let's examine the minimalist cat-code to see what it does.

    2. where is the code, to be found to examine?

    3. since it's executable, linux's "whereis" will show us.

    4. do: "whereis PT"   gives us: "PT: /usr/local/bin/PT"

    5. and show the contents of the script/executable-code

      ie. "cat /usr/local/bin/PT"  shows the single line:-

     "lsof | grep DIR | grep mc | grep "/".  | cut -b-17,67-"

    BTW, this is an example for windows-users of what linux does;

     and truthfully the file/script had several lines of comments

    which accumulated during its evolution which I'm excluding.

    If I look at the line of: code, I guess this is what it does:

     lsof : list all the open file,

     | grep DIR : but show only the lines containing "DIR"

     | grep mc : and of those show only the lines containing "mc"

     | grep "/". : and of those show only the lines containing

                     "/"<some non 'bad chars'>

         {I NOW don't remember exactly which char=set "." represents}

     | cut -b-17,67- : and show only parts of the line/s, probably cutting-out

        pieces at boundries 17th char & 67th char.

    NB. the parts which I'm not NOW sure about should be explained in the

     script's comments.  But I'm not 'sanatizing' and pretending that I know.

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

    And similarly the cat-like-code for "DV" is:

     pstree -p | cut -b25- | grep su

    which apparently does:

     print the process-tree,

     but cut-out and show only part of the lines, apparently from the 25th char

       up to the end,

     and show only lines which contain the string "su".

    Which I guess gives the 2nd data structures above.

    BTW for 'win users':

    if you've previously typed : "cat /usr/local/bin/PT"

      it only needs 3 keystrokes to get: "cat /usr/local/bin/DV"

    although I prefer ETH-oberon which works without any keyboard, if need be.

    Hopefully this example shows how comfortable it can be to develop a large

    class of tasks in a cat-style language.

    It would be valuable for me, and possibly for others, if cat-contributors

    could refine the above down to a lower level. Ie. the implementation of "grep:

    and eg. "tr" in a cat-like language would be valuable.  Frankly I don't even

    know how joy implements its control-structures, because I never found a "TOP"

    view of what joy was good for.

    The basis of the "hello world" approach is that a demonstrable model is

    made available as soon as possible; and then later one can see how the actual

    characters are printed - at a lower level ?

    The top-goal must be exposed before the implementation details.

    == Chris Glur.

## chris glur — 2009-09-03 22:52:42

    >> OTOH perhaps such "democratic committee" projects aren't feasible.

    > I believe good results require a sufficiently annoying `itch' locally

    > applied to a single implementor / designer.

     Yes, you're talking about making fish.

    I'm talking about making fishermen.

    Most of the value-added in computing comes from the soft: psychology

      and human-cognition.  OTOH the Hard: technology; is easier to talk about.

    Eg. the only justification for music is 'emotion manipulation'.

    But that's near impossible to quantify or describe.

    OTOH volumes are/can-be written about the technicalities.

    My previous laboured example, perhaps didn't prove the conclusion:--

    The brief sequence of functions described by:

     " pstree -p | cut -b25- | grep su ".

    which does:

     print the process-tree,

     but cut-out and show only the part of the lines, from the 25th char

    to end-line,

      and show only lines which contain the string "su";

    shows a very cognitive economical way of achieving the goal.

    And has the very important advantage of being achieved by successive refinement.

    Which makes for increased productivity.

    But I'm still waiting for for an explanation if/why joy is good.

    And I expect the outcome of any effort to pay-back in the future.

    Education, knowledge of universally applicable principles is more profitable

    than aquiring *A* product.

    == Chris Glur.

     On 9/3/09, eas lab <lab.eas@...> wrote:

    > .. continued fron previous post, because the mailer objected to the

    > complete text.

    > ------------

    > Because I'm an isolated researcher, I appreciate when others expose

    > the route to their results, rather than just giving the 'show-room'

    > end product.  Perhaps some see this as indiscreet exhibitionism ?

    >

    > As an example of how I'd like open-collaborative projects to be,

    > I'm going to NOW try to expose how I partially achieved a nasty task

    > using unix's cat-like facilities.

    >

    > TASK DESCRIPTION: find which [if any] Desktop, VT pair is currently 'open'

    > at

    > the correct directory, to process the newly arrived email, news, http

    > ...etc.

    >

    > Think of a system from 200 years ago, where 10 to 20 sheets for 6 to 8

    > categories are distributed between 4 clerks. Clerk1 may have 4 sheets for:

    > vegetables, meat, clothing, meat.

    > When a transaction for meat arrives, it should be directed to the clerk

    > who currently has the/a 'meat' sheet.

    >

    > Since this is a computer and not paper-sheets, multiple clerks/processes

    > can have the same sheet/directory open.  And muliple copies of a

    > sheet/directory

    > may be open for reading/editing its files. And always allocating new

    > sheets/VirtualTerminals to the new topic as they arrive would give an

    > explosive

    > growth of redundant sheets/VTs.

    >

    > If you had 20 copies of a book, all open, mostly at different pages

    > and you had to switch between books to see which, if any book was open at

    > the 'meat page', this would be frustrating; compared to scanning down a list

    > of (book, page-topic) pairs, to find the/a 'meat' book/page.

    >

    > So the 1st REFINED TASK DESCRIPTION is:

    > find which Desktop/VT, if any, has the directory for the newly arrived item.

    >

    > Then the 2nd REFINED TASK DESCRIPTION 'became':

    > generate a list of the open directories for the 10 to 20 mc-tasks,

    > and generate info which relates the (D,V) pair to the  task-directory,

    > so that by visually scanning the 2 lists the D/V which matches the mc-task

    > can be found.

    >

    > As an example this task that I'm writing now, will be in a path/directory

    > *cat* or *Cat*; and I can see that it's using desktop1, VT4; which I

    > designate as D,V=1,4.

    >

    > But when I switch out of this D,V to some other jobs and new info arrives

    > for

    > the 'cat' topic, I'll have forgotten/lost D,V=1,4.  In fact possibly D,V=1,4

    > will have been allocated to a different topic.

    >

    > The 2 sets of info look like this [where I just have to remember that

    > they're

    > call PT & DV] :-

    > --> # PT

    > mc         1477   /mnt/cdrom/Inet

    > mc         1549   /mnt/cdrom

    > mc         1593   /mnt/cdrom/Legal/TLC/Aug09

    > mc         1824   /mnt/cdrom/Legal/TLC/Aug09

    > mc         2429   /mnt/cdrom/Inet/RSS

    > mc         8952   /mnt/cdrom/Legal/TLC/UKdefaultJ

    > mc         9837   /mnt/cdrom/Legal/TLC

    > mc        13406   /mnt/cdrom/Legal/TLC/UKdefaultJ

    > mc        13529   /mnt/cdrom/Legal

    > mc        13570   /mnt/cdrom/Legal/TLC/PreApr09

    > mc        13925   /mnt/cdrom/AI/Catamorfic

    > mc        17614   /mnt/cdrom/Legal/TLC/PreApr09/CCnewJudges

    > mc        24024   /mnt/cdrom/Legal/AudtrFiduc

    >

    > --> # DV

    > |-kdeinit(1186)-+-su(1196)---bash(1271)---mc(13529)---bash(13531)

    > |               |-su(1199)---bash(1303)---linux.oberon.no(14102)

    > |               |-su(1201)---bash(9009)---mc(13570)---bash(13572)

    > |               `-su(1203)---bash(9805)---mc(9837)---bash(9839)

    > |-kdeinit(1188)-+-su(1204)---bash(1335)---mc(1593)---bash(1595)---less.bin(19649)

    > |               |-su(1207)---bash(1367)---mc(1824)---bash(1826)

    > |               |-su(1209)---bash(1399)---linux.oberon.no(1431)

    > |               `-su(1211)---bash(9481)---lynx(17276)

    > |-kdeinit(1189)-+-su(1213)---bash(2075)---mc(17614)---bash(17616)

    > |               |-su(1215)---bash(2107)---mc(2429)---bash(2431)

    > |               |-su(1218)---bash(2139)---mc(13406)---bash(13408)

    > |               |-su(1222)---bash(2171)---sob(9671)---oberon(9712)

    > |               `-su(1225)---bash(8919)---mc(8952)---bash(8954)

    > |-kdeinit(1192)-+-su(1221)---bash(1235)---linux.oberon.no(1441)

    > |               |-su(1226)---bash(1445)---mc(1477)---bash(1479)

    > |               |-su(1265)---bash(1517)---mc(1549)---bash(1551)

    > |               `-su(13889)---bash(13893)---mc(13925)---bash(13927)

    >

    >

    > This can look a bit overwhelming, but searching for the 'cat', we find

    >  /mnt/cdrom/AI/Catamorfic

    > as the 3rd last element, and with a pid-number of: 13925.

    > And the 2nd info-set has mc(13925) in the 4th/last branch of the node

    > which has linux.oberon.no(1441) as it's 1st branch.

    >

    > Which means DV=1,4 as we already know !

    > Similarly we see that the 2 'tree-branches' which are already allocated

    > to "Aug09", are D,V=3,1 & D,V=3,2 , via pid=1593 and pid=1824 .

    >

    >

    > Up till now, I've had to use the hack of puting the 'oberon' in the

    > N-th VT of the Nth Desktop, in order to see which Desktop a set of

    > branches represent. Obviously I'd like some kind of 'artificial

    > intelligence' method to further proccess and just place the D/V pair

    > next to the corresponding directory-path.  Like so:-

    > 1,2= /mnt/cdrom/Inet

    > 1,3= /mnt/cdrom

    > 1,4= /mnt/cdrom/AI/Catamorfic

    >  ...etc.

    >

    > But ! by using successive refinement, one can get the benefit of the

    > partially working product and finish it later --  or never.

    >

    > Finally ! let's see [by exposing the details of my thought process]

    > how this came from cat-style linux facilities.

    >

    > 1. Let's examine the minimalist cat-code to see what it does.

    > 2. where is the code, to be found to examine?

    > 3. since it's executable, linux's "whereis" will show us.

    > 4. do: "whereis PT"   gives us: "PT: /usr/local/bin/PT"

    > 5. and show the contents of the script/executable-code

    >   ie. "cat /usr/local/bin/PT"  shows the single line:-

    >  "lsof | grep DIR | grep mc | grep "/".  | cut -b-17,67-"

    >

    > BTW, this is an example for windows-users of what linux does;

    >  and truthfully the file/script had several lines of comments

    > which accumulated during its evolution which I'm excluding.

    >

    > If I look at the line of: code, I guess this is what it does:

    >  lsof : list all the open file,

    >  | grep DIR : but show only the lines containing "DIR"

    >  | grep mc : and of those show only the lines containing "mc"

    >  | grep "/". : and of those show only the lines containing

    >                  "/"<some non 'bad chars'>

    >      {I NOW don't remember exactly which char=set "." represents}

    >  | cut -b-17,67- : and show only parts of the line/s, probably cutting-out

    >     pieces at boundries 17th char & 67th char.

    >

    > NB. the parts which I'm not NOW sure about should be explained in the

    >  script's comments.  But I'm not 'sanatizing' and pretending that I know.

    > -------------

    > And similarly the cat-like-code for "DV" is:

    >  pstree -p | cut -b25- | grep su

    > which apparently does:

    >  print the process-tree,

    >  but cut-out and show only part of the lines, apparently from the 25th char

    >    up to the end,

    >  and show only lines which contain the string "su".

    >

    > Which I guess gives the 2nd data structures above.

    > BTW for 'win users':

    > if you've previously typed : "cat /usr/local/bin/PT"

    >   it only needs 3 keystrokes to get: "cat /usr/local/bin/DV"

    > although I prefer ETH-oberon which works without any keyboard, if need be.

    >

    > Hopefully this example shows how comfortable it can be to develop a large

    > class of tasks in a cat-style language.

    >

    > It would be valuable for me, and possibly for others, if cat-contributors

    > could refine the above down to a lower level. Ie. the implementation of

    > "grep:

    > and eg. "tr" in a cat-like language would be valuable.  Frankly I don't even

    > know how joy implements its control-structures, because I never found a

    > "TOP"

    > view of what joy was good for.

    >

    > The basis of the "hello world" approach is that a demonstrable model is

    > made available as soon as possible; and then later one can see how the

    > actual

    > characters are printed - at a lower level ?

    > The top-goal must be exposed before the implementation details.

    >

    > == Chris Glur.

    >

## Tom Schouten — 2009-09-04 12:53:44

    On Fri, Sep 04, 2009 at 01:52:42AM +0300, chris glur wrote:

     >

    >

    >    >> OTOH perhaps such "democratic committee" projects aren't feasible.

    >

    >    > I believe good results require a sufficiently annoying `itch' locally

    >    > applied to a single implementor / designer.

    >

    >    Yes, you're talking about making fish.

    >    I'm talking about making fishermen.

    >

    >    Most of the value-added in computing comes from the soft: psychology

    >    and human-cognition. OTOH the Hard: technology; is easier to talk about.

    >

    >    Eg. the only justification for music is 'emotion manipulation'.

    >    But that's near impossible to quantify or describe.

    >    OTOH volumes are/can-be written about the technicalities.

    >

     Interesting viewpoint.

     >    My previous laboured example, perhaps didn't prove the conclusion:--

    >

    >    The brief sequence of functions described by:

    >    " pstree -p | cut -b25- | grep su ".

    >    which does:

    >    print the process-tree,

    >    but cut-out and show only the part of the lines, from the 25th char

    >    to end-line,

    >    and show only lines which contain the string "su";

    >

    >    shows a very cognitive economical way of achieving the goal.

    >

    >    And has the very important advantage of being achieved by successive

    >    refinement.

    >    Which makes for increased productivity.

    >

     What you described is a `process' view on approaching a problem.

    The combinator-style that Joy/Factor/Forth/... promote is an

    example of this.  This is also called `point-free' style.

    An applicative language combines this with an `object' view, where

    you name intermediate objects in addition to processes that turn

    objects into objects.

    From a human cognition point of view it seems to me that these

    are quite basic entities that can be used to structure the

    information transfer from one brain to another.

    The formal language equivalents sure have their roots in natural

    languages, with the added advantage that these languages can

    be manipulated as objects themselves.

    (I have the feeling I'm just stating the obvious though..)

     >    But I'm still waiting for for an explanation if/why joy is good.

    >    And I expect the outcome of any effort to pay-back in the future.

    >    Education, knowledge of universally applicable principles is more

    >    profitable

    >    than aquiring *A* product.

    >

     `good' is relative to `purpose'.

    On this i can only comment from a personal angle:  I think

    concatenative languages are good for the purpose of working

    with them as data on a meta-level.

    I.e. playing with evaluation order (staging & partial

    evaluation) and allowing very simple interpreters.

    Additionally they are interesting for anything that is

    related to arithmetic (or other problems that ``naturally

    factor'' into small processes).

    As a general purpose programming language however, I feel

    they are too restrictive.  Some solutions seem to me to

    be more naturally expressed as object instead of process.

    More specifically: when random access of objects by name

    simplifies matters (i.e. tree-structured data translation).

## chris glur — 2009-09-21 16:50:00

    This forum seems to have died.

    Perhaps others had discovered what I only now discovered:

    cat-style can be as deceptive as BASIC was in the 70s.

    You think you're programming, but you're just hacking a mess.

    This forum prompted me to investigate the power of

    linux 'pipe programming',

    which is astoundingly decetive.

    It's magically easy, for small jobs, but quickly becomes unmanageable.

    == Chris Glur.

     On 9/4/09, Tom Schouten <tom@...> wrote:

    > On Fri, Sep 04, 2009 at 01:52:42AM +0300, chris glur wrote:

    >>

    >>

    >>    >> OTOH perhaps such "democratic committee" projects aren't feasible.

    >>

    >>    > I believe good results require a sufficiently annoying `itch' locally

    >>    > applied to a single implementor / designer.

    >>

    >>    Yes, you're talking about making fish.

    >>    I'm talking about making fishermen.

    >>

    >>    Most of the value-added in computing comes from the soft: psychology

    >>    and human-cognition. OTOH the Hard: technology; is easier to talk

    >> about.

    >>

    >>    Eg. the only justification for music is 'emotion manipulation'.

    >>    But that's near impossible to quantify or describe.

    >>    OTOH volumes are/can-be written about the technicalities.

    >>

    >

    > Interesting viewpoint.

    >

    >

    >>    My previous laboured example, perhaps didn't prove the conclusion:--

    >>

    >

    >

    >>    The brief sequence of functions described by:

    >>    " pstree -p | cut -b25- | grep su ".

    >>    which does:

    >>    print the process-tree,

    >>    but cut-out and show only the part of the lines, from the 25th char

    >>    to end-line,

    >>    and show only lines which contain the string "su";

    >>

    >>    shows a very cognitive economical way of achieving the goal.

    >>

    >>    And has the very important advantage of being achieved by successive

    >>    refinement.

    >>    Which makes for increased productivity.

    >>

    >

    > What you described is a `process' view on approaching a problem.

    > The combinator-style that Joy/Factor/Forth/... promote is an

    > example of this.  This is also called `point-free' style.

    >

    > An applicative language combines this with an `object' view, where

    > you name intermediate objects in addition to processes that turn

    > objects into objects.

    >

    > From a human cognition point of view it seems to me that these

    > are quite basic entities that can be used to structure the

    > information transfer from one brain to another.

    >

    > The formal language equivalents sure have their roots in natural

    > languages, with the added advantage that these languages can

    > be manipulated as objects themselves.

    >

    > (I have the feeling I'm just stating the obvious though..)

    >

    >

    >>    But I'm still waiting for for an explanation if/why joy is good.

    >>    And I expect the outcome of any effort to pay-back in the future.

    >>    Education, knowledge of universally applicable principles is more

    >>    profitable

    >>    than aquiring *A* product.

    >>

    >

    > `good' is relative to `purpose'.

    >

    > On this i can only comment from a personal angle:  I think

    > concatenative languages are good for the purpose of working

    > with them as data on a meta-level.

    > I.e. playing with evaluation order (staging & partial

    > evaluation) and allowing very simple interpreters.

    >

    > Additionally they are interesting for anything that is

    > related to arithmetic (or other problems that ``naturally

    > factor'' into small processes).

    >

    > As a general purpose programming language however, I feel

    > they are too restrictive.  Some solutions seem to me to

    > be more naturally expressed as object instead of process.

    > More specifically: when random access of objects by name

    > simplifies matters (i.e. tree-structured data translation).

    >

    >

## john@johnnowak.com — 2009-09-21 18:47:35

    On Mon, 21 Sep 2009 19:50:00 +0300, chris glur <crglur@...> wrote:

     > This forum seems to have died.

    > Perhaps others had discovered what I only now discovered:

    > cat-style can be as deceptive as BASIC was in the 70s.

    > You think you're programming, but you're just hacking a mess.

     I think it's more likely that no one is interested in responding

    to your inane questions.  If you want to know what the point of

    all this is, go read Backus, Bird, de Moor, Meijer, Fokkinga,

    Paterson, Tatsuya, Iverson, Meertens, Gibbons, et cetera.

    I'm still working on things. I've been quiet because I've been

    busy, not because I've decided that this is all a waste of time.

    - John

## chris glur — 2009-09-22 00:58:52

    This forum seems to have died.

    Perhaps others had discovered what I only now discovered:

    cat-style can be as deceptive as BASIC was in the 70s.

    You think you're programming, but you're just hacking a mess.

    This forum prompted me to investigate the power of

    linux 'pipe programming',

    which is astoundingly decetive.

    It's magically easy, for small jobs, but quickly becomes unmanageable.

    == Chris Glur.

     On 9/4/09, Tom Schouten <tom@...> wrote:

    > On Fri, Sep 04, 2009 at 01:52:42AM +0300, chris glur wrote:

    >>

    >>

    >>    >> OTOH perhaps such "democratic committee" projects aren't feasible.

    >>

    >>    > I believe good results require a sufficiently annoying `itch' locally

    >>    > applied to a single implementor / designer.

    >>

    >>    Yes, you're talking about making fish.

    >>    I'm talking about making fishermen.

    >>

    >>    Most of the value-added in computing comes from the soft: psychology

    >>    and human-cognition. OTOH the Hard: technology; is easier to talk

    >> about.

    >>

    >>    Eg. the only justification for music is 'emotion manipulation'.

    >>    But that's near impossible to quantify or describe.

    >>    OTOH volumes are/can-be written about the technicalities.

    >>

    >

    > Interesting viewpoint.

    >

    >

    >>    My previous laboured example, perhaps didn't prove the conclusion:--

    >>

    >

    >

    >>    The brief sequence of functions described by:

    >>    " pstree -p | cut -b25- | grep su ".

    >>    which does:

    >>    print the process-tree,

    >>    but cut-out and show only the part of the lines, from the 25th char

    >>    to end-line,

    >>    and show only lines which contain the string "su";

    >>

    >>    shows a very cognitive economical way of achieving the goal.

    >>

    >>    And has the very important advantage of being achieved by successive

    >>    refinement.

    >>    Which makes for increased productivity.

    >>

    >

    > What you described is a `process' view on approaching a problem.

    > The combinator-style that Joy/Factor/Forth/... promote is an

    > example of this.  This is also called `point-free' style.

    >

    > An applicative language combines this with an `object' view, where

    > you name intermediate objects in addition to processes that turn

    > objects into objects.

    >

    > From a human cognition point of view it seems to me that these

    > are quite basic entities that can be used to structure the

    > information transfer from one brain to another.

    >

    > The formal language equivalents sure have their roots in natural

    > languages, with the added advantage that these languages can

    > be manipulated as objects themselves.

    >

    > (I have the feeling I'm just stating the obvious though..)

    >

    >

    >>    But I'm still waiting for for an explanation if/why joy is good.

    >>    And I expect the outcome of any effort to pay-back in the future.

    >>    Education, knowledge of universally applicable principles is more

    >>    profitable

    >>    than aquiring *A* product.

    >>

    >

    > `good' is relative to `purpose'.

    >

    > On this i can only comment from a personal angle:  I think

    > concatenative languages are good for the purpose of working

    > with them as data on a meta-level.

    > I.e. playing with evaluation order (staging & partial

    > evaluation) and allowing very simple interpreters.

    >

    > Additionally they are interesting for anything that is

    > related to arithmetic (or other problems that ``naturally

    > factor'' into small processes).

    >

    > As a general purpose programming language however, I feel

    > they are too restrictive.  Some solutions seem to me to

    > be more naturally expressed as object instead of process.

    > More specifically: when random access of objects by name

    > simplifies matters (i.e. tree-structured data translation).

    >

    >

## Tom Schouten — 2009-09-22 11:30:05

    On Mon, Sep 21, 2009 at 01:47:35PM -0500, john@... wrote:

     >    ... go read Backus, Bird, de Moor, Meijer, Fokkinga,

    >    Paterson, Tatsuya, Iverson, Meertens, Gibbons, et cetera.

    >

     Care to complete the list?

    Backus[1]. De Moor[2], Bird[3], Meijer[4], Patterson[5], Tatsuya[6],

    Iverson[7], Meertens[8], Gibbons[9].

    [1] http://nl.wikipedia.org/wiki/John_Backus

    [2] http://www.comlab.ox.ac.uk/people/oege.demoor/

    [3] http://en.wikipedia.org/wiki/Richard_Bird_%28computer_scientist%29

    [4] http://lambda-the-ultimate.org/user/776

    [5] http://www.soi.city.ac.uk/~ross/

    [6]

    [7] http://en.wikipedia.org/wiki/Kenneth_E._Iverson

    [8] http://en.wikipedia.org/wiki/Lambert_Meertens

    [9]

## William Tanksley, Jr — 2009-09-22 15:13:55

    chris glur <crglur@...> wrote:

     > This forum seems to have died.

     No, it's just a slow period -- this happens from time to time. There

    aren't many people carrying on active research; mine is on hiatus as

    I've been working on giving a new son a start in the world.

     > Perhaps others had discovered what I only now discovered:

    > cat-style can be as deceptive as BASIC was in the 70s.

    > You think you're programming, but you're just hacking a mess.

     Unlikely. This forum is largely for research; at the present state of

    the art, the research is focused on the primitives, and nobody

    reasonable expects perfection from a primitive research effort. The

    practical people should be hanging out in the Factor and Forth (and

    possibly Postscript) groups, where they'll find pragmatic

    applications.

     > This forum prompted me to investigate the power of

    > linux 'pipe programming',

    > which is astoundingly decetive.

    > It's magically easy, for small jobs, but quickly becomes unmanageable.

     I suspect you were using an overly simple language, then. FP, FL,

    NIAL, or Q might be a better way to carry on your experiments; they're

    all based on the ideas of data pipelines, but they have strong

    facilities to group, manipulate, and redirect the data, as well as the

    control flow. NIAL is the only open-source one; Q (kx.com) is the only

    commercially successful one. FP and FL founded not only the idea of

    dataflow-centered programming, but also the entire idea of "functional

    programming", which has now become a major driver of programming

    languages (although not at all in the way the author intended).

     > == Chris Glur.

     -Wm

## John Carter — 2009-09-25 05:19:50

    On Tue, 22 Sep 2009, chris glur wrote:

     > This forum prompted me to investigate the power of

    > linux 'pipe programming',

    > which is astoundingly decetive.

    > It's magically easy, for small jobs, but quickly becomes unmanageable.

     Hmm. It's just another tool that sort of vanishes into the background

    of stuff getting done. Go digging (hard) around a major unixy project

    like gcc and you'll find pipes are quietly and unobtrusively used in

    many places.

    It's no panacea... but it it's a nifty solution to a largish pool of

    commonly occurring problems.

    I once wrote, before SQL became commonly and freely available, a

    largish datamining project heavily using pipes and filters.

    It was very similar to "NoSql", so rather than dig out my very old

    programs to show you... let me just point you at NoSql.

    http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page

    Most database projects get hung up on the need to do updates. In the

    datamining world your data is usually dumped from one or more upstream

    databases and then you just digest that static dump.

    Programming with pipes and filter database like nosql is a breeze. You

    build up your pipeline one element at a time inspecting the output.

    You can then tie it all together by dumping intermediate results in

    files and use "make" to track dependencies and update things as is

    needed.

    However, I'm not sure how we got on to this....

    I'm not sure "pipes and filters" are quite equivalent to

    "concatenative" although the similarities and differences might be

    interesting to explore.

    A way to explore it may be looking at NoSql filter elements and some

    of the nosql example pipelines.

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

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

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

    New Zealand

## John Nowak — 2010-01-05 05:03:11

    On Sep 22, 2009, at 7:30 AM, Tom Schouten wrote:

     > On Mon, Sep 21, 2009 at 01:47:35PM -0500, john@... wrote:

    >

    >>   ... go read Backus, Bird, de Moor, Meijer, Fokkinga,

    >>   Paterson, Tatsuya, Iverson, Meertens, Gibbons, et cetera.

    >

    > Care to complete the list?

    >

    > [1] http://nl.wikipedia.org/wiki/John_Backus

    > [2] http://www.comlab.ox.ac.uk/people/oege.demoor/

    > [3] http://en.wikipedia.org/wiki/Richard_Bird_%28computer_scientist%29

    > [4] http://lambda-the-ultimate.org/user/776

    > [5] http://www.soi.city.ac.uk/~ross/

    > [6]

    > [7] http://en.wikipedia.org/wiki/Kenneth_E._Iverson

    > [8] http://en.wikipedia.org/wiki/Lambert_Meertens

    > [9]

     [6] http://www.tom.sfc.keio.ac.jp/~hagino/

    [9] http://www.comlab.ox.ac.uk/jeremy.gibbons/