# Re. what's the point of cat-like ?

## chris glur — 2010-01-05 00:07:10

    When it's too hard to explain, they revert to "try it, you'll like it",

    or the new buzz-phrase: "good experience".

    Previously when I queried/criticised "what's the point of cat-like?",

    I got hysterical threats of being cut-off the mailing list. Has that

    happened, or has it just fizzled ? My crit/prompt gave good results

    in widening my OWN view.  For those who can understand, here a paste of

    my preliminary design notes towards a cat-like labour saver:-

    The data-flow model applies: incrementally transforming to data:

    Task: find telephone number of 'Goode'.

    eg.  'print the line containing "Goode" in some file in dir ?X?',

    in some /root dir of some mounted partition.

    Previous method [pre-data-flow paradigm].

    1. get list of mounted partitions.       = df

    2. select and carry-over 'the one' [via mouse cut]    = X

    3. open a file-viewer at <thePartition>/root>   = ls #/*el*

    4. visually scan for a likely FileID name  = X

    5. open the file

    6. auto-search for "oode"     = # | grep oode

    7. mouse cut the corresponding tele-number.

    AFAIK joy/cat-style is suitable for data-flow problems.

    The above telephone-number-search is a data-flow problem,

    but with human intervention at various stages.

    How does this relate to the more general notion of:

     multiple data-flows merging at various stage/s ?

     ==> needs human intervention/guidance:

    ? what are the mounted partitions

    ? what are likely file-IDs

    ======

    If *nix-shell could do cat-like, the above task would be reduced to:

       df  X [ls *el*] X [grep oode]

    where X is the human-input.

    As it is, although *nix-shell can't do cat-like, it can do lisp-like,

    and the <previous command> can easily [i.t.o. minimal key-strokes]

    be wrapped/bracketed.

    =====

    Need to do unlimited transform-data via chaining.

      ==> StageN.Input got from StageN-1.Output

      ==> stack-based/forth-like is a natural form.

    ======

    To use the powerfull advantage of human-intervention in the data-transformation

    process,

      the ability to continue [perhaps by re-rolling from the begining  ] is needed.

      *nix achieves this by single-key:<restore/pop the previous command> and

      wrapping it as an arg [thunk-like] for the next stage.

      eg. "ls /mnt/FC14/*el*"  shows the likely 'telephone-directory' file/s

      Since we don't want to have to retype this command string again, we just refer

       to it as <the last command> by a single-key-stroke, which I'll call "#".

     So now the next stage, of outputting the found-file needs:

      cat #   [ie. output <the file which you found via your search>]

       where "#" is the long previous command.

    Astualy it's necessary to wrap # thus `#`; which needs  8 key-strokes, even

     as the total command [representing #] evolves to scores of chars.

     So: cat `#` needs

     # = 1

     ` = 2

      home = 3

     cat `=4..8

    This long-story about minimal key-strokes, is justified, because it's all about

      minimising  the cognative load.

     ==> the whole process must be understandable from the code - by the operator.

     ==> no deep-debugging/analyis is needed/allowed.

     ==> the operator must be able to EASILY increment /refine already tested code.

     ==> the perceived complexity must increase linearly rather than exponentially.

     ==> "it works up to stage N, now I only need to consider the transformation

      from stageN to stageN+1".

      Ie. good information-hiding: essential for managing complexity.

     ==> I don't need to be swamped by the combined complexity of the total first

         N-stages.

    .. to be continued.

    Q. are there, for cat-like design, any published: 'axioms', 'patterns';

       rather than "this feels good"?

    PS. I've just used concepts [economical tools] which I'd never have considered

    before the prompt/controversy of: "what's cat good for?"

    "cat ObnScript | strings | fold > /mnt/cdrom/ConCatLang/ConcatCrit/Jan10"

      has only 2 concepts:

    1. copy something that's been used/tested and works -- the library

    routine concept.

      Luckily I knew where to find something similar, that I'd evolved before.

    2. re-use it with minimal modifications, which are easy to understand,

    because of

    the lack of clutter of the notaion.

    2a. "cat ObnScript"  = output [from the current-dir] the file named 'ObnScript'

    2b. "| strings | fold" = and transform it so that it is readable, like it was

     transformed by the other script that used this, and don't worry about

    the details.

    2c. "> <the destination>" = and save it to the new place - for editing/mailing.

## John Nowak — 2010-01-05 05:22:10

    On Jan 4, 2010, at 7:07 PM, chris glur wrote:

     > When it's too hard to explain, they revert to "try it, you'll like

    > it",

    > or the new buzz-phrase: "good experience".

     I'm going to answer this once and for all...

    Joy and similar languages likely share the benefits of other pointfree

    approaches. There are two main differences between Joy and other

    pointfree languages like FP:

    1) All primitives functions operate on terminated nested pairs (i.e.

    "the stack").

    2) By convention, almost all primitives can be passed more arguments

    than they need which are simply returned unaltered (e.g. '+' returns

    everything beyond the top two elements unchanged).

    The first point also has a corollary: Functions are never curried;

    higher order functions take the functions they operate on in the same

    product as the values to be operated on.

    The second also has a corollary: Implementations inspired by linear

    logic become viable without a resource-aware type system or other

    means of enforcement; see Baker's "The Forth Shall Be First" paper.

    The utility of this is debatable.

    Unfortunately, another corollary of of 2 is that programs can easily

    become overly sequential and opportunities for parallel reduction (and

    algebraic manipulation) are not syntactically obvious. Other problems

    exists but are more subtle.

    For the benefits of pointfree programming in general, research via the

    links Tom and I posted. For the benefits of stack-based languages in

    particular, namely implementation simplicity, meta-programming, and

    code refactoring benefits, look to the Forth community.

    You shouldn't need any further guidance on this question. If you're

    interested in pursuing it, I think there may be some fruitful research

    opportunities here.

    - John

## William Tanksley, Jr — 2010-01-05 06:46:54

    chris glur <crglur@...> wrote:

     > When it's too hard to explain, they revert to "try it, you'll like it",

    > or the new buzz-phrase: "good experience".

     Yup, understood.

     > Previously when I queried/criticised "what's the point of cat-like?",

    > I got hysterical threats of being cut-off the mailing list. Has that

    > happened, or has it just fizzled ?

     Don't worry -- I never considered throwing you off the list before

    this. So clearly, the hysteria level wasn't bad enough then.

     > My crit/prompt gave good results

    > in widening my OWN view.  For those who can understand, here a paste of

    > my preliminary design notes towards a cat-like labour saver:-

     Cool! I hope it's a lot of fun -- I'm having fun with my own

    concatenative toy (although mine's a LOT less practical than the one

    you're thinking about here).

     > Q. are there, for cat-like design, any published: 'axioms', 'patterns';

    >   rather than "this feels good"?

     Yes; but it's generally under the rubric of specific languages. Factor

    has some idioms of its own; Forth has a LOT (see the "1x Forth" talk

    Chuck Moore gave).

    -Wm