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@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@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

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@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@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon