On 12/14/2016 11:17 PM, Srinivas Nayak wrote:

...

These days I see, every programming language is behind functional programming! Say, C++ or Java or C# or Javascript... recent trend is the old fashion! The fashion of Lambda and Closure! How far is Oberon from functional programming?

Surprisingly we already have all the necessary stuffs in Oberon: 1. nested procedures 2. procedure variable 3. scoping of procedure local variables etc.

But as Niklaus Wirth put in one of his articles (Through the Looking Glass? Or another article he wrote)... "Why?" You can do functional programming in any language if you try hard enough.... You can nest functions in functions in functions and pass things in with pointers to emulate functional programming, but the question is why? I always find "dumb programs" easier to understrand than clever tricks up sleeves. I've always found functional programming to be one gigantic clever trick, inside clever tricks... And I have always seen procedural programs to be these utterly dumb, boring, top to bottom programs that look like a cooking recipe. First set the oven to 350 degrees. Mix the flour with the baking soda. Add water. Put cake in oven. No clever tricks... just a set of simple instructions from top to bottom... Then you've got people claiming that MS LINQ project is somehow adding functional programming to our existing languages, but is it really? Relational <> functional. All relational databases are side effects machines. Every time you add any data to a database you have side effects of all sorts. Only when you do a read only view of the database are you doing side effects free programming. Now, I suppose if you aren't baking a cake with a set of simple instructions and you are doing some super complex mathematics to calculate something... maybe this is a use case for functional programming? I've always thought that Lisp was never a functional language at all but rather a procedural language with a strange syntax... After all, to print to stdout you have to do a print call in lisp, or something similar, which goes back to the "Bake the cake" style programming... As printing something to a screen is still a procedural imperative call, full side effect, ... I watched some youtube videos of a guy doing Game Programming in Haskell, and I kept asking the same question as Wirth did in his article. Why? What problem is actually being solved? Is it pure mental masturbation? On the other hand I'm still open minded enough, to find a use case for functional programming, if there is even such a thing as functional programming, because I have no idea what functional programming even is. I've researched functional programming on and off, for about 12 years now, and never truly had anyone explain properly what functional programming is. The side effects free claims are all bogus, because a hello world program has a side effect... I've narrowed it down to "isolating side effects as much as you can", but no one actually ever said this was what functional programming was until I said it myself... (i.e. I'm likely the only person who really came up with a definition of what functional programming is, because one one else could).

...

But only thing we need is: a way to preserve dynamic state of a procedure and unnamed procedures! What else?

You might need to make a function that has zero side effects, or rather isolated side effects like how Monads (rhymes with Gonads) works. Niklaus Wirth claimed, in his article, that Object Orientation was a better way in his opinion to isolate side effects by privatizing things instead of the old plain C public everything way of programming. I'm even skeptical of Wirth's claim that OOP is the answer to side effects isolation. So to answer the Monads (with your gonads) question, try writing a Component Pascal or oberon program that does not do anything at all with regards to printing to the screen, it just purely calculates something. Then, create a separate module that takes this calculation and then isolates it in such a way that it can print to screen. That's kind of what Monads are. But always ask yourself "why am I even doing this in the first place?". It's definitely an interesting academic exersize... or maybe it's just boring, I don't know. Functional programmers seem to think their programs are one gigantic calculation, and then you isolate that calculation from side effects, like GUI calls, Print screen calls, etc. That's certainly not what Lisp is since Lisp is riddled with side effects all over the place throughout its programs..... But Haskell Wheenies seem to think their program is a big Math problem being solved without any side effects, and then when you absolutely have to do something useful like print to a screen, you isolate it so it's less dangerous. Maybe it is like baking a cake in your head first, calculating what the cake will be baked like if it is at a certain temperature in the oven (but DO NOT turn on the oven as that is dangerous).... Then after you've done millions of calculations about the entire baking cake process (mental masturbating), finally at the end of all your calculations, figure out a way to turn on the oven with a fire extinguisher in hand. Heck, I just wrote a parody website of functional programming: this is an email, but I wrote an entire website article in my email above. Maybe I'll convert it and open up a parody domain name. But obviously functional programming has provided us some useful insights such as garbage collection, which came heavily from lisp. But IMO, lisp was never a true functional language, so even if we stole garbage collection from lisp, it really wasn't functional anyway, so you'd be stealing garbage collection from an imperative language with a weird syntax (IMO that's what lisp is).

Am 2016-12-15 um 12:11 schrieb Lars:

First set the oven to 350 degrees. Mix the flour with the baking soda. Add water. Put cake in oven.

No clever tricks... just a set of simple instructions from top to bottom...

Wouldn't it be better to just describe the result (declarative programming) instead of specifying the step-by-step creation process (imperative programming)? I find it actually easier to read a (well structured, pure) functional program than a procedural program: you do not have to go through all the steps in your head and remember previous state changes to understand what the end result will be; you just look at one declaration at a time independently. And, of course, because you avoid side effects, you do not actually bake the cake--you leave that to the environment. So you can have your cake and eat it too, without even cooking. ;)

I watched some youtube videos of a guy doing Game Programming in Haskell, and I kept asking the same question as Wirth did in his article. Why? What problem is actually being solved? Is it pure mental masturbation?

Advantages of Haskell compared to other programming languages are that programs tend to be very concise and the sophisticated type system catches many errors already at compile time. But IMO it's just too complicated for most programmers (including me). Richard

On 12/15/16, Richard Hable <informujo@aon.at> wrote:

- generics

Linked List [T] = RECORD head: T; tail: List [T] END;

Without generics (i.e. type parameters for functions, types, and values) it is not possible to define reusable persistent collections. We can't just build and manipulate aribitrary pointer structures.

Type extension is sufficient. A collection module can allow its client modules to allocate extensions of its own Entry record type, or it can operate on keys and/or values of type Objects.Object.

These days I see, every programming language is behind functional programming!

It seems that if a programming language doesn't introduce new features every X years, the language is obsolete and not worthy of consideration. It's the modern trend to add functional features to imperative programming languages, a trend that I would never follow.

How far is Oberon from functional programming? [...] But only thing we need is: a way to preserve dynamic state of a procedure and unnamed procedures!

Why do you want these functional features? Mixing the two increases language complexity and redundancy, basically you have two constructs to solve the same problem: 1) A closure that is a function which operates on his own (dynamic) lexical scoping (that is a record); and 2) A method that is a procedure which operates on his associated object (that is also a record). If you look closely they are very similar (if not the same).

I got interested towards functional programming, reading that it favors concurrency and avoidance of mutation is the future...

In imperative languages it is a good practice to offer an immutable representation of a data structure. It's not that big effort. -- Diego Sardina

https://pdfs.semanticscholar.org/10bd/dc49b85196aaa6715dd46843d9dcffa38358.p... Chapter 6.1 Jörg Am 16.12.2016 um 08:51 schrieb Chris Burrows <chris@cfbsoftware.com>:

...

-----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Srinivas Nayak Sent: Friday, 16 December 2016 4:36 PM To: ETH Oberon and related systems Subject: Re: [Oberon] Functional programming and Oberon

I got interested towards functional programming, reading that it favors concurrency and avoidance of mutation is the future...

What is the reality?

I haven't seen much regarding this from Dijkstra, Wirth, Hoare and their friends... So what are language master's thoughts on this?

Wirth writes about Functional Programming on pages 66-67 of the paper that Lars mentioned recently:

"Good Ideas, through the Looking Glass", IEEE Computer, Jan. 2006.

Regards, Chris Burrows

CFB Software http://www.astrobe.com

-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

Chris wrote:

Wirth writes about Functional Programming on pages 66-67 of the paper that Lars mentioned recently:

"Good Ideas, through the Looking Glass", IEEE Computer, Jan. 2006.

Since IEEE may be only accessible to the members, I looked up the web: pdfs.semanticscholar.org/10bd/dc49b85196aaa6715dd46843d9dcffa38358.pdf Regards, Wojtek ________________________________________

On 12/17/2016 5:35 AM, Richard Hable wrote:

There is no generic Object type in Oberon (and Trankvila); for good reasons! Using such a "garbage" type takes away the advantages of static typing.

And in both solutions a lot of type casts at runtime would be necessary. A quick skim of what you wrote seemed reasonable. But then on a closer look I ask "what is a static type?" Something is either a type or its not. There is no concept of "static" or "dynamic" associated with "TYPE". Instances of a type can indeed be static or dynamic but the "TYPE" is not. What "advantage" do you mean by "static typing?" Your comments make no sense.

-- Danforth of the Greenwood

Please note. This is an email list devoted to Oberon. Not about languages in general. On 12/28/2016 2:09 PM, Richard Hable wrote:

dynamic typing

-- Danforth of the Greenwood

On Wed, December 28, 2016 3:09 pm, Richard Hable wrote:

Am 2016-12-18 um 02:53 schrieb Douglas G Danforth:

...

What "advantage" do you mean by "static typing?" Your comments make no sense.

Static typing means that the type of a variable is known at compile time. Thus, the compiler can make sure that only values suitable for the declared type are assigend to it.

Otherwise, with dynamic typing (using variables with no declared type or a generic type like "Object"), the compiler accepts assignments of arbitrary types, and thus typing errors can only be recognized at runtime.

An object can be statically typed.... And should be.. Do you mean an object that is empty without any fields in some bizarre language? or an object with a bunch of untyped fields, maybe ruby?

Well, one can always create a TYPE Object and then descend many other types from that. I do that in a module called Objects which exports a type Object. I then build generic lists, sets, stacks, queues based on Object as well as Reals, Ints, Bools, ... which are specific instances of an Object. All of that works well. But one is not forced to do that by the language. Its up to the programmer. -Doug Danforth On 1/7/2017 11:33 AM, Richard Hable wrote:

Am 2017-01-06 um 17:24 schrieb Lars:

...

Do you mean an object that is empty without any fields in some bizarre language? or an object with a bunch of untyped fields, maybe ruby? No, I mean a predefined type "Object" which is the implicit base type of all declared classes; e.g. in the Java programming language (java.lang.Object).

It was proposed as an alternative to generics (type parameters) in this list and apparently has been introduced in at least one extension of the Oberon programming language.

Richard

-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

-- Danforth of the Greenwood

Ph.D wrote:-

The Component Pascal Language Report mentions ANYPTR and ANYREC as predefined identifiers. There is also a procedure PROCEDURE (a: ANYPTR) >FINALIZE-, NEW, EMPTY;

What is the context of the above twat. Are you all writing from your twitter devices these days? Query to M$ users: is it really possible that I can't compose mails on out$pook while my inet connection is out of order? == Chris Glur. PS. OK out$pook becomes available; but then can't access other apps to get texts. Terrible punishment when coming from *nix to M$. How/why do you tolerate this garbage?

On Wed, January 25, 2017 12:24 am, eas lab wrote:

PS. OK out$pook becomes available; but then can't access other apps to get texts. Terrible punishment when coming from *nix to M$. How/why do you tolerate this garbage?

Or more importantly, why do you, Chris Glur, tolerate it? If MS Win so bad, why not just use Loonix for loonies, or bsd, or, Solaris, or... oberon natively on a oberon station or one of those USB oberon stations (can't remember the name) for $100

I believe I started this thread about <functional> programming & ETHO; because it's power/econony-of-effort has become [ever more] evident to me. The thread has morphed into multiple/confusing concepts and terminology. "Piping" seems to capture the best cost-benefit aspect, which ETHO already uses. Ie. <piping> is only one aspect of FP; but seems to offer great productivety gains and is already acknowledged by usage, although never AFAIK explicitly stated in ETHO's documents. When they ask you Q: "how do you compile with oberon?", you just tell them A: "we klik on Compiler.Compile ^ or Compiler.Compile *" Q: "But that's got no parameter" A: "We don't like 50N-char-ErrorProne parameters. We prefer to use the FP concept [and acknowledged as such eg. in ML] of 'it'. So both 'Compiler.Compile ^' and 'Compiler.Compile *' mean 'compile it'. Similarly the output of each stage of piping/FP is simply "it". With our existing system, the output is often a new TextFrame, which via "*" [as "it"] becomes the input to the next stage. Someone here already mentioned the <rough scripting facility> which we already have; which closely relates to the ability to write multi-stage piping scripts.

The whole dynamic typing joke started in language came before Lisp that lisp copied and stole from.

Don't forget Wirth's Euler. ;)