[Oberon] List of extensions for Project Oberon compiler
Chris Burrows
chris at cfbsoftware.com
Mon Feb 1 00:03:08 CET 2021
> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> August Karlstrom
> Sent: Monday, 1 February 2021 9:01 AM
> To: oberon at 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
More information about the Oberon
mailing list