[Oberon] extending ETHO to function-composition syntax.

[eas lab]

]> 1. replace the sequence of MarkedViewers by just 2, which are cycled.
]
]Interesting proposal.
]
]In the TUI, the input viewer of a command can be identified by the
]* cursor.  When the command opens an output viewer, the * might be
]put there.  Just one idea.  Likely there are better.
]
A : position TOP of outputViewer; <-- via <ET.Marker X Y>
B : step-down into TextFrame, [below MenuFrame];
C : execute M.P, who's output will write to position B;

Can't some of the beginners solve this puzzle, or give a formal
proof that it's not viable ?!

]> 2. perhaps replace the MarkedViewers, which take up screen space,
]>   with an <invisible carrier> like unix does ?
]
]For interactive work, the result of each step being visible in
]a viewer can be helpful for debugging and understanding.  I'd
]suggest keeping successive viewers.  Once a calculation is
]working properly, the whole sequence can be compiled as a new
]command.

You won't do it, unless the pain is sufficient; eg. you need
<show me the 9 latest files in this dir & their sizes> for this dir
that you were last working in ca.22 months ago. My linux: Lz script is
continually used for this.

IIRC ETHO can't do it: <SysDir *\d> does NOT order them, and gives you
ID <wrongly Formatted date> <Time> : fields.

So you need to eg:
RX the date-field to the front |
RX the date field to: Year:Month:Day format |
<Miscl.Sort \uniquely> |
Perhaps only show a few, is less important for ETHO than linux.

An important aspect of compositional style, is that you can test/confirm
up to stage N. And if stage N+1 is very tricky, and best suited to manual
execution, it's OK. Perhaps you'll automate stage N+1, next year, and
just append it to the tail. Or more importantly, you can ETHO compile/get
complex transformations, which you use in your compositions.

One reason why I'm so enthusiastic about <composition>, is that I've
 stopped <heavy reading>. I just lie-down and have it read to me,
like a baby; new text and old stuff accumulated via <text only fetches>:
using `wily` [which is based on ETHO]:-
* manually mark the begin & end of the text;
* manually mark a suitable Name;
* push "GO";  which does:
= remove all URL-links, like [174]  |
= convert the text to speech: <suitable Name>.wav  |
= convert <suitable Name>.wav to <suitable Name>.ogg <-save 85% space

]> ... function-composition ...
]
]FWIIW, composition is a central concept in Category Theory.
]Desktops.OpenDoc  "http://en.wikipedia.org/wiki/Category_theory"

This is a further example for this very topic:
 for tasks which are too varied or rare, our Tool.* is more appropriate
than the compositional-script that I'm suggesting.
So, eg.
 Desktops.OpenDoc  "http://en.wikipedia.org/wiki/Category_theory"
is problematic [effectively useless] since you can't read the Latex
mathSymbols. But you can evolve your LatexMath.Tool over time, to handle
such. Again, like composition: it doesn't get <dirty> with use; it gets
smarter.

BTW, I had <wiki/Category_theory> which I'd previously fetched via links
[text only - which showed the ASCII of the Latex], and it was interesting
to  note the revisions. But a [not really important] diagram was missing,
so I fetched the stuff via a full-featured-browser.

IMPORTANTLY the ETHO version is the most valuable:
= after you've manually edited the <maths chars> while you're spending
  time to study the text.
= you can COLOR the related parts, according to *YOUR* understanding.
= you can paste any important diagrams into the ETHO version.
= you save the complete [but evolveable] ONE file, instead of the
  monster garbage directory, for the equivalent full-feature-browser.

ETHO is not just about the language.
It's about the unique/economical-of-your-effort user experience.

== Chris Glur.

PS. I've just d/l-ed this, which is related, and haven't yet LISTENED
to it:--
 Keep in mind that the programming tasks at Rosetta Code are the typical
   kinds of exercises that you can write in conventional programming
   languages: editing text, implementing quicksort, or solving the Towers of
   Hanoi. You wouldn't even think of dashing off a program in C to do
   handwriting recognition, yet that's a one-liner in the Wolfram Language.
   And since the Wolfram Language's ultra-high-level constructs are designed
   to match the way people think about solving problems, writing programs in
   it is usually easier than in other languages. In spite of the Rosetta Code
   tasks being relatively low-level applications, the Wolfram Language still
   wins handily on code length compared to every other language.
   ...bla...bla...