Functional programming style for Oberon?

[n***@gmail.com]

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?

[Richard]

Post by n***@gmail.com
Can Oberon procedure types facilitate the <functional/compositional>
style of programming? Which is NOT a passing fad.

Niklaus Wirth is quite critical concerning functional programming
languages--see e.g. subchapter "Functional Programming" in:

https://www.inf.ethz.ch/personal/wirth/Articles/GoodIdeas.pdf

Some essential programming language features would have to be added to
Oberon in order to support functional programming. E.g., it would be
necessary to allow conditional statements within expressions. Then, one
would be able to write functions like this without the need for mutable
variables:

PROCEDURE Maximum (x, y: Integer): Integer
BEGIN
RETURN IF x > y THEN x ELSE y
END Maximum

In earlier versions of Oberon one could at least write the same in a
similar style:

IF x > y THEN RETURN x ELSE RETURN y

In the current Oberon version, however, the RETURN statement is only
allowed at the end of the procedure, and thus a solution like the
following, using a mutable helper variable, is needed:

h := x;
IF x < y THEN h := y END;
RETURN h;

My own attempt at a pure functional programming language based on the
Oberon syntax can be seen here:

http://trankvila.org

It turned out to be quite different to the Oberon programming language...

Richard

[Pascal J. Bourguignon]

Post by Richard

Post by n***@gmail.com
Can Oberon procedure types facilitate the <functional/compositional>
style of programming? Which is NOT a passing fad.

Niklaus Wirth is quite critical concerning functional programming
https://www.inf.ethz.ch/personal/wirth/Articles/GoodIdeas.pdf
Some essential programming language features would have to be added to
Oberon in order to support functional programming. E.g., it would be
necessary to allow conditional statements within expressions. Then, one
would be able to write functions like this without the need for mutable
PROCEDURE Maximum (x, y: Integer): Integer
BEGIN
RETURN IF x > y THEN x ELSE y
END Maximum

This is basically because FORTRAN implementers didn't want to include
this in FORTRAN, (and Algol designers didn't want to include COND into
Algol), that John McCarthy invented LISP. Notice that lisp processing
was already existing, in the form of a FORTRAN library (FLPL), with
CONS, CAR, CDR, etc. (the FORTRAN functions were named XLWORDF, XCARF,
XCDRF, etc). http://www.informatimago.com/articles/flpl/flpl.html

Post by Richard
In earlier versions of Oberon one could at least write the same in a
IF x > y THEN RETURN x ELSE RETURN y
In the current Oberon version, however, the RETURN statement is only
allowed at the end of the procedure, and thus a solution like the
h := x;
IF x < y THEN h := y END;
RETURN h;

So I guess that would explain a good part of the reduction of Oberon
users…

[y***@z505.com]

Post by Pascal J. Bourguignon

Post by Richard

Post by n***@gmail.com
Can Oberon procedure types facilitate the <functional/compositional>
style of programming? Which is NOT a passing fad.

Niklaus Wirth is quite critical concerning functional programming
https://www.inf.ethz.ch/personal/wirth/Articles/GoodIdeas.pdf
Some essential programming language features would have to be added to
Oberon in order to support functional programming. E.g., it would be
necessary to allow conditional statements within expressions. Then, one
would be able to write functions like this without the need for mutable
PROCEDURE Maximum (x, y: Integer): Integer
BEGIN
RETURN IF x > y THEN x ELSE y
END Maximum

This is basically because FORTRAN implementers didn't want to include
this in FORTRAN, (and Algol designers didn't want to include COND into
Algol), that John McCarthy invented LISP. Notice that lisp processing
was already existing, in the form of a FORTRAN library (FLPL), with
CONS, CAR, CDR, etc. (the FORTRAN functions were named XLWORDF, XCARF,
XCDRF, etc). http://www.informatimago.com/articles/flpl/flpl.html

Post by Richard
In earlier versions of Oberon one could at least write the same in a
IF x > y THEN RETURN x ELSE RETURN y
In the current Oberon version, however, the RETURN statement is only
allowed at the end of the procedure, and thus a solution like the
h := x;
IF x < y THEN h := y END;
RETURN h;

So I guess that would explain a good part of the reduction of Oberon
users...

Nice conspiracy theory. Ever try this conspiracy: Oberon doesn't have strings like PHP, GoLang, C++, and delphi. maybe strings are what people need these days, i.e. everything revolves around strings of text these days. It's called the internet. Full of text strings. Hmm. interesting. Databases: have strings. Wow. That's earth shattering news to us...

Hmm, nope. Array of char won't suffice. Sorry folks. Nothing to see here, move along now.

[August Karlstrom]

Post by y***@z505.com
Nice conspiracy theory. Ever try this conspiracy: Oberon doesn't have
strings like PHP, GoLang, C++, and delphi. maybe strings are what
people need these days, i.e. everything revolves around strings of
text these days. It's called the internet. Full of text strings. Hmm.
interesting. Databases: have strings. Wow. That's earth shattering
news to us...

The claim

Programming language X is popular => X has string variables

is falsified by substituting X with C.


-- August

[y***@z505.com]

Post by August Karlstrom
The claim
Programming language X is popular => X has string variables
is falsified by substituting X with C.
-- August

No, C has strings that you allocate memory for. They are called pointers to chars which is a string, albeit low level.
Pascal had strings, that were unusable in practice. C had strings that were usable. Their called pointers to chars. You can argue that these are not strings they are just pointers to chars, but they function as strings and for all intents and purposes are a type of string.

Why did C kill pascal? Because C had strings.

Falsified? You haven't a clue.

[August Karlstrom]

Post by y***@z505.com

Post by August Karlstrom
The claim
Programming language X is popular => X has string variables
is falsified by substituting X with C.

No, C has strings that you allocate memory for. They are called
pointers to chars which is a string, albeit low level. Pascal had
strings, that were unusable in practice.

I think the biggest problem with Pascal related to strings was the lack
of open array parameters.

Post by y***@z505.com
C had strings that were usable. Their called pointers to chars. You
can argue that these are not strings they are just pointers to chars,
but they function as strings and for all intents and purposes are a
type of string.

Character arrays in Oberon also "function as strings and for all intents
and purposes are a type of string."


-- August

[y***@z505.com]

Post by August Karlstrom

Post by y***@z505.com
No, C has strings that you allocate memory for. They are called
pointers to chars which is a string, albeit low level. Pascal had
strings, that were unusable in practice.

I think the biggest problem with Pascal related to strings was the lack
of open array parameters.

Oh come on now, you don't think also the fact that 255 was too limited.

Whereas C allowed unlimited (as much as your hardware allowed) length strings.

Pascal had all sorts of problems, not just one string problem, but several problems.

Another issue was no modules.. You had to shove all your code in a single pascal source file. Modula tried to solve this but no one uses modula, and modula likely didn't solve the string problem either.

C had include files which were not true modules, but made some headway.

Post by August Karlstrom
Character arrays in Oberon also "function as strings and for all intents
and purposes are a type of string."

Wrong. A string can grow in size, like in PHP and even standard pascal. oberon strings are arrays of characters, not strings. You can do kludges to make them act more like a string and Component Pascal BlackBox attempts to solve the issue, but is just a kludge. I believe oberon for Dot Net also tries to solve the problem and I won't comment here as I don't have enough experience, but from my research it was also a kludge.

Even if Oberon had C style strings it would be more useful, but you'd waste programmer time allocating memory like in C. In fact there is something probably like this by using the unsafe SYSTEM module, I don't know, I don't have enough experience with oberon. But my experience with blackbox component pascal is that ARRAY OF CHAR is in no way a string, even less so than plain C's string, which admittingly is not a full abstract string but a low level kludge too.

The problem with fixed length arrays of chars, where you predefine the max length ahead of the time, is like using an INTEGER and saying the integer MUST define it's max range, like standard pascal. This works great if you are psychic. Humans are not psychic. Why doesn't oberon FORCE you to define your max range integer use you will use? For example:

i: integer (0..20)

Some loops only increment up to 20 and do nothing else.
So why does oberon not force you to define your range that the integer will be ahead of time? Same goes with strings. The Wirth argument (or worthless, rather) is that you should KNOW ahead of time your string length, such as a file name that will only be 8 characters long and nothing more. In real life programs over time become larger and more advanced, and predefining your string length ahead of time is a huge mistake. This is commonly seen where someone thinks a file path should only be maximum 100 long, but systems in the real world we cannot be psychic about. Some business may have a file path that is 300 characters long. You cannot be psychic and know how your users will use your oberon tool. Wirth expects people to be psychics (developers).

This is also commonly seen in MySQL databases where people define a column of only 10 characters max. Then as their web application grows larger and more people use it people start complaining that 10 characters is not enough. So then they have to change all the code to increase it to 20 characters. Then they find 20 is not enough and eventually they just use an arbitrary length string or define it as 10000 max, or 1000.

So in oberon we have some hypocrites who use INTEGER all the time. Let me ask you, why do you use an integer and not an integer that has a range of only 10 or 20 numbers? Rarely does your integer ever get fully used. You rarely use the entire range of the entire integer. So why don't you strongly type the integer ahead of time as a range? Because Wirth took out ranges, as they weren't useful. Similarily, ARRAY 256 OF CHAR of ARRAY 1000 OF CHAR is rarely ever useful, compared to freepascal and delphi's "STRING" type.

Yes, in a rare case, I may in fact need a string that is only 8 chars long and I may want to limit it to 8 characters long. Rarely. Freepascal and delphi have this feature! As does C.

[Blue Bayou]

Post by y***@z505.com

Post by August Karlstrom
The claim
Programming language X is popular => X has string variables
is falsified by substituting X with C.
-- August

No, C has strings that you allocate memory for. They are called pointers
to chars which is a string, albeit low level.

That is not a string. It's a pointer to a bunch of chars, hopefully null
terminated. But as we see from countless CVEs, not nearly often enough.

Post by y***@z505.com
Pascal had strings, that were unusable in practice. C had strings that
were usable.

Well that's charitable. C strings are not what one thinks of with usable in
the same sentence. At least not if they have any knowledge of a real
programming language as opposed to something that was admittedly "designed"
(again, an overly charitable characterization) based on ease of
implementation rather than any silly notion of programmer usefulness,
language safety, coherence, etc. And it's ugly.

Post by y***@z505.com
Their called pointers to chars. You can argue that these are not strings
they are just pointers to chars, but they function as strings and for all
intents and purposes are a type of string.

That's pretty unequivocal language. They function as strings, ok to some
extent they do. Where it falls down is all the (mis)use of broken library
functions that have no idea how long a string is or how to move and copy
them around except by cruising down memory lane until a specific character
is found (or often not).

In any respectable language a string is a counted object and is safe to move
or copy efficiently without having to walk the whole object, without
inadvertantly trashing the receiving field, etc. Minor stuff like
that. There is just really no excuse for much of C and especially not the
1960s-era "strings." Of course this can't ever be fixed because of The
Standard, The Standard, The Standard. Tail wags dog.

Post by y***@z505.com
Why did C kill pascal? Because C had strings.

No, make no mistake, C did not kill PASCAL despite C's lack of strings.

PASCAL killed itself in some ways, and not in others. PASCAL was not
designed to be a production language and wasn't written by the right people
and at first had a lousy one-pass compiler and no serious facilities. It was
fine for what it was for, if you fall into the school of teaching languages
vs. using languages which I think we can all agree is a mistaken separation.

The two languages never competed for anything and share very little domain.

PASCAL actually did have some good implementations later that were far more
useful and safe than the best C compiler ever written. But C survived
because of timing and marketing, not on technical merit. If UNIX and later
Linux were not written in C, C would have died the death it deserved. It's a
great language for lazy sociopaths and pentesters. Other than that, not so
much. Most of the OS code written in C should have been written in
assembly. It's just that the lazy slobs wanted to run on everything badly,
and now they do.

[y***@z505.com]

Post by Blue Bayou

Post by y***@z505.com
Pascal had strings, that were unusable in practice. C had strings that
were usable.

Well that's charitable. C strings are not what one thinks of with usable in
the same sentence. At least not if they have any knowledge of a real
programming language as opposed to something that was admittedly "designed"

Yeah, try GoLang, designed by a student of Wirth himself.. which has a proper string that oberon doesn't have, except for Eberon which I pointed out in another post.

Post by Blue Bayou
(again, an overly charitable characterization) based on ease of
implementation rather than any silly notion of programmer usefulness,
language safety, coherence, etc. And it's ugly.

C was ugly but half usable. In fact I discussed here:
http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Why-C-Is-Not-My-Favorite-Programming-Language

And also:
z505.com/cgi-bin/qkcont/qkcont.cgi?p=What-The-Fuck-Is-This-C-Shit

Long long ago. They read all that and created golang, which addresses most of the problems, except for the "declare anywhere" issue.

Post by Blue Bayou
That's pretty unequivocal language. They function as strings, ok to some
extent they do. Where it falls down is all the (mis)use of broken library
functions that have no idea how long a string is or how to move and copy
them around except by cruising down memory lane until a specific character
is found (or often not).

Someone tried to solve this with a string library for C. It was called BSTRINGS but I haven't used it, bstrings, as I don't program in C that much.

Post by Blue Bayou
There is just really no excuse for much of C and especially not the
1960s-era "strings." Of course this can't ever be fixed because of The
Standard, The Standard, The Standard. Tail wags dog.

All discussed by myself in my wiki articles long ago, when I was much younger and more flaming than I even am now.


z505.com/cgi-bin/qkcont/qkcont.cgi?p=Why-C-Is-Not-My-Favorite-Programming-Language

z505.com/cgi-bin/qkcont/qkcont.cgi?p=What-The-Fuck-Is-This-C-Shit

Or search google for
z505 "why c is not my favorite programming language" including the quotes.

And the other page, has the F word in it, so I won't say what to search on google because it requires a swear word.

Post by Blue Bayou

Post by y***@z505.com
Why did C kill pascal? Because C had strings.

No, make no mistake, C did not kill PASCAL despite C's lack of strings.

There were many reasons, but pascal has been forked 1000 times like a hooker who's been in 1000 men's beds. Oberon has the same problem happening. How many forks of oberon are there?

Oh looky do we have here:
https://github.com/vladfolts/oberonjs/wiki/Eberon-Strings

Eberon, you ask? What's that?

Another fork of oberon.

How many forks are in my kitchen sink, and my kitchen drawer? Not as many forks as oberon has.

Hold on, let me go count.... I'll be back.

[W***@gmail.com]

Post by n***@gmail.com
Can Oberon procedure types facilitate the <functional/compositional>
style of programming? Which is NOT a passing fad.

S N I P
My own attempt at a pure functional programming language based on the
http://trankvila.org
It turned out to be quite different to the Oberon programming language...
Richard

Why do you claim "based on the Oberon syntax".
Having <multiple word identifier tokens> is disasterous!

In what way can I use your efforts to build on my already paid-for oberon
learning/experience?

==TIA.

[Richard]

Post by W***@gmail.com

Post by Richard
My own attempt at a pure functional programming language based on the
http://trankvila.org

Why do you claim "based on the Oberon syntax".

I mentioned the similarity with Oberon-2 syntax because most other
currently used programming languages are based directly or indirectly on
the ancient C syntax. Trankvila and Oberon-2 syntax differs from those,
for example, in the following aspects:

- assignment with ":=" instead of "="
- test for equality with "=" and "#" instead of "==" and "!="
- keywords instead of curly braces to delimit blocks
- declaration of variables and parameters in the form "name1, name2:
Type" instead of "Type name1, Type name2"
- semicolon is used as a separator, not as a delimiter
- type-bound functions/procedures ("methods") use an explicitly defined
receiver parameter instead of "this" or "self".
- all keywords are written with upper-case instead of lower-case characters
- and the main difference: the entire EBNF grammar fits on a single
instead of several pages :)

But, of course, there are also many differences to the Oberon-2 syntax
due to personal preferences and additional language features like
type-parameters ("generics").

Post by W***@gmail.com
Having <multiple word identifier tokens> is disasterous!

Why do you think so? Using upper-case keywords makes this possible with
little danger of naming conflicts.

Post by W***@gmail.com
In what way can I use your efforts to build on my already paid-for oberon
learning/experience?

I don't think there is a lot to gain from that. If you like the Oberon-2
syntax, you might prefer the Trankvila syntax to that of other
functional programming languages.

Richard

[Unknown]

Post by Richard
My own attempt at a pure functional programming language based on the
http://trankvila.org

--- SNIP ---

the entire EBNF grammar fits on a single instead of several pages :)

I didn't find it after wasting effort to decode that
"multiple word identifier tokens := 7" is 3 tokens.

Imagine writing music or schematic diagrams in novel/poetry-notation!
==========
ETHO already does piping: but manually, at the OS level, where the
intermediate-results are delivered to newTextFrameS.

How would trankvila do:
find the spelling of "?t*book" in that file,
which mentioned <string2>,
on partition 6,
from yesterday.

Under *nix [with its disasterous syntax] I might try
[manually, with intermediate stages, pasted from the previous output]:-
partition 6 = df | grep 6
files changed in last 2 days = find <partition 6> -ctime -2
which mentioned <string2>
= find <partition 6> -ctime -2 -exec grep -l "<string2>" {} \;

At this stage I've got a list of <path/fileS>, which is the one argument
of: FUNCTION GrepFilesContaining(<path/fileS>, "?t*book") : LinesList;

How does trankvila handle the type-matching between pipe-stages,
and currying ...?

[Richard]

Post by Unknown
Imagine writing music or schematic diagrams in novel/poetry-notation!

Imagine writing novels or poetry in uglyCamelCaseNotation or
with_all_words_connected_by_underscores. ;)

Post by Unknown
find the spelling of "?t*book" in that file,
which mentioned <string2>,
on partition 6,
from yesterday.
Under *nix [with its disasterous syntax] I might try
[manually, with intermediate stages, pasted from the previous output]:-
partition 6 = df | grep 6
files changed in last 2 days = find <partition 6> -ctime -2
which mentioned <string2>
= find <partition 6> -ctime -2 -exec grep -l "<string2>" {} \;

I'm not sure if such a comparison makes much sense, since the Unix shell
utilities are especially designed for tasks like this.

But, assuming that some module "File System" with the necessary
functions was available, one could program it like this:

LOCAL
partition 6 := File System' partitions:
filter (?(p) p: name: exists (?(c) c = '6')): get (0);
files changed in last 2 days := File System'files (partition 6):
filter (?(f) f: change time <= 2);
starts with (s, p: String) :=
s: length >= p: length AND s: take (p: length) = p;
contains (s, p: String) := NOT s: filter (
?(c, x) starts with (s: drop (x), p)): is empty;
IN
which mentioned string 2 := files changed in last 2 days:
filter (?(f) contains (f: lines, "<string2>"));
END;

Traversal of partitions and directories is performed lazily. Thus,
searching starts immediately after the first partition and contained
file has been found.

Post by Unknown
How does trankvila handle the type-matching between pipe-stages,

As with every strongly-typed programming language, one has to provide
input arguments with correct types--explicit conversion may be required.

Post by Unknown
and currying ...?

No currying in Trankvila...

And now, finally, some Oberon related content:

I once wrote a Module "Batch", which was intended to allow some
automation of tasks in the Oberon System. E.g., one could write
something like:

Batch.Call Edit.Store *; Compiler.compile *

Writing Oberon source code to store a marked viewer and invoke the
compiler would have been a lot more work. So, I guess, even in the
Oberon System a simple, built-in "shell script" language would be useful.

Richard

[n***@gmail.com]

-- s n i p --

Post by Richard

Post by W***@gmail.com
Having <multiple word identifier tokens> is disasterous!

Why do you think so? Using upper-case keywords makes this possible with
little danger of naming conflicts.
Richard

======
My system crashed, when I tried to accomodate some Micro$loth-based
testing. This one is tied together with string & elastic-bands.
USEnet is problematic, with Ngroups > 80K!
So let's see if little LEO can post this?
What can I say to this thread?
"In the heirarchy of 'no-nos', perhaps the highest is
'don't mess with we-write-from-left-to-right'
only slightly lower down is:
'white-spaces DEFINITELY separate tokens'.
----
RE. HCI: my analysis of why ETHO is for me, the last
resort <heavy artillary> for the most difficult problems:
is that the <immediate/easy coloring of texts> adds an
extra dimension of comprehension.

Apart from coloring, wily [plan9 based, copied from ETHO]
is more convenient for me. But for the worst problems
ETHO is my medicine.

[c***@gmail.com]

Post by n***@gmail.com
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.

Procedure types had already been introduced many years earlier in Modula-2. Oberon always had them - they weren't an extension. Even original Pascal in the early 1970's allowed you to pass Procedures as parameters:

Quoting from Modula-2 and Oberon by Niklaus Wirth:

"An uncontroversial, fairly straightforward, and most essential innovation was the procedure type, also adopted from Mesa. In a restricted form it had been present also in Pascal, even ALGOL, namely in the form of parametric procedures. Hence, the concept needed only to be generalized, i.e. made applicable to parameters and variables. In respect to Pascal (and ALGOL), the mistake of incomplete parameter specification was amended, making the use
of procedure types type-safe. This is an apparently minor, but in reality most essential point, because a type-consistency checking system is worthless if it contains loopholes."

[c***@gmail.com]

Post by n***@gmail.com
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.

ETHO was not 'extended' to handle procedure types - Oberon had them right from the start. Procedure types were introduced about 10 years earlier in Modula-2. Even original Pascal in the early 1970's allowed you to pass procedures as parameters. Refer to the following extract from the paper by Niklaus Wirth titled "Modula-2 and Oberon".

"An uncontroversial, fairly straightforward, and most essential innovation was the procedure type, also adopted from Mesa. In a restricted form it had been present also in Pascal, even ALGOL, namely in the form of parametric procedures. Hence, the concept needed only to be generalized, i.e. made applicable to parameters and variables. In respect to Pascal (and ALGOL), the mistake of incomplete parameter specification was amended, making the use of procedure types type-safe. This is an apparently minor, but in reality most essential point, because a type-consistency checking system is worthless if it contains loopholes."

Chris Burrows
CFB Software
http://www.cfbsoftware.com/modula2

[y***@z505.com]

Post by n***@gmail.com
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.

Not a fad, Haha.. are you sure about that...

Read Wirth's Through The Looking Glass Article... I believe someone else also mentioned it and it's called Bad Ideas or Ironically Good Ideas... I'm too lazy to look it up right now myself, but I've read it more than once. And he has some other articles on the subject too. In his articles he mentions that OOP is actually better suited for Parallelization and multiple CPU's if I remember correctly, due to OOP having PRIVATE sections (similar to less side effects). Objects are considered Live Modules or Modules at runtime, by wirth. I.e. modules are static and compile time whereas objects are modules at run time.

Well, you're cross posting to two mailing lists/groups, I've replied to you on the oberon list too.. I don't like replying multiple places, but I guess it has to be done.

Essentially OOP is just extending the type system further than before,
whereas a lot of pathetic OOP languages use snake oil terms like "class"
in place of type. An object is an instance of a class. Hmm. Why not an
instance of a type?

Why is it even an object and not just a struct? a struct or record, is an
instance of a type. Now we have no OOP, just advanced structured
programming...

Wirth seems to think OOP solves the parallelization problem better than
functional programming if you check his articles. Through the looking
glass might be the one, or there are others. I am simply too lazy to link
to them and not feeling like searching for it.

Post by n***@gmail.com
The big advantage of this functioal/compositional style is the
maintainablity.

Prove this using science. Not vague handwaving.

i.e. where is the science in computing science? there is none. It's just a bunch of "he said, she said" programmers pretending to be experts on subjects. Not talking about you specifically, but all programmers on "teh internets".

Lisp is an example of a joke that no programmer understands, except myself. The joke is that Lisp is a procedural imperative language, being fraudulently sold as functional, with strange syntax. Nail clippings mixed with oatmeal, with full imperative and procedural ability, defrauding people as "functional" since the early 1800's when it was invented. Or was it 1960's when the A.I. lab released the movie World on A Wire and the Thirteenth Floor, I can't remember. Certainly A.I. uses procedures to have side effects... it's called thinking... yes... Thinking brains are FULL of side effects. Functional my ass.

[Richard]

Post by y***@z505.com

Post by n***@gmail.com
The big advantage of this functioal/compositional style is the
maintainablity.

Prove this using science. Not vague handwaving.

There is definitely an advantage in having as much side-effect-free code
as possible: you can look at a function and be sure that it will return
the same result each time it is called with the same arguments.

Post by y***@z505.com
i.e. where is the science in computing science? there is none. It's

Yep, it's not a science. That's why we have to resort to logical
thinking. ;)

Richard

[Unknown]

Post by Richard

Post by y***@z505.com

Post by n***@gmail.com
The big advantage of this functioal/compositional style is the
maintainablity.

Prove this using science. Not vague handwaving.

There is definitely an advantage in having as much side-effect-free code
as possible: you can look at a function and be sure that it will return
the same result each time it is called with the same arguments.

Post by y***@z505.com
i.e. where is the science in computing science? there is none. It's

Yep, it's not a science. That's why we have to resort to logical
thinking. ;)
Richard

The example that recently most impressed me, that I cited on ETHO's
mail-list is: the easy maintainability of a potentially disasterous
situation. Recently there's a fad of replacing the single-quote-char
by 3-bytes. So that when I TextToSpeech my InetFetches to my mobile
to listen to at night; instead of hearing "can't"
I hear "sea aye enn tea".

Imagine the complexity of the function-chain:
GetOriginalTextFile | FilterOut eg. "["{digit}"}" |
TextToSpeech.wav | To.mp3 (using fileName selected at start)

To remove the [what I named the apostrophe-virus] just needed a
one-line command [*nix translate the 3-bytes to Char(apostrophe) ]
==========
This whole debate re. functional [ambiguously defined] vs.procedural
needs to be judged from a cognition/psychology point of view.
Computing is no longer about computers. It's about human cognition.

Coming from hardware [like NW] where you know the workings from the
transistors, bistables, registers, machine-code ...up to OberonSource,
it's very uncomforable to try eg. Haskell, when you don't know the
mechanism of how the results are achieved, and worse still you realise
that the ballet-dancing-Haskellers don't know either.

But then how many people understand the underlying mechanism of how
pushing some buttons connects their phone calls.

[Richard]

Post by Unknown
Coming from hardware [like NW] where you know the workings from the
transistors, bistables, registers, machine-code ...up to
OberonSource, it's very uncomforable to try eg. Haskell, when you
don't know the mechanism of how the results are achieved, and worse
still you realise that the ballet-dancing-Haskellers don't know
either.

I think, there does not have to be a conflict between a declarative
("purely functional") style of programming and knowing what is actually
happening on the machine.

Dijkstra, if I understand his writings correctly, proposed that we first
make sure a program would work correctly when executed on the "Good
Lord's Machine (GLM)", an imaginary device with unlimited speed, memory,
precision, and reliability. Then, if necessary, we can still adapt the
program to the limitations of real devices.

Thus, we could first write a program in a pure functional programming
language without thinking about memory usage etc., and then, using
knowledge about implementation mechanisms like tail recursion and lazy
evaluation, modify it to run reliably with limited hardware resources.

Richard

[y***@z505.com]

Post by Richard
Thus, we could first write a program in a pure functional programming
language

There is no such thing as a pure functional programming language. A functional programming language is not a falsifiable, nor is a pure language falsifiable. The term pure functional programming language is equivalent to saying "how pure is a dog's doodoo". It's not something that is pure nor will it ever be. Because computers, have side effects, like a casio calculator.

What makes a functional language Pure or not, is like asking a Christian what the true version of Christ or Christianity is. Each catholic/protestant/jehovah will disagree and come up with his own, unfalsifiable, unscientific, unmathematic version of b.s.

[y***@z505.com]

Post by Unknown
try eg. Haskell, when you don't know the
mechanism of how the results are achieved, and worse still you realise
that the ballet-dancing-Haskellers don't know either.
But then how many people understand the underlying mechanism of how
pushing some buttons connects their phone calls.

This is the type of people Edsgar Dikstra warned us about. Engineers programming computers who don't really know what it is they are doing, and allowing other hackers to come along and contribute too, who also don't know what they are doing. Something like a really long Lisp program which no one understands, not even the Lisp program itself understands itself because it's gotten so obfuscated and full of DSL's.

Software engineering: programming, for those who can't.

[y***@z505.com]

Post by Richard
There is definitely an advantage in having as much side-effect-free code
as possible: you can look at a function and be sure that it will return
the same result each time it is called with the same arguments.

Ever hear of CONST params in fpc (freepascal) which are read only paramters.

The most side effect free code, is a program that doesn't do anything at all. Kind of like a castrated bull that doesn't have the ability to impregnate a cow. A useless bull, to say the least.

Try writing a video game with as much side effect free code as possible. Video game sales are up lately! The latest video game does nothing, and costs $0.00. It's coded in, side effects reduced language called "castration".

[c***@gmail.com]

Post by y***@z505.com
Ever hear of CONST params in fpc (freepascal) which are read only paramters.

CONST parameters were also in the initial version of Oberon-07 (2007) but were removed again a few years later.

[y***@z505.com]

Post by y***@z505.com
Ever hear of CONST params in fpc (freepascal) which are read only paramters.

CONST parameters were also in the initial version of Oberon-07 (2007)]\
but were removed again a few years later.

Interesting, thanks for this history.

Were they removed because of extra compiler complexity?

The only thing that bothers me about CONST params is that they make the code more verbose and longer to read... a procedure list quickly becomes very long and bloated:

PROCEDURE DoSomething(CONST param1: string; CONST param2: integer;)

Versus the much simpler:
PROCEDURE DoSomething(param1: string; param2: integer;)

The CONST words take up a lot of space and bloat up the parameter declarations.

In GoLang they don't have "var" paramaters because you just use pointers, instead. same with plain C

[c***@gmail.com]

Post by y***@z505.com
Were they removed because of extra compiler complexity?

No - the additional compiler complexity was insignificant. At the same time they were removed the following rule (which does not require the use of the CONST keyword) was introduced:

"If a value parameter is structured (of array or record type), no assignment to it or to its elements are permitted."