[Oberon] Oberon Digest, Vol 160, Issue 26
Michael McGaw
mcgawma at yahoo.com
Sat Sep 30 15:12:29 CEST 2017
I have found this thread of discussion to be immensely interesting, as I use Oberon to do embedded work for much of what I do. I have focused on the well sorted OP2 compiler for much of this, and also use M2 (programmed in an Oberon-like subset) for many things.
The changes being discussed (and those that have already been made) in PO, or 07 (e.g., any follow-on dialect to Oberon that is post OP-2 in this millennium) are in many cases welcome, as they clarify and simplify.
But they do confound. The confound our previous thinking and experience in language use (remember, there are practitioners lurking in this list who rely on a high degree of familiarity and experience with a given language definition and its implementation to ensure reliable work products).
But perhaps most importantly, the changes are most dramatic in their impact on code bases. Many of the changes made in PO/07 are of the type that cannot be machine translated, in the sense of a source to source translator. They require the practitioner to perform code redesign in order to adopt the latest compilers. LOOP, RETURN fall into this category. The local procedure situation is another.
Then, there are the many more minor, but tedious to adopt changes of bit op functions and their names, and the like.
To adopt these later variants in Oberon is quite a task, if you must convert an existing, active code base to adopt the new language. And, this base works only until the *next* decision to simplify or streamline the language further.
Another reason I like OP2: it is more than capable, but more than this, it is static in its definition and predictable in its behavior. I can depend on what it does, and how it does it. Moreover, I can enforce that the compiler DOES NOT change, and avoid a compiler manufacturer's next release of its tool set, and the problems THAT engenders. This reason alone is enough to adopt (one of) the Oberon dialects being discussed in this list, and locking in on it.
I am not exercising a right of contrarianism, here; rather, I do very much appreciate the laser-like intensity and clarity with which Wirth has gone after these many details. It certainly makes the teaching of language design and implementation much more focused and on point. But practitioners, who build code bases and who must maintain the painfully worked-out, stable behaviors of these code bases most certainly DO NOT want to have to open them back up, and redesign (and then, worst of all, retest and confirm, on all platforms, in all environments, that the changes are stable and correct), with no other benefit than language compatibility. In other words, to be compelled to have to do work that adds no value to the functional performance of this code base. This is the bane of those who operate in the commercial realm. It is the main reason I maintain a close eye on these subsequent language developments, but also why I am extremely careful in committing a new project to these developments.
-M
On Saturday, September 30, 2017 6:00 AM, "oberon-request at lists.inf.ethz.ch" <oberon-request at lists.inf.ethz.ch> wrote:
Send Oberon mailing list submissions to
oberon at 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 at lists.inf.ethz.ch
You can reach the person managing the list at
oberon-owner at 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. Re: Procedure variables and local procedures (Skulski, Wojciech)
2. Re: Procedure variables and local procedures (Chris Burrows)
3. Re: Procedure variables and local procedures (Chris Burrows)
4. Re: Procedure variables and local procedures (Skulski, Wojciech)
5. Re: Procedure variables and local procedures (Skulski, Wojciech)
6. Re: Procedure variables and local procedures (J?rg)
7. Re: Procedure variables and local procedures (chris)
----------------------------------------------------------------------
Message: 1
Date: Sat, 30 Sep 2017 01:18:50 +0000
From: "Skulski, Wojciech" <skulski at pas.rochester.edu>
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Procedure variables and local procedures
Message-ID:
<DM5PR0701MB3672FBF0990DD0769421BE0FFF7F0 at DM5PR0701MB3672.namprd07.prod.outlook.com>
Content-Type: text/plain; charset="Windows-1252"
Joerg:
>Btw. another issue I see with Oberon-07 ist the removal of dynamic
> arrays. I cannot imagine how to write for example a string library or
> something like that without.
I do not know the string libs mentioned by Chris, but I used mathematical libs by Robert Campbell. I also wrote waveform data acquisition and corresponding graphics. All of these highly useful programs are based on something like the following, copied from my own code.
RArray* = POINTER TO ARRAY OF REAL;
IArray* = POINTER TO ARRAY OF INTEGER;
> Would you please explain ?dynamic arrays?? Do you miss the low level SYSTEM.NEW(p, n)?
I am guessing that Chris has the above in mind. I second his opinion: without the dynamic arrays (or "open arrays") the language is crippled.
> The modules handling dynamic structures (eg. text editor, network stack or files)
> do in principle use the same internal scheme: they use chains of blocks of fixed size.
Perhaps it works OK if one is developing a text editor. I still remember Turbo Editor Toolbox was using a similar approach.
Writing an algebra library using this method takes us back to FORTRAN. Here I second Chris. I too cannot imagine working in this area without dynamic arrays.
Perhaps you guys could have a look at monumental work done by Robert? This might provide some arguments against cutting off what you consider dead wood, which is in fact crucial for some applications.
Thanks,
Wojtek
------------------------------
Message: 2
Date: Sat, 30 Sep 2017 11:55:56 +0930
From: "Chris Burrows" <chris at cfbsoftware.com>
To: "'ETH Oberon and related systems'" <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Procedure variables and local procedures
Message-ID: <001801d33993$731ca830$5955f890$@cfbsoftware.com>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> chris
> Sent: Saturday, 30 September 2017 4:21 AM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Procedure variables and local procedures
>
>
> Very terse. How does it work in the reverse case.
>
> VAR b : BYTE; i : INTEGER;
> i := 1000; b := i;
>
> Does it trap for overflow?
>
chris,
The details of runtime traps are implementation-specific questions and do
not form part of the language design.
Runtime overflows (INTEGER as well as BYTE) are not trapped in Project
Oberon or Astrobe Oberon. In fact the Random function exploits this
behaviour and would break if ported to a system that didn't allow you to
turn off overflow trapping.
If you have no control over the values of the data that reach that point in
your code and you want to trap them (a more subtle scenario than your
example) you should write:
ASSERT(i <= 255);
b := i;
Chris (Burrows, that is - I'm not talking to myself ;-))
CFB Software
http://www.astrobe.com/RISC5
------------------------------
Message: 3
Date: Sat, 30 Sep 2017 12:12:52 +0930
From: "Chris Burrows" <chris at cfbsoftware.com>
To: "'ETH Oberon and related systems'" <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Procedure variables and local procedures
Message-ID: <001901d33995$d2dff7c0$789fe740$@cfbsoftware.com>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Skulski, Wojciech
> Sent: Saturday, 30 September 2017 10:49 AM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Procedure variables and local procedures
>
> Perhaps you guys could have a look at monumental work done by Robert?
> This might provide some arguments against cutting off what you
> consider dead wood, which is in fact crucial for some applications.
>
I would not dream of using a hammer to drive in a fence post any more than I
would choose a sledgehammer to drive in a nail. Similarly, computer
languages are just tools - no one tool is suitable for all jobs. The more
you try to make one toll suitable for a different job the less suitable it
is for use with the job is was designed to do e.g. a short-handled
sledgehammer or a long-handled hammer.
What's the point of making Oberon-07 like Component Pascal when you already
have Component Pascal?
I would not dream of trying to use a 'bloated' language like Component
Pascal to program a single-tasking application for a microcontroller with 16
KB of RAM. I would also not attempt to use a 'crippled' language like
Oberon-07 to write a multi-tasking, event-driven GUI program running on a
system with 16GB of RAM.
However, I do use the 'highly efficient' Oberon-07 to program
microcontrollers with 16 KB of RAM. I also use the 'extremely powerful'
Component Pascal to write GUI programs for a system with 16GB of RAM.
Regards,
Chris Burrows
CFB Software
http://www.astrobe.com
------------------------------
Message: 4
Date: Sat, 30 Sep 2017 02:56:30 +0000
From: "Skulski, Wojciech" <skulski at pas.rochester.edu>
To: "chris at cfbsoftware.com" <chris at cfbsoftware.com>, ETH Oberon and
related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Procedure variables and local procedures
Message-ID:
<DM5PR0701MB3672C300B9589480B3587BDBFF7F0 at DM5PR0701MB3672.namprd07.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
> I would not dream of trying to use a 'bloated' language like Component
> Pascal to program a single-tasking application for a microcontroller with 16
> KB of RAM. I would also not attempt to use a 'crippled' language like
> Oberon-07 to write a multi-tasking, event-driven GUI program running on a
> system with 16GB of RAM.
Chris:
this is a very interesting point. A few posts ago I implied that Oberon-07 looks like a microcontroller language. Frankly, I expected to get spanked. Now you are saying the same. Would ETH folks agree? Was Oberon not meant as a pinnacle of language design, capable of the most demanding tasks like writing compilers and operating systems? Will the authors feel offended by the word "microcontroller"?
So is Oberon-07 intended to be a frugal general purpose language, or was it meant to be a minimalistic microcontroller language? I can hold to my opinions, but what were the authors' intentions?
W
------------------------------
Message: 5
Date: Sat, 30 Sep 2017 03:07:10 +0000
From: "Skulski, Wojciech" <skulski at pas.rochester.edu>
To: "chris at cfbsoftware.com" <chris at cfbsoftware.com>, ETH Oberon and
related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Procedure variables and local procedures
Message-ID:
<DM5PR0701MB367228D88B23D3D5F90A6B9DFF7F0 at DM5PR0701MB3672.namprd07.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
> Runtime overflows (INTEGER as well as BYTE) are not trapped in Project
> Oberon or Astrobe Oberon. In fact the Random function exploits this
> behaviour and would break if ported to a system that didn't allow you to
> turn off overflow trapping.
Another good point! Overflowing is a crucial part of some digital filters in FPGAs. Without overflowing these filters would not work.
Another, slightly less exotic example is a circular buffer design whose pointer must overflow in order to make the buffer circular. I use this design pattern all over my FPGA firmware. In a computer language one can use an IF statement or a modulo operator, but in the FPGA there is hardly place for such embellishments. Most often I just let the upper bit fall off.
W.
------------------------------
Message: 6
Date: Sat, 30 Sep 2017 09:23:10 +0200
From: J?rg <joerg.straube at iaeth.ch>
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Procedure variables and local procedures
Message-ID: <66D4EA77-43ED-4830-BCAC-880D2F868A09 at iaeth.ch>
Content-Type: text/plain; charset=utf-8
Wojtek
> I am guessing that Chris has the above in mind. I second his opinion: without the dynamic arrays (or "open arrays") the language is crippled.
Oberon-07 has open arrays.
Open arrays are formal parameters whose length is not known at compile time.
Here an example in Oberon-07:
PROCEDURE Max(v: ARRAY OF REAL): REAL; (* ?v? is an open array *)
VAR i: INTEGER; max: REAL;
BEGIN
max := v[0];
FOR i := 1 TO LEN(v)-1 DO IF v[i]>max THEN max := v[i] END END
RETURN max END Max;
and use Max() with vectors of different lengths like
v1: ARRAY 10 OF REAL;
v2: ARRAY 88 OF REAL;
If you would like to write a library operating on two dimensional matrices, you can do so in Oberon-07. It is left as an exercise how to implement
MODULE Matrix;
TYPE
Matrix* = POINTER TO MatrixDesc;
MatrixDesc = RECORD
m*: PROCEDURE (i, j: INTEGER): REAL (* m(i, j) returns an elem of the matrix *)
END;
PROCEDURE Allocate*(m: Matrix; dim1, dim2: INTEGER);
PROCEDURE Initialize*(m: Matrix; f: Files.File);
PROCEDURE EigenValue*(m: Matrix): REAL;
END Matrix.
As all this is possible in Oberon-07, I was wondering what dynamic arrays are.
br
J?rg
------------------------------
Message: 7
Date: Sat, 30 Sep 2017 11:56:41 +0200
From: chris <chris at gcjd.org>
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Procedure variables and local procedures
Message-ID: <20170930115641240305.32164927 at gcjd.org>
Content-Type: text/plain; charset=iso-8859-13
On Sat, 30 Sep 2017 02:33:16 +0200, J?rg wrote:
>> VAR b : BYTE; i : INTEGER;
>> i := 1000; b := i;
>>
>> Does it trap for overflow?
>
> The compiler does not generate a trap. It moves the lowest byte of i
> to b. See first IF in ORG.Store.
Well, that is considered good style? In my opinion this kind of low
level action should not be in the base language. If it's defined to be
"least significant byte" that would be a bit better, but this could
result in some surprise on different hardware.
Leaving this undefined in the language report makes the type BYTE an
unusable feature for portable programs.
> Would you please explain ?dynamic arrays?? Do you miss the low level
> SYSTEM.NEW(p, n)?
I mean things like:
TYPE
CharPtr = POINTER TO ARRAY OF CHAR;
VAR
p : CharPtr;
BEGIN
NEW(p, 1234);
There is nothing low level here. That is a widely used feature in ETH
Oberon (System 3) or whatever you call it today. What is wrong with
this? Even if I had to write a string librarary for UTF8 I would use
this feature for the buffers internally and not linked list of fixed
(compile time determined) sized pieces.
Greeting, chris
------------------------------
Subject: Digest Footer
--
Oberon at 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 160, Issue 26
***************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170930/525ecd04/attachment.html>
More information about the Oberon
mailing list