Re: [stack] function "adjoinment"?

> Nowak gave a good answer to this. Mine is a little different:
> No. If all you know how to read is plain English text, don't
> expect to be able to read Lisp, Algol, or Joy at all.

I've arrived here via: semi-conductor junctions > transistors > registers
->CPUs -> binary coding -> hex coding -> asm -> various HLL.
If I was A kiddie who'd entered via C, I might be fascinated to look
*down* to see [and grovell with] the underlying details.
At this stage of life I want to move *UP*.
I want the computer to do the grovelling.
OTOH notions like voice input are absurd, and even colloquial english is crap.
I favour a method that builds on what we've got: decades of schooling and
practice in reading.  IIRC a note here previously led to a mention of
'limited syntax' ideas for speech eg. as used in aviation-speak.
So, remove art/creativety from what can be formalised and automated.

> You already know that bash, csh, and scsh are made to be
> mainly compositional (the first two are pretty bad programming
> languages aside from their ability to compose other languages'
> work).

IMO these [full featured, with control structures ..etc] are botched [l
ike C] nightmares, where the 'template writer' which I mentioned is
good to handle -- I want to make a template to translate cannonical
english into Chinese too.

The only good thing about 'shell programming' is the ability to pipe.
Eg. I threw together something to convert:
   Nowak  gave  a good answer to this. Mine is a little different: No. If
   all you
   know  how  to  read  is plain English text, don't expect to be able to
   read
 to:
> Nowak gave a good answer to this. Mine is a little different:
> No. If all you know how to read is plain English text, don't
> expect to be able to read Lisp, Algol, or Joy at all.

Taking existing functions, it does something like:

 RemoveMultipleSpaces | ReplaceLineEndWithSpace | CutLinesAtWordBoundryForLen<80
 ...etc.

> If compositional programming is so awesome, why isn't every
> program written using one of these languages to stitch its
> other languages together?

I only accept inductive inferences in fuzzy field like anthropology and
sociology. We are discussing science. Even IF the soft/fuzzy aspect of
psychology/cognition is applicable, it is scientifically analyzable

>> I mean the data-flow paradigm, and especially where there
>> are no globals; so that at stage N the programmer doesn't
>> need to know/see what happened in the previous N-1 functions
>> i.e. effective information hiding.

> ...but this is actually a thought-provoking definition. I
> suspect that it's impossible and I'm not sure that it's at all
> practical; it seems to imply that each word in the definition
> of a program would have to be operationally independent of all
> the previous words; but such a language would be incredibly
> verbose, since you'd have to have distinct words for any
> possible operation, with no possibility of overloading due
> to context (since the definition excludes the possibility of
> using context).

In the extreme, my example above has ONE word "|" : pipe;
 and access to an infinite library of functions, one of which
 might be named "factorial".

What I'm interested in, is extending this model with some
control structures, ability to 'feed input to the data flow
at stage I and to "branch/Tee" output at stage J ...etc.

I've just realised that what I'm considering is old-hat and already
repeatedly proven: the layer-structure where each layer-worker
only needs to know about his 2 immediate neighbouring levels;
which via information-hiding greatly increases productivety.

== Chris Glur.