[Oberon] Functional programming style for Oberon?

[eas lab]

] Lisp is jokingly a procedural language being fraudulently sold
] as functional.
Wrong. Try to work scientifically; with definitions, not slogans.

]Show me the science and the studies done. ...

I gave you an example of how *nix-piping impressed ME.
Imagine the complexity of taking text from inet
 | converting the text to speech in *.wav format
 | convering the *.wav to *.mp3
 | writing the *.mp3 to your mobile-phone ?

What is the code to do it?.
3 tokens:  textFileID, DestinationFileID, utility to doit.
So avoiding clutter, you can: T12Z <FileName> <DestName>

Like with ETHO which *IS* functional:
  T12Z & <FileName> are just one klik each.

I'm more impressed with the ETHO's OS than the language.
The OS already follows the functional/piping style:.

Then because of some new-fad [probably M$ originated], single-quotes
are not 1-byte, but 3. So the complete TTS system fails.

With Oberon or other normal/procedural code, you'd need to dig in and
decode the source to fix it. With functional/*nix-piping, you just add
a 20-char-function that:
 replaces the <new fad/virus bytes> with Char("'")
and you don't WANT to know about the rest of the code.

As previously stated ETHO OS does piping: Eg.
 Exchange all "red" with "yellow" in files: *Fruit*.Mod in <DirTree>
A proper functional language [apparently Wolfram's Mathematica is good]
 might do:
 find <DirTree> FileName: *Fruit*.Mod
 | ReplaceAll("red","yellow")  <- I lapsed into PASCAL ;-)

Instead of piping the results between each stage/function:
ETHO OS puts each result to an anonymous [you don't need to remember its
name] TextFrame. Since eg. ET.Tool can position, create & kill TextFrames,
I suspect that an ET.Do script could be written to:
  mark TextFrame position [to be able to kill it after use]
  Get list of files [to TextFrame]
  next operation/function on list of files, to alternate TextFrame;
  Kill position1 TextFrame, for further use to position new TextFrame
  .....REPEAT.

ML seems an interesting functional programming language:
 the output if each stage [of the functional pipe] is called "it".
So you don't need a vocanulary of Identifiers like with non functional
languages.

PASCAL's functional style, shows how the local variables are <got rid of;
so to find:
Maximum of age-difference between SetOfCats, SetOfDogs
  ABS(Age(Dogs,oldest)-Age(Dogs,youngest)
    - Age(cats,oldest-Age(cats,youngest));
This is related to your data-base that you wrote about.

Don't get hung-up on Haskell and monads.
Reading their literature exposes that they're saying <if FEELS nice>, but
they can't explain why. OTOH, there are some classical texts from decades
ago with solid proof/examples of the ECONOMY of effort from FP.
Eg. Backus's 70's award winning ACM lecture.

Traditional coding, eg. Oberon is good to reduce unemployment.
The format is:--

declare all the soldiers and materials = zillion names to remember
DoStage1

declare all the soldiers and materials = MORE zillion names to remember
DoStage 2 using also any NAMED previously returnedvalues

declare all the soldiers and materials = MORE zillion names to remember
DoStage 3 using also any NAMED previously returnedvalues

REPEAT .....
Each newly declared variable is an extra mental load and potential error.

By contrast the FUNCTIONAL TextToSpeech example structure is:

1.Put chosen name in fixed location for finalStage to use: Name := Jon
2.Get TextFile to use as input: TextFile := <TextFile>
3. GetTextFile | CleanBadSuff1....CleanBadstuffN
    | convert to TextFile.wav   |   convert to TextFile.mp3
    | store to final location using pre-set Name [ie. Jon]
produces Jon.mp3 at final location.

==Chris Glur.

PS. a previous contributer here: Sorren; started on the ETHO.
implementation of a version of the 'joy' functional language.
I see no point in writing the functions in joy or forth.
Oberon would be easier.

The way the ETHO *O S* with Gadgets, and perhaps Layla, which I've never
used, is built ON TOP OF Oberon [ie. extending Oberon].
 is what I'm advocating.

PSS. ETHO has already got a usable Scheme.Tool