[Oberon] Functional programming style for Oberon?

[Jan de Kruyf]

> PS. it's very problematic pasting the pre-written text into the
web-browser
> for gmail

When everything else fails try the Windows way:
Control-C
Control-V

j.


On Sat, Oct 17, 2015 at 8:40 AM, eas lab <lab.eas at gmail.com> wrote:

> 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?
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20151017/0a43d7c4/attachment.html>