January 2016 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Concurrency support in Oberon
by John R. Strohm 25 Jan '16

25 Jan '16

--- Lars (noreply(a)z505.com) wrote: > Same goes for implementing Strings of arbitrary > length.. String is not a type. At best, it is an abstract data type, a set of operations (or methods) that operate on instances of that type and yield results of other (potentially abstract) data types. The "reasonable" implementation of a fixed-length immutable short string is very different from the "reasonable" implementation of a potentially long variable-length mutable string. The moment you start talking about inserting into or deleting from the middle a string, you have a nightmare on your hands, unless your mutable string was designed with those capabilities in mind. At the same time, if you don't need those capabilities, there is no reason whatsoever for your String type to carry that extra baggage.

1 0

(no subject)
by None 25 Jan '16

25 Jan '16

1 0

Re: [Oberon] Concurrency support in Oberon
by John R. Strohm 25 Jan '16

25 Jan '16

--- Lars (noreply(a)z505.com) wrote: Jörg wrote: >> Hi >> >> >> >> >> If you think of Co-routines, this is not part of the Oberon language per >> se, >> >> but this functionality can be added by a "MODULE Coroutines". >> > > How can someone add a module that is partially a language feature? i.e. > golang has goroutines, which are a language feature... how can oberon > possibly allow concurrent programming without some of it being built into > the language itself? Same goes for implementing Strings of arbitrary > length.. As I understand it, Knuth vol. I describes coroutines as paired subroutines that are ping-ponged back and forth by a coroutine linkage module. As for concurrency: If the processor is a standard single-thread processor, as the VAST majority are, then it still executes one thread of control at a time (although instructions may be overlapped) and concurrency is simulated, not "true". At that point, you CAN do concurrency in a language, or you can do it in libraries. C, for example, has no explicit concurrency support (except for the "volatile" keyword), and C is routinely used in multitasking, multithreaded systems. See for example VxWorks.

1 0

Concurrency support in Oberon
by Srinivas Nayak 25 Jan '16

25 Jan '16

Dear All, We had Pascal, We came to its successor Modula-2. Then we came to its successor Oberon. But do we still have the concurrency programming support in Oberon, which was present in Modula-2? With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

6 6

Re: [Oberon] Oberon Digest, Vol 140, Issue 4
by Søren Renner 25 Jan '16

25 Jan '16

> > You've been sold a lie by the religious cult known as functional > programmers. "Lars O" is completely right. Disclaimer: I haven't actually learned Haskell. But he's right. On Mon, Jan 11, 2016 at 11:00 AM, <oberon-request(a)lists.inf.ethz.ch> wrote: > Send Oberon mailing list submissions to > oberon(a)lists.inf.ethz.ch > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.inf.ethz.ch/mailman/listinfo/oberon > or, via email, send a message with subject or body 'help' to > oberon-request(a)lists.inf.ethz.ch > > You can reach the person managing the list at > oberon-owner(a)lists.inf.ethz.ch > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Oberon digest..." > > > Today's Topics: > > 1. Running a video in Oberon. (Srinivas Nayak) > 2. Re: Functional programming style for Oberon? (Lars O) > 3. Re: Functional programming style for Oberon? (Lars O) > 4. Re: Numerical CASE Statements in Project Oberon (Lars O) > 5. Re: Project Oberon for Mac (Lars O) > 6. Re: Numerical CASE Statements in Project Oberon (Bob Walkden) > 7. Re: Numerical CASE Statements in Project Oberon > (Douglas G. Danforth) > 8. (no subject) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 10 Jan 2016 21:56:52 +0530 > From: Srinivas Nayak <sinu.nayak2001(a)gmail.com> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: [Oberon] Running a video in Oberon. > Message-ID: <5692864C.9060406(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Dear All, > > After a long time of acquaintance with Oberon, last week I finalized to > read the Oberon Trilogy. > Though I got to see many good ideas implemented in Oberon, I surprise, if > one can run a video in it. > Is running a video or running two videos simultaneously possible in Oberon? > > By Oberon, I mean the version which is described by Oberon Trilogy. > > > With thanks and best regards, > > Yours sincerely, > Srinivas Nayak > > Home: http://www.mathmeth.com/sn/ > Blog: http://srinivas-nayak.blogspot.in/ > > > ------------------------------ > > Message: 2 > Date: Mon, 11 Jan 2016 03:24:26 -0600 > From: "Lars O" <noreply(a)z505.com> > To: "ETH Oberon and related systems" <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Functional programming style for Oberon? > Message-ID: > <b58f51b23b8627910b518b1e08766b6c.squirrel(a)gator3286.hostgator.com > > > Content-Type: text/plain;charset=iso-8859-1 > > eas lab 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. > > > > You might want to read Wirth more... Wirth has articles such as Through > the Looking Glass.... and he seems to think Functional programming is a > fad, but that OOP has something to offer us.... > > Which is why his languages have OOP in them or advanced structured > programming. > > 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. > > > ------------------------------ > > Message: 3 > Date: Mon, 11 Jan 2016 03:33:17 -0600 > From: "Lars O" <noreply(a)z505.com> > To: "ETH Oberon and related systems" <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Functional programming style for Oberon? > Message-ID: > <5a7e66d1ef7738d335b184b10b0ddf03.squirrel(a)gator3286.hostgator.com > > > Content-Type: text/plain;charset=iso-8859-1 > > eas lab wrote: > > "functional programming" is very different from our "imperative > > programming". > > > > You've been sold a lie by the religious cult known as functional > programmers. It's not that different at all really. What ends up happening > is all sorts of side effects are required for the functional program to > actually do something useful, i.e. haskell Monads.... There is NO > scientific proof whatsoever that ramming a bunch of side effects into > monads makes it better than having the side effects like "writeln()" right > there in a pascal program or cout() in a c program. > > At some point you have to deal with side effects sooner or later and > delaying it until the last minute so that your program does absolutely > nothing until it hits the "monads" section is kind of like shoving all > your code into one long procedure that does anything useful, and putting > all the code that doesn't do anything into other procedures elsehwere. > SHOW me the science, and the studies done that prove this code is more > reliable, less bug prone, etc. Then there is the parallelization hype.... > But GoLang has goroutines for that, is GoLang functional? > > Show me the science and the studies done. Functional programmers are > guilty of religious cult propaganda. Join our cult because we know more > than all the other cults out there! trust our bible over at Haskell Wiki > because it's God's word! Oh really? Show me the SCIENCE. Ask Dijkstra, he > said something along the lines of "massaging all your code" is what > functional programming is. > > Also, is the relational model, functional? If you end up actually updating > your database with anything useful, you've got a side effect. Without side > effects you are castrated, like a cow that has his balls cut off. > > Wise GoLang programmer said "I used a functional programming language that > was doubly functional. Doubly in the fact that it actually did something." > > Lisp is jokingly a procedural language being fraudulently sold as > functional. > > > ------------------------------ > > Message: 4 > Date: Mon, 11 Jan 2016 03:53:53 -0600 > From: "Lars O" <noreply(a)z505.com> > To: "ETH Oberon and related systems" <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Numerical CASE Statements in Project Oberon > Message-ID: > <272ca1c552f748c7240c61e67d006524.squirrel(a)gator3286.hostgator.com > > > Content-Type: text/plain;charset=iso-8859-1 > > Jan de Kruyf wrote: > > Good morning David, > > > > > >> or perhaps he hasn't made a final determination on CASE. > > > > I like to believe that too. > > Ultimately the proof of the pudding is in the eating. Things have changed > > before in Oberon. Sometimes on good scientific grounds, sometimes on the > > basis of practical deliberations. > > > > What Wirth always _has_ argued against is needless inflation of the > > language just because of 'feature fever'. And I agree wholeheartedly with > > that sentiment. > > > > At the same time of course we are slowly getting to the point where we > > need to carry the idea forward ourselves. > > > Or how about communication? i.e. why doesn't Wirth participate in > developer discussions regarding languages? I think we are stuck in the > 1970's where one programmer writes a compiler and has zero feedback from > its users, because the God programmers knows better than all his users. > This is one area where languages like GoLang are better off - their lead > developers actually participate in discussions, criticisms, ... they > actually COMMUNICATE with each other. Wow. They communicate, like people. > Is wirth an alien? > > > ------------------------------ > > Message: 5 > Date: Mon, 11 Jan 2016 04:19:05 -0600 > From: "Lars O" <noreply(a)z505.com> > To: "ETH Oberon and related systems" <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Project Oberon for Mac > Message-ID: > <de020601ece78ed4eb61da3712c1f42e.squirrel(a)gator3286.hostgator.com > > > Content-Type: text/plain;charset=iso-8859-1 > > R. P. de Jong wrote: > > Hi All, > > > > > > I would like to inform you that a new "Project Oberon, Revised Edition > > 2013" product has just been released. It is aimed to make Oberon > > available for Mac owners who don???t want to tinker or boot into Windows > > to get it running, like myself. > > > You may want to clarify whether you mean Mac, as in the old mac or the new > macosx. The old macs were based on pascal, whereas the new macosx is > objectivec based and bsd based, and such. The old macs were pascal systems > that people didn't really know about, well possibly assembly based too. > I'm not an expert on Macs, though, just spreading typical mac rumors... as > it's all closed source anyway, so no one truly knows. > > > ------------------------------ > > Message: 6 > Date: Mon, 11 Jan 2016 10:21:03 +0000 > From: Bob Walkden <bob(a)web-options.com> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Numerical CASE Statements in Project Oberon > Message-ID: <SNT406-EAS126E212E02429A7113E5B56F7C90(a)phx.gbl> > Content-Type: text/plain; charset="us-ascii" > > On 11 Jan 2016, at 09:54, Lars O <noreply(a)z505.com> wrote: > > > > [...] > > > > Or how about communication? i.e. why doesn't Wirth participate in > > developer discussions regarding languages? I think we are stuck in the > > 1970's where one programmer writes a compiler and has zero feedback from > > its users, because the God programmers knows better than all his users. > > This is one area where languages like GoLang are better off - their lead > > developers actually participate in discussions, criticisms, ... they > > actually COMMUNICATE with each other. Wow. They communicate, like people. > > Is wirth an alien? > > > > He's a teacher, and obviously a good one. That is one of the most > effective forms of communication. Almost all of his work seems to have been > done in collaboration with others. > > I was never his student, but his books are among the best computer science > writing that I know of, and have been immeasurably useful in my own > computing education. The clarity of his writing is quite extraordinary by > any standards; more so when compared with most CS literature. > > He is one of the very best communicators I know of. > > B > > ------------------------------ > > Message: 7 > Date: Mon, 11 Jan 2016 02:44:12 -0800 > From: "Douglas G. Danforth" <danforth(a)greenwoodfarm.com> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] Numerical CASE Statements in Project Oberon > Message-ID: <5693877C.9040302(a)greenwoodfarm.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > I first met Niklaus Wirth when he team taught a course in Algol-60 at > Stanford > in 1965 (yup, way back then). That was my first computer science course. > -Doug Danforth > > > On 1/11/2016 2:21 AM, Bob Walkden wrote: > > On 11 Jan 2016, at 09:54, Lars O <noreply(a)z505.com> wrote: > >> [...] > >> > >> Or how about communication? i.e. why doesn't Wirth participate in > >> developer discussions regarding languages? I think we are stuck in the > >> 1970's where one programmer writes a compiler and has zero feedback from > >> its users, because the God programmers knows better than all his users. > >> This is one area where languages like GoLang are better off - their lead > >> developers actually participate in discussions, criticisms, ... they > >> actually COMMUNICATE with each other. Wow. They communicate, like > people. > >> Is wirth an alien? > >> > > He's a teacher, and obviously a good one. That is one of the most > effective forms of communication. Almost all of his work seems to have been > done in collaboration with others. > > > > I was never his student, but his books are among the best computer > science writing that I know of, and have been immeasurably useful in my own > computing education. The clarity of his writing is quite extraordinary by > any standards; more so when compared with most CS literature. > > > > He is one of the very best communicators I know of. > > > > B > > -- > > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > > > > ------------------------------ > > Message: 8 > Date: Mon, 11 Jan 2016 10:40:13 +0000 (added by postmaster(a)bluewin.ch) > Subject: [Oberon] (no subject) > Message-ID: <563B739603D13119(a)zhhdzmsp-smta14.bluewin.ch> (added by > postmaster(a)bluewin.ch) > > > > ------------------------------ > > Subject: Digest Footer > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > ------------------------------ > > End of Oberon Digest, Vol 140, Issue 4 > ************************************** >

2 1

Jupiter and Saturn. Oberon, Miranda and Titania. Neptune, Titan and so on
by Bob Walkden 25 Jan '16

25 Jan '16

A timely reminder of how Oberon got its name: http://www.nasa.gov/feature/jpl/voyager-mission-celebrates-30-years-since-u… And a catchy little number from a popular beat combo which helps me remember the names of some of the other moons: https://m.youtube.com/watch?v=arXEDRZHyvg B

2 1

Pepino, a new FPGA board for Oberon RISC
by Magnus Karlsson 22 Jan '16

22 Jan '16

Dear Oberoners, I'd like to announce Pepino, an entry-level FPGA development board based on Xilinx Spartan-6 FPGA, by Saanlima Electronics. The board is specifically designed to run the FPGA-based 32-bit RISC computer which is described in the 2013 edition of Project Oberon by Niklaus Wirth and Juerg Gutknecht, including 32-bit wide fast SRAM that typically don't exist on other FPGA development boards. Other features includes a large flash memory chip (16 MB) that can be used to hold several sets of configuration bitfiles (multi-boot) or any type of user data like programs, images etc., and an on-board USB-to-serial converter that makes it simple to connect to board to a computer. The board also have a built-in JTAG programmer and is recognized and supported by Xilinx development tools (iMPACT, ChipScope, SDK etc.) as well as several third-party JTAG programming software tools without the need for an external (and expensive) JTAG programmer. The board is shipped with Oberon RISC bitfile installed in flash and is ready to boot from an sd-card with an Oberon image (sd-card not included). The cost of the board starts at $99.95 for the LX9/1MB version and is available in the Saanlima store (http://saanlima.com/) See the links below for details. http://pepino.saanlima.com/ http://projectoberon.com/ http://www.inf.ethz.ch/personal/wirth/ Cheers, Magnus Karlsson Saanlima Electronics www.saanlima.com

1 0

OS X and Oberon
by David Egan Evans 22 Jan '16

22 Jan '16

Are there OS X users (e.g. Yosemite, El Capitan) of Oberon systems out there? If so, what do you use? A2? Is there anyone using ETH Oberon? Blackbox? Specifically, I'm looking for Oberon as an IDDEE. From what I can tell, A2 is the only system I can see that ever had OS X support on modern (Intel64) Macs. PS Has anyone successfully compiled Peter's RISC emulator on OS X? -- http://oberon07.com

14 24

Re: [Oberon] Oberon-2 and Oberon-7
by John R. Strohm 21 Jan '16

21 Jan '16

It is my understanding that Oberon-7 and Oberon-2 are significantly different languages. Oberon-2 added typebound procedures. Oberon-7 cleaned up a few rough spots, the biggest one being the RETURN statement for typed procedures (functions). --- sinu.nayak2001(a)gmail.com wrote: From: Srinivas Nayak <sinu.nayak2001(a)gmail.com> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: [Oberon] Oberon-2 and Oberon-7 Date: Thu, 21 Jan 2016 20:41:52 +0530 Dear All, When we have Oberon-7, do one still need to look at Oberon-7? From the discussions, I see, Oberon-2 is still alive. Didn't we(including NW) conclude Oberon-7 from our experiments with Oberon and Oberon-2? With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/ -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Oberon-2 and Oberon-7
by Srinivas Nayak 21 Jan '16

21 Jan '16

Dear All, When we have Oberon-7, do one still need to look at Oberon-7? From the discussions, I see, Oberon-2 is still alive. Didn't we(including NW) conclude Oberon-7 from our experiments with Oberon and Oberon-2? With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

2 1