If only the FPC compiler supported it and allowed combining units in Oberon with Pascal ones in one project!
The language specs: https://github.com/oberon-lang/specification/blob/master/The...
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!
> 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.
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.
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.
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.
declare
function f (i: Integer) returns Integer is ( i * 2 );
x : Integer;
begin
x := f(21);
end;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.)
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.