[Oberon] concrete use of open array -> functional-style

[Chris Glur]

Cc:
Newsgroups:

--- spir  wrote
> > Right, I will need such a pattern for higher-order funcs. Not that
> > I appreciate the functional paradigm, 
No ! functional style gives great advantages.

> > but some match typical patterns,
> > eg for collections (find --> element; filter, map --> collection;
> > any, every --> boolean). I particuliarly like the clarity of code
> > 'every' enables:
> >	IF numbers.every(isNaturalNumber) THEN ...
> >	IF objects.every(isNotNil) THEN ...
> >	IF inputData.every(isValid) THEN ...

This is what we need.

Joerg wrote:-
> You're right, Oberon does offer e.g. ARRAY OF REAL but
> no higher functions like "filter" or "every" that work on it
> natively.
> 
> The good news however: these functions can be added if needed.
> The higher data type (Element, Collection..) and their
> corresponding functions (find, filter, every..) are encapsulated
> in a MODULE. Instantiation, input and output of those
> higher data structures should be handled in this MODULE as
> well.

I'm sure someone has already done this.
Let's have what's already been constructed!

Although I've used ETHoberon every day for decade/s,
I've never written any code as substantial as I wrote
previously in turbo-pascal. 

Since we 'must' base our code on the existing S3
framework, and extend it, I'm repeatedly frustrated
when instead of say:
   StoreTo(FileName, ...  ,
I see in every one of the many sources that need to
get the filename from <ID>, "*" or "^",
the use the tedious routine of:
 * declare auxiliary varaibles,
 * intialise var-args,
 * call
 * unpack returned values
from the assembly code mentality, sources.

We discusssed this before, and I suspected that because
ETH is a teaching intitution, 'each student must have
done the "exercises" to graduate', instead of just calling 
the low-level routines which were previously written,
via "well factored code".
I.e. each student must get practice in inventing the wheel?

With initial skeptisism, I've recently been following the debate
about functional languages eg. :---- extract --------
  http://www.onlamp.com/pub/a/onlamp/2007/05/21/
   an-introduction-to-haskell---part-1-why-haskell.html
   
 If I want to define a function that takes a list of values, and
 returns only the even values in that list, it would look like this
 in the interpreter:
   Prelude> let evens = filter even  -- define the function
   Prelude> evens [1..10]            -- filter numbers out of a list
   [2,4,6,8,10]

 This example may appear trivial, but it demonstrates a key benefit of
 working with lambda calculus in a functional programming language
 -- the ability to create specialized functions by merely gluing
 together a small number of more generalized, pre-existing
 functions.

   Interestingly, this is exactly how shell pipelines work.

 Writing the function evens in C is much more complex. First, the
 output list must be allocated, and to do that, the number of output
 values must be counted. Next, the values must be copied to the new
 list, one at a time. This simple expression in Haskell becomes this
 function in C:
    int *evens(int *in, int count) {
        int matches = 0;
        int i, *out, *ptr;

        for (i = 0; i < count; i++) {
            if ((in[i] % 2) == 0) {
                matches++;
            }
        }

        out = malloc(sizeof(int) * matches);
        ptr = out;

        for (i = 0; i < count; i++) {
            if ((in[i] % 2) == 0) {
                *ptr = in[i];
                ptr++;
            }
        }

        return out;
    }

 This function defines the combined behavior of the Haskell definition
 of evens. That is, this block of code is equivalent to the expression
 'filter even' in Haskell. If there were a C library function that
 handled the behavior of filter, this code would be simpler. However,
 this is kind of solution is sadly idiomatic in C-like languages.
-------------- end of extract -------------
What broke my initial skeptisism against functional/concatinative
languages' claims was that I started writing an ETHoberon utility
to transform eg:-
> Lambda calculus is   spurious-spaces    nothing more
than a precise set of rules that ==too-long-line
 describe how
> to evaluate functions.

   to
   
> Lambda calculus is spurious-spaces nothing more than a precise
> set of rules that ==too-long-line describe how to evaluate
> functions.

and abandoned it through frustration of having to grovel
at low level. 

Since I use mostly linux-ETHoberon these days, I checked for 
a linux solution; ie. that uses existing functions piped together.

The whole utility is a few characters which is tested incrementally
while being designed. I'm GUESSING [because I don't WANT to 
remember] that it does something like:
 write the text lines through a filter that:
 removes multiple spaces,
 and cuts the lines to (len < N) at word-boundries,
 and if the first line started with "[>]{' '}" then let all
 new-lines start similarly.
-------

How many of you have tried ETHoberon's Scheme.Tool?
Quite remarkable.  I haven't tried LayLa yet!

I've got no doubt that very powerful higher levels of
abstraction can be conveniently built with ETHoberon.

Perhaps some tools already exist in the above described
direction?

== Chris Glur.

PS. a further example, that I use every day, that reminds
me of the power of 'composing functions' [stringing
filters in series] is: FindTelephoneNumber(someone),
where I know that my telephone-directory is in the
<root-dir> of <one of my partitions>.
So I just need to 'compose' the 3 simple concepts.

1=show me the list of mounted partitions
    and use my selected one,
    because I don't want to remember,
    and I'll recognize, when I see it.    == df
2=and list the file-name/s   "*ele*"   == ls "*ele*"
3=and list the line/s which contain 
            "<someone>"                 == | grep  someone
            
            
NB. this case is done interactively, because I want to
recognise the partition's name and be able to humanly
select the recognised <telephoneDirectory> filename.
---------
These people who write *nix scripts, have no
difficulty in writing one-liners to eg. :-
 list all the File-IDs with the lines containing <string>,
 which were written in June or July,
 between 1994 and 2007 - inclusive;
 and reverse-order 
 the lines by non-white-char count.
 
PSS. I've just remembered how astounding ETHo's Vinci
tool is; which is built on scheme, which is built on oberon.
Unfortunately, automating the creation of drawings is
a very specialised application, not needed by many.  
But hi-level functions to manipulate text in files are needed 
every day. Such facilities, which exist for *nix, give massive 
productivety increases.
I'm confident that we too could have them, as oberon-users.