x dev
2017-05-11 14:31:32 UTC
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.
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.