Basic Types and some questions

[tarkonian]

First thank you for the great work with oberon+. I am learning your implementation and congratulations. If possible I need some clarifications. In the documentation (section 6.1) there are some types declared (INT8,...) but when a try to use these types in the program the compiler emit a error. These types are not implemented in the compiler or I need to import some additional module? Another question is about the println procedure. There is some example in how to use it with integers, real, etc... I don´t know if you look at the XDS-Modula-2 compiler, but there are some very cool procedure (printf like c) that can be used in the oberon+. In pascal I really like the generic writeln and readln. You have println there is a readln equivalent? You have plan to introduce Complex Number, Complex Math in the language? And the last question (sorry for the long post) there is a way to call a extern command line program (for example gnuplot) in windows environment? Thank you.

[rochus-keller]

Hi tarkonian Thanks for your feedback which I appreciate.

there are some types declared (INT8,...) but when a try to use these types in the program the compiler emit a error

The reason is likely that the precompiled version is a bit dated; I should actually update all precompiled versions when I make changes but I usually forget and unfortunately I'm not very comfortable with Github actions (by which I could automate the build). On which OS/architecture are you? I could update the binary at least for that one, or you can build it yourself as described here.

the println procedure

The println() procedure is mostly a feature I use for development and debugging; as far as I remember it's not even declared in the specification. The "official" way is to use the In and Out module of the Oakwood standard library; you can enable this library with the IDE/Project/Build-in Oakwood menu.

In pascal I really like the generic writeln and readln

Pascal has a lot more pre-declared functions/procedures which are just there (officially part of the system unit e.g. in FreePascal). Wirth went away from this concept already in the late seventies when he invented Modula-2 and Oberon does it the same way.

Complex Number, Complex Math in the language

There are actually complex numbers defined in the Oakwood guidelines, but I don't support these modules (yet). You can easily implement them yourself, but Oberon doesn't support operator overloading, so you have to do it with regular procedures (as also proposed by Oakwood as far as I remember).

there is a way to call a extern command line program

Oberon+ has a quite powerful FFI feature which is part of the language; you can use it to call C functions, e.g. from the C standard library, or maybe directly from a gnuplot shared library. With the system() function of the C standard library you can run external programs.

[tarkonian]

Thank you I am compiling now the Ide. My interest is more in scientific computing (I am a retired physicist that use mainly c and fortran). I look at the oberon implementation Vishap (https://github.com/vishaps/voc) and there are many modules that a believe follow the Oakwood standard. Currently I am studying the Pascal Library DMath (https://wiki.freepascal.org/DMath) and if possible I will translate to oberon+ (or modula-2). The main problem is that the pascal code is sometime a mess. Again thank you for your work.

PS: as Brazilian I am happy that you use Lua and not python for the scripts.

[rochus-keller]

Welcome. Just ask if you need support with the build.

The Vishap Oberon compiler is great and likely delivers good performance when compiling the generated C code with GCC or CLANG, but unfortunately it uses the original Oberon/-2 syntax with all its limitations (why I implemented Oberon+).

The main problem is that the pascal code is sometime a mess.

Also the language itself unfortunately is a mess and the generated code is not particularly efficient (see e.g. https://forum.lazarus.freepascal.org/index.php/topic,64261.0.html). It turned out that the selection of language features is very relevant for the resulting performance, since some features are surprisingly slow (see e.g. https://forum.lazarus.freepascal.org/index.php/topic,64275.0.html). Oberon+ via GCC is nearly as fast as C++, and the Mono version is still fast enough for development and debugging (see https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf).

if possible I will translate to oberon+

That would be great, but keep in mind that Oberon+ is work in progress and not yet an established product.

as Brazilian I am happy that you use Lua and not python for the scripts.

Also as a Swiss I'm very happy that I can use something as lean and elegant as Lua instead of Python ;-)

[tarkonian]

The problem of free pascal is that it is based on the borland (delphi) pascal variants (to be sincere I don´t like object oriented paradigm). Its incredible that we don´t have a full ISO Pascal compiler (we have variants like Pascal ABC, delphi, free pascal, etc...) For example, Modula-2 have 3 complete ISO compiler (gnu-modula-2, XDS and ADWM2). Oberon-2 and 7 have many compilers. The problem with arrays is pascal is old (the fortran community talked about this in the past) . One solution was proposed by Vector Pascal (https://en.wikipedia.org/wiki/Vector_Pascal). The Active Oberon have some very good solutions (Math Arrays, multithreading, for example), but the problems is that the compiler work only inside the A2 system and the lack of documentation for the library Matrix. A full stand-alone A2 compiler would be fantastic. As an outsider (reading discussion in the forums of oberon, pascal, etc..) my impression is that these languages form a kind of cult where the small number of user consider some modification of the language a heresy. Oberon+ make some beautiful modification (not only CAPS, no semicolon, etc.). A possible suggestion is to eliminate the begin-end (like in Julia language where we have only end). In the future if possible you could consider the introduction of functions as immutable procedures without side effects (some language have a clear distinction between immutable functions and mutable procedures, the nim language has this for example). In parallel computations mutable variable cause many errors in the program execution.

[rochus-keller]

The Active Oberon have some very good solutions (Math Arrays, multithreading, for example)

Maybe one could port it to Oberon-2 or Oberon+; support for multi-threading is on my list; it will be a library feature though (I'm not convinced that multi-threading should be part of the language syntax).

my impression is that these languages form a kind of cult where the small number of user consider some modification of the language a heresy.

I share that impression; I'm not member of the Oberon list, but I did, however, notice the incredible outrage from there when I posted Oberon+ on Reddit ;-)

Oberon+ make some beautiful modification

You might have recognized the similarity to Lua.

eliminate the begin-end

In comparison to Pascal "begin" is mostly eliminated; it appears once per procedure (unless it's only one return statement in which case it can be left out) and optionally once per module; I think it's affordable.

introduction of functions as immutable procedures

There is already the possibility to declare the receiver of a type-bound procedure as "IN", but I'm not yet sure how useful that is, and I'm very hesitant to add features, because the compiler becomes more complex and if the feature is there you're likely never get rid of it anymore, even if it's a bad feature. I don't want Oberon+ to share the same fate as FreePascal ;-) You could consider writing the mathematical parts in a functional language which is optimized for such applications, and use the result as an external library in Oberon.

[tarkonian]

"In comparison to Pascal "begin" is mostly eliminated; it appears once per procedure (unless it's only one return statement in which case it can be left out) and optionally once per module; I think it's affordable."

Yes this the same in modula-2.

"There is already the possibility to declare the receiver of a type-bound procedure as "IN", but I'm not yet sure how useful that is, and I'm very hesitant to add features, because the compiler becomes more complex and if the feature is there you're likely never get rid of it anymore, even if it's a bad feature. I don't want Oberon+ to share the same fate as FreePascal ;-) You could consider writing the mathematical parts in a functional language which is optimized for such applications, and use the result as an external library in Oberon."

I am only a "user" then I don´t understand the complexity to create a compiler, but you are correctly. In general the language is only important if it is related with a good compiler, debugger, libraries and tooling (how to import external libraries). Nobody care about the Python as language. It success comes from the ease to use libraries (numpy, matplotlib, networkx, etc..). In my opinion the mistake of prof. Wirth (and many others) was to think that everyone that will use a language know how o create libraries and will have a deep knowledge of the language. Using functional languages (and I consider F# a very beautiful language) in high performance numerical application is not usual. In general the garbage collector (that is essential in functional languages because of multiples copies necessary to create mutable data) interferes in the performance. The Rust language is a exceptions because the language have many of the features of functional languages without a Garbage Collector (the complexity of language is the price to be paid). I will write some code in oberon+ (computational physics codes) and if I found some problem in the compiler I will report. Thank you.

[rochus-keller]

Welcome.