I think that one of the most important reasons why oberon language is not widespread and commonly used nowadays is absence of necessary implementation.
I had used all currently available compilers for oberon-2 language, and all of them lacks features I assume very important.
My position is that implementation should confirm following points:
1. compiler and all deployed libraries should be open source
Open source compiler with relatively good quality always much more preferable for software developers because in case of compiler fault they often can solve problem themselves instead of waiting for company which doesn't care of producing patches, or supporting compiler on a modern distributions.
This was a story of Kylix - proprietary object pascal compiler and IDE for linux: company was just abandoned developers, not only left them without patches and support but also in obscurity about kylix future.
As you may know now kylix has a place in borland museum, keeping company with other dead products.
On the contrary, open source freepascal compiler, also known as fpk is actively supported by developers community.
2. compiler should generate native code
Language is especially designed to produce native code.
For instance, in oberon report by N. Wirth we can read, that
"result type of a procedure can be neither a record nor an array"
According to Niklaus Wirth "Compiler Construction" book it is the way to generate fast and efficient code:
Quote from page 102 - Compiler Construction, Niklaus Wirth (ISBN: 0201403536) :
"If our primary goal is the generation of efficient code with the minimal number of memory accesses then a register is the prime candidate for temporarily holding the function's result. If this solution is adopted. we must renounce the capability of defining functions with a structured result, because structured values cannot be held in a register."
This is why generating native code in oberon based projects became a good tradition, for instance Juice project achieved uncomparable with java performance during web applets execution, and the main reason of that performance was idea to compile source into native code, not to byte code for some virtual
Besides, when code executed by hardware processor unit it is almost guarantee optimal performance in most cases.
3. whenever possible implementation should use
platform native features
When writing compiler for some platform, we do not have to write a complete environment to run compiled program on that target platform, it is already written.
Do not necessary to write an operating system on top of other operating system. Moreover, generated program shouldn't depend
on GUI software just like Blackbox Component Pascal framework.
We only have to write code generator which will generate a native code and resulting binary may be run on that platform, not more, not less.
O-K compiler concept is to avoid any complexity in design, and I found a way to integrate compiler in modern dominating C based operating systems in their native way.
Yes, in unix and windows systems every executable can have only one entry point while in oberon _every_ compiled module may have different entry points. But there are already implemented dynamic loaded libraries in modern operating systems, and any of them may have many exported functions. That libraries known to every windows user as files with .dll extention, and to any unix user as files with .so extention. O-K oberon-2 compiler will allow not only static linking when you can have one binary file which will not depend on any external library. The main difference of O-K compiler design is that it will allow dynamic module loading in
any system without complicated mechanisms of module loading and using only native possibilities.
O-K by default compiles every module as a separate shared object.
So, in case you wrote a program, which imports modules Out and Graphik modules, and your main module name is SomeProgram then
O-K compiler will generate three libraries with corresponding names. Also a one binary will generated, which accepts command line arguments with an exported procedure names.
So, for instance we have
IMPORT Out, Graphik;
o, after compilation in linux we'll have four resulting files, three libraries:
and one executable:
MainModule executable is a program automatically generated by compiler, and may accept
command line arguments like
In windows systems compiler will generate
you can run MainModule.exe with parameter DoThis or DoThat
4. implementation should use platform native tools
It is much more preferable to use target platform native tools,
for instance debugger. It is much clever to concentrate on quality compiler development not on already implemented tools development. It is much easier because many cross platform
tools already developed, and available under open source licenses, particularly many of them developed by GNU project.
So, there should be possibility to debug applications with gdb, and its graphical frontends.
4. Pure command line usage possibilities
All development cycle should be possible using only command line tools to allow working and debugging in console environments without graphics. It is especially useful when working on projects remotely using telnet or ssh connections, allows to automate some parts of development process.
Besides, there is a nice tradition in unix world to write whenever it's possible console applications, and front ends for that console applications. This allows use of application in console environments, and while software may do the same work it takes less space in memory, and it is possible to use it in shell scripts.
5. Avoiding wrappers
Compiler should generate native code for operating system whenever possible avoiding usage of external wrapper libraries like GNU C Library.
Because, if that kind of third party library changed, compiler should be changed with it.
Bugs, which may be found in that library will affect compiler produced code.
Avoiding wrappers helps to have faster resulting executables.
And finally, in case of GNU/Linux systems it will allow not to concentrate on this or that concrete distribution, but support whole family of linux distributions.
For instance, Borland Kylix designed with dependence on glibc, and so it had troubles to run on any GNU/Linux distribution, and runs just on a few supported commercial distributions.
6. Calling conventions
All possible shared object external functions calling conventions should be supported, so called: cdecl, pascal, register, etc. to
allow using our code with most of other languages and to allow us write code using shared objects generated with other languages.
7. Various backends
On an early stage of development it costs too much time and complexity to implement direct generating object code though it is more faster way. Instead for now I prefer to generate assembly source code for various backends. Now I have a plan how with minimal efforts have a working compiler for Linux, Windows, Macos and FreeBSD operating systems running on intel/amd 32 and 64 bit processors.