<div dir="ltr">Cris,<div>what an excellent excuse to evade the truth of our existence: We WILL NOT LEARN! :)</div><div><br></div><div>To me a programming language is a tool to convince the hardware into doing something useful.</div><div>When it tries to do more than that I have a terrible itch to dump it.</div><div>So yes sometimes i have found use for OO, sometimes I have found use for functional programming,</div><div>and sometimes I shot myself in the foot with either of them because I thought I did not have to LEARN;</div><div>the language paradigm would do the job for me. hahaha.</div><div><br></div><div>For Oberon section 6.6.1 in the green book sums up everything there is to learn to be able to do </div><div>functional programming in Oberon. </div><div>You are free to expand on that and make your own library Modules.</div><div><br></div><div>After all Robert Dewar did a SPITbol package for Ada. (Look up Snobol in wikipedia) and it is very nifty.</div><div>Although at first sight Ada's paradigm and Snobol's paradigm are eons apart.</div><div><br></div><div>And here is the weekend laugh:</div><div><a href="http://www-users.cs.york.ac.uk/susan/joke/foot.htm">http://www-users.cs.york.ac.uk/susan/joke/foot.htm</a><br></div><div><br></div><div>Cheers,</div><div><br></div><div>j.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 17, 2015 at 8:40 AM, eas lab <span dir="ltr"><<a href="mailto:lab.eas@gmail.com" target="_blank">lab.eas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some years ago when the OO-paradigm was at it's peek, ETHO was extended<br>
to handle procedure types, which could be passed as arguments.<br>
<br>
There's great advantages in avoiding temporary-fads, so I never exercised<br>
OOP. Now [using LEO] that it's less easy to access my old NativeOberon<br>
files, I failed to find the documentation, and example uses of the<br>
<passing PROCs as arguments>.<br>
<br>
Where should I look?<br>
<br>
Can Oberon procedure types facilitate the <functional/compositional><br>
style of programming?  Which is NOT a passing fad.<br>
<br>
*nix's <piping of functions/data-transformers> is staggeringly<br>
economical in user's effort, but has a terrible syntax.<br>
<br>
The benefit of removing the need to learn ad-hoc syntaxS is my<br>
motivation for syntax-directed-editors & menu-driven-usage:<br>
which ETHO already used successfully.<br>
<br>
An example of *nix's ability to easily get results by piping a sequence<br>
of existing/proven/well-tested functions together [but using<br>
understand-able syntax] is:--<br>
<br>
CheckTheFileDataBaseForFilesNamed *roc*ointer*<br>
| ButSkipAllFiles *.pdf *.zip *.ps *.gz<br>
| AndListThoseContainingString "beron"<br>
<br>
The big advantage of this functioal/compositional style is the<br>
maintainablity. Which is the whole idea of NW's "MODUL"a and<br>
"COMPONENT" pascal.<br>
<br>
Some years ago, when my then ISP introduced Sender-must-ID<br>
for email, it was quite a job to modify the ETHO <emailer>.<br>
<br>
Now there's a new-fad which messes my TextToSpeech facility:<br>
instead of 'saying' "can't",<br>
it says "Sea Aye Enn Tea";<br>
because many feature/fad-following clowns are replacing the<br>
one-byte single-quote [ASCII] by 3 bytes.<br>
<br>
Since the substantial processing-stages of fetching [unfortunately<br>
these days http-formatted] text, visually scanning it to wipe-out<br>
<bad sections> by an ETHO-like editor, and getting the TestToSpeech<br>
to a device, as a suitably-named file,<br>
needs only a few mouse-chords and typing the chosen name,<br>
you don't need to understand the details of each stage.<br>
<br>
So you can just plug-a-function-into-the-pipe-line to:<br>
 <translate the 3-byte-quote-fad to ASCII(SingleQuote)>.<br>
<br>
Which just needs pasting from your library of examples, a 10 char line,<br>
and editing/modifying it; into the suitable pipe-line position.<br>
<br>
That's why I call it MickeyMouse programming.<br>
<br>
A most convincing argument, for me, for the functional style, is:--<br>
<br>
   Let's create a list of all even numbers up to 100, and another list<br>
   omitting the first five of them.<br>
<br>
   The program written in Java.<br>
<br>
   final int LIMIT=50;int[] a = new int[LIMIT];<br>
   int[] b = new int[LIMIT - 5];<br>
   for (int i=0;i < LIMIT;i++) {<br>
       a[i] = (i+1)*2;<br>
       if (i >=5) b[i - 5] = a[i];<br>
   }<br>
<br>
 The program written in ###<br>
<br>
   let a = [2,4..100]<br>
   let b = drop 5 a<br>
<br>
   It is immediately clear that with ###, you can understand what's<br>
   going on; whereas in Java, or any imperative language, you can barely<br>
   tell what the code is supposed to do because you are overwhelmed with<br>
   the low-level minutia. This effect increases as programs grow more<br>
   complex. From this simplicity and abstraction flow most of ###'s<br>
   advantages.<br>
----------------------------- end of extract. --------------------<br>
### <- let's not get stuck on NAMES.<br>
Let's rather first understand the CONCEPTS.<br>
Of course, the above is an extreme example, but ETHO's already existing<br>
facilities could perhaps do:<br>
<br>
 MapFunctionOverElements(DigitToText:PROC,<br>
      DigitSequence: TextString):TextString;<br>
<br>
 MapFunctionOverElements(TestForPrime:PROC,<br>
      Ints1toN: IntegerList):IntegerList;<br>
<br>
There's nothing new about this. Extracting from McCarthy [designed lisp<br>
in 60s?]:-<br>
These three procedures clearly share a common underlying pattern. They<br>
   are  for  the  most  part identical, differing only in the name of the<br>
   procedure, the function/job of a used to compute the term to be added,<br>
   and the function that provides the next value of a. We could generate each<br>
   of the procedures by filling in slots in the same template:<br>
------ snip lisp code ---<br>
   The presence of such a common pattern is strong evidence that there is<br>
   a  useful  abstraction  waiting  to be brought to the surface. Indeed,<br>
   mathematicians  long  ago identified the abstraction of summation of a<br>
   series and invented ``sigma notation,''<br>
   to express this concept. The power of sigma notation is that it allows<br>
   mathematicians  to  deal  with  the concept of summation itself rather<br>
   than  only  with  particular sums -- for example, to formulate general<br>
   results about sums that are independent of the particular series being<br>
   summed ...<br>
<br>
What are unforeseen problems in using ETHO to do this too?<br>
<br>
== Chris Glur.<br>
<br>
PS. it's very problematic pasting the pre-written text into the web-browser<br>
for gmail [designed for F/B-twitter kiddies=modern] compare to the 90's<br>
N-O emailer. Can Linux:Aos handle gmail?<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div><br></div>