[Oberon] Functional programming style for Oberon?

eas lab lab.eas at gmail.com
Sat Oct 17 08:40:11 CEST 2015


Some years ago when the OO-paradigm was at it's peek, ETHO was extended
to handle procedure types, which could be passed as arguments.

There's great advantages in avoiding temporary-fads, so I never exercised
OOP. Now [using LEO] that it's less easy to access my old NativeOberon
files, I failed to find the documentation, and example uses of the
<passing PROCs as arguments>.

Where should I look?

Can Oberon procedure types facilitate the <functional/compositional>
style of programming?  Which is NOT a passing fad.

*nix's <piping of functions/data-transformers> is staggeringly
economical in user's effort, but has a terrible syntax.

The benefit of removing the need to learn ad-hoc syntaxS is my
motivation for syntax-directed-editors & menu-driven-usage:
which ETHO already used successfully.

An example of *nix's ability to easily get results by piping a sequence
of existing/proven/well-tested functions together [but using
understand-able syntax] is:--

CheckTheFileDataBaseForFilesNamed *roc*ointer*
| ButSkipAllFiles *.pdf *.zip *.ps *.gz
| AndListThoseContainingString "beron"

The big advantage of this functioal/compositional style is the
maintainablity. Which is the whole idea of NW's "MODUL"a and
"COMPONENT" pascal.

Some years ago, when my then ISP introduced Sender-must-ID
for email, it was quite a job to modify the ETHO <emailer>.

Now there's a new-fad which messes my TextToSpeech facility:
instead of 'saying' "can't",
it says "Sea Aye Enn Tea";
because many feature/fad-following clowns are replacing the
one-byte single-quote [ASCII] by 3 bytes.

Since the substantial processing-stages of fetching [unfortunately
these days http-formatted] text, visually scanning it to wipe-out
<bad sections> by an ETHO-like editor, and getting the TestToSpeech
to a device, as a suitably-named file,
needs only a few mouse-chords and typing the chosen name,
you don't need to understand the details of each stage.

So you can just plug-a-function-into-the-pipe-line to:
 <translate the 3-byte-quote-fad to ASCII(SingleQuote)>.

Which just needs pasting from your library of examples, a 10 char line,
and editing/modifying it; into the suitable pipe-line position.

That's why I call it MickeyMouse programming.

A most convincing argument, for me, for the functional style, is:--

   Let's create a list of all even numbers up to 100, and another list
   omitting the first five of them.

   The program written in Java.

   final int LIMIT=50;int[] a = new int[LIMIT];
   int[] b = new int[LIMIT - 5];
   for (int i=0;i < LIMIT;i++) {
       a[i] = (i+1)*2;
       if (i >=5) b[i - 5] = a[i];
   }

 The program written in ###

   let a = [2,4..100]
   let b = drop 5 a

   It is immediately clear that with ###, you can understand what's
   going on; whereas in Java, or any imperative language, you can barely
   tell what the code is supposed to do because you are overwhelmed with
   the low-level minutia. This effect increases as programs grow more
   complex. From this simplicity and abstraction flow most of ###'s
   advantages.
----------------------------- end of extract. --------------------
### <- let's not get stuck on NAMES.
Let's rather first understand the CONCEPTS.
Of course, the above is an extreme example, but ETHO's already existing
facilities could perhaps do:

 MapFunctionOverElements(DigitToText:PROC,
      DigitSequence: TextString):TextString;

 MapFunctionOverElements(TestForPrime:PROC,
      Ints1toN: IntegerList):IntegerList;

There's nothing new about this. Extracting from McCarthy [designed lisp
in 60s?]:-
These three procedures clearly share a common underlying pattern. They
   are  for  the  most  part identical, differing only in the name of the
   procedure, the function/job of a used to compute the term to be added,
   and the function that provides the next value of a. We could generate each
   of the procedures by filling in slots in the same template:
------ snip lisp code ---
   The presence of such a common pattern is strong evidence that there is
   a  useful  abstraction  waiting  to be brought to the surface. Indeed,
   mathematicians  long  ago identified the abstraction of summation of a
   series and invented ``sigma notation,''
   to express this concept. The power of sigma notation is that it allows
   mathematicians  to  deal  with  the concept of summation itself rather
   than  only  with  particular sums -- for example, to formulate general
   results about sums that are independent of the particular series being
   summed ...

What are unforeseen problems in using ETHO to do this too?

== Chris Glur.

PS. it's very problematic pasting the pre-written text into the web-browser
for gmail [designed for F/B-twitter kiddies=modern] compare to the 90's
N-O emailer. Can Linux:Aos handle gmail?


More information about the Oberon mailing list