You appear to be familiar with Pascal, so I am surprised you find the statement-heavy approach an issue. What would be the benefit of making this change?

My Pascal days are far in the past, but I recently used Lazarus to quickly prototype a simple GUI app (not many tools beat it yet for the task) and was a bit annoyed by the syntax.

Relying on expressions greatly reduces the need for transitory variables, and in case of Pascal, where you can't just declare them as you go, this would be especially important to clear the code from ops inessential to the task at hand.

`let foo = if (bar > 0) then bar else frobnicate() end` would be nice to have, as well as begin-end blocks with their own scope (can't fathom the reasons it's not allowed) and evaluated to the last statement. Rust and Nim get it mostly right.

This does feel then like a matter of taste. While Pascal's predecessor language Algol did allow syntax like that, adding it back to Pascal-like languages would make it into a different kind of language.

What makes the language what it is is rather a philosophical question. I don't think I agree with you on this specific point.

I'm not against evolution, especially when you have others to test the feature extensively for years. But I'm not a language designer and my opinion on the matter holds no weight.

Ada 2012 has expression functions

    declare
        function f (i: Integer) returns Integer is ( i * 2 );
         x : Integer;
    begin
        x := f(21);
    end;

Oberon+ is not set in stone; if there are good ideas that fit into the concept of simplicity and add significant value, they should be considered. From my point of view, however, one should rather avoid proliferation, as one can observe it with C# or TypeScript.

It's very nice to hear and I agree that languages have to move slowly, considering each move. On the other hand, when the user base is still slim you have much more freedom to be a bit more adventurous, add and deprecate things more freely. Some of the features can also be optional and available for those not afraid to try unstable things.

It's a bit interesting that I initially stumbled on Oberon+ while searching for something typed which compiles to straight Lua and was surprised seeing the scope of the project.

In any case, I wish you all the best in the development of the language!

Thanks.

> when the user base is still slim you have much more freedom to be a bit more adventurous, add and deprecate things more freely

When designing a language, it's hard to get rid of the initial sins, so if in doubt, leave a feature out, so you don't regret it later; once enough people are involved with the language and writing code with it, any change that isn't backwards compatible is an imposition on everyone involved.

I agree completely.

Playing the devil's advocate: On the other hand, making a whole new language is rarely a way to GTD now, it's usually an investment in the future. For surviving into that future the language usually needs the involvement of the community. And for that one has to consider what new/different/radical things does the language offer to the public to hook them on. May be it's OK to sin a little and get straight closer to v1.0? Of course, a few will hurt but they'll live.

I guess you could make changes like that while keeping backward compatibility with older Oberon, but that's probably kind of a pain, no? I agree that such changes would make Oberon more to my taste.

Maybe what we really want would be semantically close to Oberon+ but abandoning Wirth's surface syntax. (You could still respect the design discipline of allowing a simple fast compiler.)

I'm fine with Nim for my limited set of problems, but it's its own thing and not exactly in the family. Ideally, it would be something supported by the FPC compiler.

The reason pascal is so easy to work with is that each phase of a program is separate... you have your Units, then types, variables, functions, procedures, and blocks of code all separate

making a mish-mash of variable declarations and code would make it quite easy to inadvertently add a new variable similar, but not identical to an existing one, for example.

It's good that procedures and functions in pascal are different. One of the big problems with C is that you can leave function results dangling, which works against the clean separation of purposes... procedures have side effects, functions tend not to (but can).

One of the most clever things in pascal is assignments := are very hard to confuse with tests for equality =. You're not likely to accidentally confuse them.