Re: [stack] Re: Jon Purdy: Why Concatenative Programming Matters

Yes certainly Concatenative Programming Matters, but to convince others
who have vast experience/INERTIA with old stuff one should do a.
Hello-world demo before giving the theoretical analysis of cat-style.

I want to take this real-life problem to illustrate how powerfull
[i.e. big results from small effort] the concatenative/data-flow programming
method is; which *nix is using all the time, without even mentioning it.

My problem is to know what path each of 28 consols, spread over 11 workspaces
has.  So that when an 'item' arrives I know which of the 28 consols is
setup to handle the item. If I don't know that consol-11 is already setup to
handle 'planets', when venus arrives, I'll open a new/redundant and even
possibly-conflicting 'planets-path'.

The particular unix syntax, which I too don't know well, is unimportant to the
principle demonstrated here. The key idea is to see how the data is transformed
[mostly just filtered] through multiple stages.

 pstree -p | awk '{print $2}'
which syntax we'll ignore [only the "|" character is important] means
 <give me the table showing the number of each process/consol>
        AND PASS THAT THROUGH THE FILTER WHICH
cuts off the 1st field of each line ie. give me the 2nd fieldS.
Fields are separated by space or tab - by default.

The 2nd field of a  typical line [of the 28] looks like:
|-xterm(6877)---bash(6879)---mc(6895)---bash(6897)
.
We want to know the 'path' corresponding to process: 6897, and the other 27.

`lsof | wc -l`
again has the magic syntax, using the "|" <concatenative> symbol, and
says give me the 'lsof' table
        AND PASS THAT THROUGH THE FILTER WHICH
counts the number of lines.
I my case I get 4099, which is not part of the problem, but just gives you
an idea of the size of the data to be filtered/manipulated.

The 1 of 4099 lines which contains the path corresponding to the 6897 process
looks like:-
bash    6897     root  cwd     DIR    22,17   4096    384273 /mnt/p17/Feb2012
where the second field: 6897; is the process-number which has the last-field:
 /mnt/p17/Feb2012 as the required path.

Unfortunately 27 other lines also have 6897 as their 2nd field.
I believe that 27+1=28 is UNrelated to the 28 consols - just coincidental.
It seems that the required line [one for each consol] is distinguished by "cwd"
as the 4th field. The details of the table are irrelevant to the demonstration
of how 'cat style solves big problems easily'. I just looked at the table for
a distinguishing field for the required line.

So the line which CONTAINS the key [for 6897] is got by:
   lsof | grep 6897 | grep cwd
which means:
 gimme the table of open-files
 but only the lines which contain 6897
 and only those which contain cwd.
So that's 3 instructions to get the one of 4099 lines.
and a final ONE instruction say:
 gimme the last field only.

And here/now :  lsof | grep 6897 | grep cwd | awk '{print $9}'
gives me:.
   /mnt/p17/Feb2012

And fluent <one line *nix jockeys> would know how to easily append the path:
 /mnt/p17/Feb2012  to the end of the `pstree-p` generated line, to give:

|-xterm(6877)---bash(6879)---mc(6895)---bash(6897) = /mnt/p17/Feb2012
  for each of the 28 consols.

So far the whole experiment has only used *SIX* instructions !! I think.
And a vocabulary of 4 different instructions:
  pstree, awk, lsof, grep.
How can you possibly deny that Concatenative Programming Matters,
 when it can do such a BIG job with a vocabulary of 4 instructions?
----------------------------

It seems that each line of the 1st-flow must have the 2nd-flow
 appended/attached to it.
So the 2nd flow is nested inside the 1st.

But that takes the problem outside of pure cat-style/piping to another.
dimension.

What I'm trying to work out is: how did the unix designers know what
filters to design, to act as 'primitive' instructions?.
I.e how to get a optimal set of primitives <which are Turing complete?> ?
-----
Re. impedance matching: *nix seems to have solved this, without discussing the
theoretical background, by having the in/output of 'all' filters being
<a sequence of text lines>.  This leads me to think that a text editor
would be a good exercise to test/experiment with cat-style, since the.
in/out could be fixed N-lines of L-len each?

== Chris Glur.