[Oberon] Functional programming style for Oberon?

[Jan de Kruyf]

Cris,
what an excellent excuse to evade the truth of our existence: We WILL NOT
LEARN! :)

To me a programming language is a tool to convince the hardware into doing
something useful.
When it tries to do more than that I have a terrible itch to dump it.
So yes sometimes i have found use for OO, sometimes I have found use for
functional programming,
and sometimes I shot myself in the foot with either of them because I
thought I did not have to LEARN;
the language paradigm would do the job for me. hahaha.

For Oberon section 6.6.1 in the green book sums up everything there is to
learn to be able to do
functional programming in Oberon.
You are free to expand on that and make your own library Modules.

After all Robert Dewar did a SPITbol package for Ada. (Look up Snobol in
wikipedia) and it is very nifty.
Although at first sight Ada's paradigm and Snobol's paradigm are eons apart.

And here is the weekend laugh:
http://www-users.cs.york.ac.uk/susan/joke/foot.htm

Cheers,

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/a46e447c/attachment.html>