A Joy VM in OCaml

[Tom Schouten-3]

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-3]

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

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]

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-3]

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]

> 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-3]

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]

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

>> 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-3]

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]

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 Nowak]

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]

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-3]

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]

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

[JohnCarter]

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 : [phone]
Tait Electronics                        Fax   : [phone]
PO Box 1645 Christchurch                Email : john.carter@...
New Zealand