Variable Initialization

[tarkonian]

In the discussion about the necessity to use begin-end construct and not only a block end like in Julia language I read some arguments that the Begin block is used to separate the data definition (types) from the data flow (manipulation and commands), but in my opinion this is not true. In Pascal or ADA we can write a program with data definition and initialization before the begin:

ADA -> a:integer:= 1, b:real; PASCAL -> a:integer = 1, b:real;

In the new Delphi we can write also: for var i:integer =1 to ...

But in Oberon (also oberon+) we have to write

var a:integer;

begin a:=1 ... Then we have data also in the begin block and not only the manipulation of these data. My question is why the language can´t really make a separation and put all the data (definition, type and initialization) in the same place?

[rochus-keller]

but in my opinion this is not true.

Yes, technically it's not necessary; e.g. in ALGOL 60 you just start with declarations in a block and then continue with statements as you do e.g. in C. The separation of the declaration and statement section was a design decision by Wirth which he maintained in all languages over the years. From my point of view Pascal, Modula and Oberon had more important issues than this one, first and foremost the lack of dynamic arrays (which was only fixed in Oberon-2). Pascal in addition, even it's many derivatives, still suffers from the dangling else problem because of its ALGOL inheritance, which is also the reason for the many uses of "begin". There are constantly discussion why in Pascal and derived languages declarations are only possible on top of the block. Personally I spent much more time with C++ or Java where you just declare things where you use them for the first time; I can live with both approaches; both have their merrits and their downsides.

But in Oberon (also oberon+) we have to write

Initializers for variables were added in non-Wirth Pascal derivatives. Personally I don't think it's worth the additional language extensions and complexities. If Oberon+ would support it, also literals for records and arrays would have to be added. This would require a lot of additional rules for type compatibility, field/element correspondence (especially when inheritance is present) and the like. The goal of Oberon, and with it also Oberon+, is to be as simple as possible; of course it should not be too simple, because that would increase code complexity for other reasons, but the goal is to find the right balance. From my point of view it is preferable to initialize variables close to where they are used, which is actually the main advantage of the in-place declarations you can e.g. do in C++ or Java (where a declaration is just another statement).

[tarkonian]

Thank you for the answers. Sometime a have doubts if Wirth was more interested in create a powerful and easy language in the design aspect or in the compiler aspect. One of the Go Language creator (Robert Griesemer) that studied in ETH and make a PHD with Wirth always say that the Go language has many elements of Oberon with the c semantic. But the language have a huge standard library that make easy to work. I don´t know if you read this essay

http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

But in many aspects show what I think about the Wirth languages that really don´t have a true leadership to discuss the evolution of the language (try to search Oberon in the ETH site). I don´t know is someone teach or use oberon there today. Many of the implementation comes from Russian and each one create his own version of the language extensions. The Active Oberon is more a phd research project. Pascal have Embarcadero and their product delphi, and yet as you said the Pascal have many problems not solved in 50 years.

[rochus-keller]

if Wirth was more interested in create a powerful and easy language in the design aspect or in the compiler aspect

He always took a simplified subset of the languages he studied (Algol W, Mesa, Cedar); he alwas optimized the overal trade-off including his own effort to implement the compiler.

Go language has many elements of Oberon with the c semantic

Go actually has surprisingly little in common with Oberon; the obvious similarity is the syntax of the type-bound procedure headers where the corresponding class is noted in the first pair of parenthesis. That was originally an idea of Hanspeter Mössenböck, the author of Oberon-2 and PhD supervisor of Griesemer.

try to search Oberon in the ETH site

Yes, there is not much left; I don't think it's still used for teaching.