List of extensions for Project Oberon compiler
Does anyone know if the language extensions that the Project Oberon compiler provides in relation to the Oberon report (from 2016) is documented somewhere? I'm thinking of features such as dynamic arrays and structural equivalence of arrays used in assignments. -- August
look at the source code🤣 Best docu you get.. Jörg
Am 31.01.2021 um 19:29 schrieb August Karlstrom <fusionfile@gmail.com>:
Does anyone know if the language extensions that the Project Oberon compiler provides in relation to the Oberon report (from 2016) is documented somewhere? I'm thinking of features such as dynamic arrays and structural equivalence of arrays used in assignments.
-- August -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of August Karlstrom Sent: Monday, 1 February 2021 4:59 AM To: ETH Oberon and related systems Subject: [Oberon] List of extensions for Project Oberon compiler
Does anyone know if the language extensions that the Project Oberon compiler provides in relation to the Oberon report (from 2016) is documented somewhere? I'm thinking of features such as dynamic arrays and structural equivalence of arrays used in assignments.
My understanding is that any language extensions that exist in the Project Oberon compiler are 'undocumented features' which means that you cannot rely on them to be supported or available in a future release or to exist in any other implementations of Oberon. Some might have originally have been candidates for inclusion in the Language Report but were rejected for some reason e.g. too implementation-dependent. The risk of describing them in print is that it bestows some sort of 'official' status on them which leads to unrealistic expectations and complaints if they do not appear in other implementations. Why do you ask the question? One of things on my possible 'list of things to do' is to produce a version of Project Oberon that is 100% compliant with the Language Report. I believe that is eminently feasible. If you have a similar ambition then I would be happy to collaborate with you. BTW I didn't think that dynamic arrays were implemented in the official Project Oberon compiler. Maybe we are thinking of something different. Can you provide a simple test program that compiles on Project Oberon shows what you are referring to? Regards, Chris Burrows CFB Software https://www.astrobe.com/RISC5
On 2021-01-31 22:40, Chris Burrows wrote:
Why do you ask the question?
I think it would be interesting to go through each extension and analyze why it's there. Is it because the official language is lacking somehow, is it due to backwards compatibility with previously written programs, or is it something else?
One of things on my possible 'list of things to do' is to produce a version of Project Oberon that is 100% compliant with the Language Report.
Good point! It seems natural to practice what you preach and keep the reference implementation in sync with the language report.
BTW I didn't think that dynamic arrays were implemented in the official Project Oberon compiler. Maybe we are thinking of something different. Can you provide a simple test program that compiles on Project Oberon shows what you are referring to?
I was under the impression that PROCEDURE P; VAR a: ARRAY OF INTEGER; BEGIN NEW(a, 100) END P is valid but it doesn't compile so I'm obviously wrong. -- August
August In EO, Andreas implemented a general NEW with length. Jörg
Am 31.01.2021 um 23:31 schrieb August Karlstrom <fusionfile@gmail.com>:
On 2021-01-31 22:40, Chris Burrows wrote:
Why do you ask the question?
I think it would be interesting to go through each extension and analyze why it's there. Is it because the official language is lacking somehow, is it due to backwards compatibility with previously written programs, or is it something else?
One of things on my possible 'list of things to do' is to produce a version of Project Oberon that is 100% compliant with the Language Report.
Good point! It seems natural to practice what you preach and keep the reference implementation in sync with the language report.
BTW I didn't think that dynamic arrays were implemented in the official Project Oberon compiler. Maybe we are thinking of something different. Can you provide a simple test program that compiles on Project Oberon shows what you are referring to?
I was under the impression that
PROCEDURE P; VAR a: ARRAY OF INTEGER; BEGIN NEW(a, 100) END P
is valid but it doesn't compile so I'm obviously wrong.
-- August -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of August Karlstrom Sent: Monday, 1 February 2021 9:01 AM To: oberon@lists.inf.ethz.ch Subject: Re: [Oberon] List of extensions for Project Oberon compiler
On 2021-01-31 22:40, Chris Burrows wrote:
Why do you ask the question?
I think it would be interesting to go through each extension and analyze why it's there. Is it because the official language is lacking somehow, is it due to backwards compatibility with previously written programs, or is it something else?
Now that I have had a taste of the power that you get by being able to modify the compiler I think I can understand how it happens. Often it can be easier to add a 'feature' to a compiler to solve a very specific problem than to code it using the existing language features. Wirth publishes the source code to the Oberon compiler so that Oberon users can do just that. If all of these 'features' were added willy-nilly to the official language you would end up with yet another monster like C#, Ada, Delphi etc. where the user has no choice but to be at the mercy of the compiler developer for enhancements, support, bug fixes etc.
One of things on my possible 'list of things to do' is to produce a version of Project Oberon that is 100% compliant with the Language Report.
Good point! It seems natural to practice what you preach and keep the reference implementation in sync with the language report.
Note that the Project Oberon compiler is not, and was never intended to be a 'reference' implementation. In some ways, now I think about it, attempting a reference implementation might just be asking for trouble. In a real world implementation of a language there are always going to be some 'grey areas' that are open to interpretation. That's exactly why democracies have judges and juries in their legal systems.
BTW I didn't think that dynamic arrays were implemented in the official Project Oberon compiler. Maybe we are thinking of something different. Can you provide a simple test program that compiles on Project Oberon shows what you are referring to?
I was under the impression that
PROCEDURE P; VAR a: ARRAY OF INTEGER; BEGIN NEW(a, 100) END P
is valid but it doesn't compile so I'm obviously wrong.
That was a feature in the Oberon-SA compiler (which preceded Oberon-07) - that might be what you were thinking of. Consequently this feature still exists in the Astrobe ARM Oberon compilers. I thought it was a good feature at the time but since realise it has limited usefulness. I would like to remove it as it prevents me from making other general enhancements that would benefit all users. I wish it had been an 'undocumented feature' as it would be easier to defend against any backlash that might occur if I removed it. :) Regards, Chris Burrows CFB Software https://www.astrobe.com/RISC5
Chris
One of things on my possible 'list of things to do' is to produce a version of Project Oberon that is 100% compliant with the Language Report. I believe that is eminently feasible.
At least the following code is not compliant to the Oberon Report: - FileDir.Search: Kernel.GetSector(dadr, a); - Display.Mod: module body needs some rework - ORG.Header: allowed hex constant not defined in Oberon Report. - Files.WriteReal Jörg
-----Original Message----- From: Jörg [mailto:joerg.straube@iaeth.ch] Sent: Monday, 1 February 2021 9:04 AM To: chris@cfbsoftware.com; ETH Oberon and related systems Subject: Re: [Oberon] List of extensions for Project Oberon compiler
Chris
One of things on my possible 'list of things to do' is to produce a version of Project Oberon that is 100% compliant with the Language Report. I believe that is eminently feasible.
At least the following code is not compliant to the Oberon Report: - FileDir.Search: Kernel.GetSector(dadr, a); - Display.Mod: module body needs some rework - ORG.Header: allowed hex constant not defined in Oberon Report. - Files.WriteReal J=
You might think that but I couldn't possibly comment on it ;-)
Chris:
One of things on my possible 'list of things to do' is to produce a version of Project Oberon that is 100% compliant with the Language Report. I believe that is eminently feasible. If you have a similar ambition then I would be happy to collaborate with you.
There can be two approaches to language definition and implementation. 1) Define the language the way it should be. Be surprised why there are no users and no useful applications. 2) Look at the applications, ask the users of previous versions, extract the advice from the community, and cautiously implement modifications which improve the language and also minimize the damage. This boils down to the question "why do computers exist in the first place?". One answer is "to justify the existence of computer scientists". The other might be "to perform some useful work". The first answer is right. The second answer is correct. So now one has to decide whether the correct is right, or the right is correct. Hint: History is littered with right ideas and great projects which nobody cares about except their authors. I have a few of these under my own belt. W.
-----Original Message----- From: Skulski, Wojciech [mailto:skulski@pas.rochester.edu] Sent: Monday, 1 February 2021 10:48 AM To: chris@cfbsoftware.com; ETH Oberon and related systems Subject: Re: [Oberon] List of extensions for Project Oberon compiler
Chris:
One of things on my possible 'list of things to do' is to produce a version of Project Oberon that is 100% compliant with the Language Report. I believe that is eminently feasible. If you have a similar ambition then I would be happy to collaborate with you.
There can be two approaches to language definition and implementation.
1) Define the language the way it should be. Be surprised why there are no users and no useful applications.
2) Look at the applications, ask the users of previous versions, extract the advice from the community, and cautiously implement modifications which improve the language and also minimize the damage.
Good point. There is one undocumented extension that I do find useful in low-level device drivers for example. That is the use of a type declared as ARRAY n OF BYTE as a formal parameter that maps onto actual parameters with a range of data types. It is similar to the use of ARRAY OF SYSTEM.BYTE in Oberon for the NS32000 but it is slightly safer in that it is restricted to data types with the same number of bytes. However, I can understand it not being included in the language Report as it is effectively a non-SYSTEM loophole which undermines type safety. Similar effectiveness could be achieved without altering the language by allowing SYSTEM.VAL to apply to non-scalar data types. The use of SYSTEM.VAL would highlight that it is non-portable. I would be interested to hear any feedback on this proposal. e.g. TYPE Word = ARRAY 4 OF BYTE; VAR i: INTEGER; b0, b1, b2, b3: BYTE; w: WORD; ... ... w := SYSTEM.VAL(Word, i); b2 := w[2]; Regards, Chris Burrows CFB Software https://www.astrobe.com/RISC5
participants (5)
-
August Karlstrom -
Chris Burrows -
Joerg -
Jörg
-
Skulski, Wojciech