Anytime I see an announcement of a new ALGOL-like language, I check for two biggest problems which I didn't like in my Turbo Pascal days: error handling and memory management. Let's check this language:
Error handling: language specification has no mention of word "error". The example show the total lack of it: JSON parser, on seeing the invalid data, prints error and exits entire program (!!!) [0]
Memory management: Oberon+ has garbage collection! Nice!
So a clear improvement, but still needs some work before becoming usable.
(Note that error handling is as much user convention as is compiler support -- after all, C has no language-level error handling either, but C's JSON parsers do not exit entire program on invalid json.)
> Error handling: language specification has no mention of word "error"
Errors can still be handled even without explicit provisions in the language; some languages offer exceptions; in my 30 years of C++ I actually use them very rarely; Wirth decided against such in Oberon and I followed him in this respect. It's always a delicate consideration which elements should be part of the language or part of the library; from my point of view topics like threads or exceptions can be covered well via library. Oberon is supposed to be "as simple as possible". Here is some rationale: https://oberon-lang.github.io/2021/07/16/motivation-for-a-ne....
> Oberon+ has garbage collection! Nice!
The predecessor language Oberon has a garbage collector since 1987 (see https://doi.org/10.3929/ethz-a-005363226). Oberon+ is just an extension of it (with selected new features to keep it as simple as possible while being nevertheless useful - at leat from my point of view).
> Errors can still be handled even without explicit provisions in the language
Sure! but as I said in the last sentence of my post, "error handling is as much user convention as is compiler support"
In particular, almost all C code I have seen is designed to handle errors gracefully -- every stdlib function may fail and user is expected to handle it. On the other hand, much of the oberon code I have seen before is pretty bad with error handling -- the program will just halt on any error.
Now, I cannot really tell which way Oberon+ will go because there is so little code written in it, and it seems there isn't even a way to open a file as of now. But I browsed around and found JSON parser in Oberon+ and it handles errors by calling halt()... so it does not look like this version has good error handling (yet?)
There are similar possibilities for error handling as in C. The definition and implementation of the Oberon+ standard library is work in progress. Also the Blackbox framework, of which I already migrated a lot of modules, has some interesting approaches which I study. The Json parser you mention is part of the Are-we-fast-yet benchmark suite which apparently doesn't need much error handling.
EDIT: Btw. there are quite some notable C libraries which for certain error conditions just call a panic function or print a message to stderr and then call exit().
Anytime I see an announcement of a new ALGOL-like language, I check for two biggest problems which I didn't like in my Turbo Pascal days: error handling and memory management. Let's check this language:
Error handling: language specification has no mention of word "error". The example show the total lack of it: JSON parser, on seeing the invalid data, prints error and exits entire program (!!!) [0]
Memory management: Oberon+ has garbage collection! Nice!
So a clear improvement, but still needs some work before becoming usable.
(Note that error handling is as much user convention as is compiler support -- after all, C has no language-level error handling either, but C's JSON parsers do not exit entire program on invalid json.)
[0] https://github.com/rochus-keller/Oberon/blob/master/testcase...
> Error handling: language specification has no mention of word "error"
Errors can still be handled even without explicit provisions in the language; some languages offer exceptions; in my 30 years of C++ I actually use them very rarely; Wirth decided against such in Oberon and I followed him in this respect. It's always a delicate consideration which elements should be part of the language or part of the library; from my point of view topics like threads or exceptions can be covered well via library. Oberon is supposed to be "as simple as possible". Here is some rationale: https://oberon-lang.github.io/2021/07/16/motivation-for-a-ne....
> Oberon+ has garbage collection! Nice!
The predecessor language Oberon has a garbage collector since 1987 (see https://doi.org/10.3929/ethz-a-005363226). Oberon+ is just an extension of it (with selected new features to keep it as simple as possible while being nevertheless useful - at leat from my point of view).
> Errors can still be handled even without explicit provisions in the language
Sure! but as I said in the last sentence of my post, "error handling is as much user convention as is compiler support"
In particular, almost all C code I have seen is designed to handle errors gracefully -- every stdlib function may fail and user is expected to handle it. On the other hand, much of the oberon code I have seen before is pretty bad with error handling -- the program will just halt on any error.
Now, I cannot really tell which way Oberon+ will go because there is so little code written in it, and it seems there isn't even a way to open a file as of now. But I browsed around and found JSON parser in Oberon+ and it handles errors by calling halt()... so it does not look like this version has good error handling (yet?)
There are similar possibilities for error handling as in C. The definition and implementation of the Oberon+ standard library is work in progress. Also the Blackbox framework, of which I already migrated a lot of modules, has some interesting approaches which I study. The Json parser you mention is part of the Are-we-fast-yet benchmark suite which apparently doesn't need much error handling.
EDIT: Btw. there are quite some notable C libraries which for certain error conditions just call a panic function or print a message to stderr and then call exit().