I know this is old now, but yes these are good points and suggestions.

I myself am just embarking on attempting to write a compiler front-end for Oberon, following Wirth's book and docs from Project Oberon. Of course I'm certainly not the first and the last!

If we could just get 1 compiler to target native - not transpile - then I think people would be more inclined to take Oberon more seriously, and invest the time and effort in writing libraries and modules.

Project Oberon is cool and it was quite visionary for Wirth. But for Oberon lang to be practical and more widely used, it really does need to be decoupled from Oberon System.






On Thursday, May 11, 2017 at 10:31:33 AM UTC-4, x dev wrote:

OPCL is an interesting project which demonstrates that standalone applications for mainstream operating systems can be built using Oberon. However, it is showing its age. Maybe ETH Zürich can lead to creation of a modern basic development tool that is

inspired by Java SDK.

This request is public so that the most essential elements of an Oberon programming environment can be openly discussed. Below are my suggestions.

The new development kit should cover essential features:
1) LLVM IR.
2) Windows and Ubuntu distribution.
3) Unicode support.
4) XML support.
5) Standard libraries that were outlined in Oakwood guidelines.
6) Exception handling.

Although we want to have a good starting point similar to Java SDK, we don't expect everything from ETH Zürich. The main considerations for an Oberon SDK are:
a) Documenting the language precisely.
b) A tool that will allow us to develop real world software. It needs to be separate from Oberon OS and still be fully functional.
c) It should be easy to alter and extend the compiler for custom needs.

Explanations of the requested features:
(1)
Since LLVM 4.0 has been released recently, the development kit can take advantage of it and rely on 64-bit human-readable IR. This will serve (a) and (c), because anyone can study the output of the compiler. Since human-readable IR can be translated to

bitcode, developing real world software will still be possible:

http://llvm.org/docs/CommandGuide/llvm-as.html

(2)
I suggest that the SDK would be available for Windows and Ubuntu, two very popular systems. This will make the tool very accessible. Besides, this will demonstrate that the language is cross-platform. LLVM supports many architectures, so it will be

trivial to make unofficial ports of the SDK to other operating systems.

(3)
A standard way to handle unicode needs to be introduced. I guess it's just a matter of introducing a module like libunistring:
https://www.gnu.org/software/libunistring

The way to handle localized strings like iso-8859-1 should also be made clear.

(4)
XML is a very commonly used data interchange format today. I guess it is hard to ignore even in a basic programming kit. At least a simple parser like SAX-parsers can be implemented. Another option is to provide bindings for a well-known XML library

like libxml.

(5)
I suppose it will not be very costly to include complete set of basic modules and additional modules suggested by Oakwood guidelines. Since the work belongs to 1993-1995, a revision would be nice too:
http://www.math.bas.bg/bantchev/place/oberon/oakwood-guidelines.pdf

(6)
Error handling mechanism can be more comprehensive. There is Exceptions module in OPCL. An ideal error handling mechanism is the one that doesn't induce computational cost when it is not used. Zero-overhead exception handling is very nice, but it's not

an absolute necessity.

Error handling is like memory management. NEW and DISPOSE procedures do not affect a program when they are not used. But when they are used they will have computational cost. Now, what memory management has to do with programming? An algorithm will

never have steps like "allocate memory" or "free memory", so memory management is not part of a program. Error handling is just like that. It's not part of the program but we need to do it. If possible, automatic error handling facilities should be
implemented, just like automatic memory management (garbage collection).

System exceptions and input stream/user input errors are not the only error types. Today's software projects are huge, consisting of many components that are written by different programmers. When you write a routine, it is very likely that the

programmer who is using it will not know how to use it very well. So you need to handle programmer errors.

---

Hopefully some libraries like database connectivity, network protocols, gui frameworks will be implemented by other developers. Implementation of some useful compiler features like compiler directives, ability to create daemons (services) can also be

left to third parties. I believe that once a working system that is ready for modern programming is presented, people will be interested in it and start to contribute to it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2018-03-01 17:47, Yves Cloutier wrote:

If we could just get 1 compiler to target native - not transpile -
then I think people would be more inclined to take Oberon more
seriously, and invest the time and effort in writing libraries and
modules.

Why do you think that? As long as the generated code is efficient, why
would anyone care if it is compiled directly to binary or compiled via
e.g. LLVM IR or C?

Project Oberon is cool and it was quite visionary for Wirth. But for
Oberon lang to be practical and more widely used, it really does need
to be decoupled from Oberon System.

With this I agree.


-- August

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, 1 March 2018 19:53:34 UTC+1, August Karlstrom wrote:

On 2018-03-01 17:47, Yves Cloutier wrote:

If we could just get 1 compiler to target native - not transpile -
then I think people would be more inclined to take Oberon more
seriously, and invest the time and effort in writing libraries and
modules.

Why do you think that? As long as the generated code is efficient, why
would anyone care if it is compiled directly to binary or compiled via
e.g. LLVM IR or C?

Project Oberon is cool and it was quite visionary for Wirth. But for Oberon lang to be practical and more widely used, it really does need
to be decoupled from Oberon System.

With this I agree.

-- August

In my experience, transpiling to C is very effective in many scenarios, especially to port Oberon programs to many different CPUs in bare metal scenarios with a reasonable effort.
Virtually all systems have a C compiler.
This does not exclude the interest for native compilers, in particular for mainstream platforms like Windows, macOS and Linux.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Actually, reading the vishap compiler page, I see native backend is on the roadmap:

Work on native backends for arm and x86_64 is in progress.
voc team also works on bindings to existing C/Pascal libraries.

Even better, I see that voc is on arch AUR.

I didn't realize how many modules were available.

Looks like a lot of amazing work is already underway!


On Thursday, March 1, 2018 at 3:21:32 PM UTC-5, s_ant...@hotmail.com wrote:

On Thursday, 1 March 2018 19:53:34 UTC+1, August Karlstrom wrote:

On 2018-03-01 17:47, Yves Cloutier wrote:

If we could just get 1 compiler to target native - not transpile -
then I think people would be more inclined to take Oberon more
seriously, and invest the time and effort in writing libraries and modules.

Why do you think that? As long as the generated code is efficient, why would anyone care if it is compiled directly to binary or compiled via
e.g. LLVM IR or C?

Project Oberon is cool and it was quite visionary for Wirth. But for Oberon lang to be practical and more widely used, it really does need
to be decoupled from Oberon System.

With this I agree.

-- August

In my experience, transpiling to C is very effective in many scenarios, especially to port Oberon programs to many different CPUs in bare metal scenarios with a reasonable effort.
Virtually all systems have a C compiler.
This does not exclude the interest for native compilers, in particular for mainstream platforms like Windows, macOS and Linux.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2018-03-01 23:38, Yves Cloutier wrote:

Actually, reading the vishap compiler page, I see native backend is on the roadmap:

If I'm not mistaken, vishap is a compiler for Oberon-2, not Oberon-07.

-- August

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2018-03-01 21:21, s_antoniaz@hotmail.com wrote:

This does not exclude the interest for native compilers, in particular for mainstream platforms like Windows, macOS and Linux.

To develop a compiler back-end for a complex architecture like AMD64
which beats the code optimizer of e.g. GCC must be quite a challenge.


-- August

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, March 2, 2018 at 3:17:15 AM UTC+10:30, Yves Cloutier wrote:

If we could just get 1 compiler to target native - not transpile - then I think people would be more inclined to take Oberon more seriously, and invest the time and effort in writing libraries and modules.

Project Oberon is cool and it was quite visionary for Wirth. But for Oberon lang to be practical and more widely used, it really does need to be decoupled from Oberon System.

Patchouli is an Oberon-07 compiler for Intel 64 (AMD64) architecture that generates native code directly:

https://github.com/congdm/Patchouli-Compiler

Regards,
Chris Burrows
CFB Software
http://www.astrobe.com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01.03.18 17:47, Yves Cloutier wrote:

I know this is old now, but yes these are good points and suggestions.

I myself am just embarking on attempting to write a compiler front-end for Oberon, following Wirth's book and docs from Project Oberon. Of course I'm certainly not the first and the last!

If we could just get 1 compiler to target native - not transpile - then I think people would be more inclined to take Oberon more seriously, and invest the time and effort in writing libraries and modules.

Project Oberon is cool and it was quite visionary for Wirth. But for Oberon lang to be practical and more widely used, it really does need to be decoupled from Oberon System.

This is not necessary. You can use the Oberon System as an
infrastructure layer such as Eclipse when building applications. And
this can even be done without X11 if certain measurements are taken.
With this approach you can write command line tools and daemons. Have a
look at Templ Josef's work.

On Thursday, May 11, 2017 at 10:31:33 AM UTC-4, x dev wrote:

OPCL is an interesting project which demonstrates that standalone applications for mainstream operating systems can be built using Oberon. However, it is showing its age. Maybe ETH Zürich can lead to creation of a modern basic development tool that

is inspired by Java SDK.

This request is public so that the most essential elements of an Oberon programming environment can be openly discussed. Below are my suggestions.

The new development kit should cover essential features:
1) LLVM IR.
2) Windows and Ubuntu distribution.
3) Unicode support.
4) XML support.
5) Standard libraries that were outlined in Oakwood guidelines.
6) Exception handling.

Although we want to have a good starting point similar to Java SDK, we don't expect everything from ETH Zürich. The main considerations for an Oberon SDK are:
a) Documenting the language precisely.
b) A tool that will allow us to develop real world software. It needs to be separate from Oberon OS and still be fully functional.
c) It should be easy to alter and extend the compiler for custom needs.

Explanations of the requested features:
(1)
Since LLVM 4.0 has been released recently, the development kit can take advantage of it and rely on 64-bit human-readable IR. This will serve (a) and (c), because anyone can study the output of the compiler. Since human-readable IR can be translated

to bitcode, developing real world software will still be possible:

http://llvm.org/docs/CommandGuide/llvm-as.html

(2)
I suggest that the SDK would be available for Windows and Ubuntu, two very popular systems. This will make the tool very accessible. Besides, this will demonstrate that the language is cross-platform. LLVM supports many architectures, so it will be

trivial to make unofficial ports of the SDK to other operating systems.

(3)
A standard way to handle unicode needs to be introduced. I guess it's just a matter of introducing a module like libunistring:
https://www.gnu.org/software/libunistring

The way to handle localized strings like iso-8859-1 should also be made clear.

(4)
XML is a very commonly used data interchange format today. I guess it is hard to ignore even in a basic programming kit. At least a simple parser like SAX-parsers can be implemented. Another option is to provide bindings for a well-known XML library

like libxml.

(5)
I suppose it will not be very costly to include complete set of basic modules and additional modules suggested by Oakwood guidelines. Since the work belongs to 1993-1995, a revision would be nice too:
http://www.math.bas.bg/bantchev/place/oberon/oakwood-guidelines.pdf

(6)
Error handling mechanism can be more comprehensive. There is Exceptions module in OPCL. An ideal error handling mechanism is the one that doesn't induce computational cost when it is not used. Zero-overhead exception handling is very nice, but it's

not an absolute necessity.

Error handling is like memory management. NEW and DISPOSE procedures do not affect a program when they are not used. But when they are used they will have computational cost. Now, what memory management has to do with programming? An algorithm will

never have steps like "allocate memory" or "free memory", so memory management is not part of a program. Error handling is just like that. It's not part of the program but we need to do it. If possible, automatic error handling facilities should be
implemented, just like automatic memory management (garbage collection).

System exceptions and input stream/user input errors are not the only error types. Today's software projects are huge, consisting of many components that are written by different programmers. When you write a routine, it is very likely that the

programmer who is using it will not know how to use it very well. So you need to handle programmer errors.

---

Hopefully some libraries like database connectivity, network protocols, gui frameworks will be implemented by other developers. Implementation of some useful compiler features like compiler directives, ability to create daemons (services) can also be

left to third parties. I believe that once a working system that is ready for modern programming is presented, people will be interested in it and start to contribute to it.


--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)