The Oberon+ Programming Language

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 e.g. C#, C++ or TypeScript.

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?

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.)

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.

For me, "begin" and "end" are actually much more comfortable to type, because I don't have too move my hands for that, I can stay pretty much on the home row. Curly Braces are way too far on the right top to do that and then you either have to use you weak fingers or move quite a bit.

(Granted I am touch typing and also using Colemak layout, so rarely ever move my hands. For people that hunt and pek, I believe curly braces are easier to type.)

I don't think there is much practical difference between curly-braced vs keyboard based syntax. Both are similarly easy to read, especially with syntax highlighting. After a while, your brain will automatically parse "begin" and "end" as a symbol, same as curly braces, so you won't notice the "noise".

As for the pros and cons:

Pascal style syntax is slightly better for new people learning to program. Learning how to even type those weird curly braces and understanding the difference between all the styles of braces just takes focus away from actually learning how to program.

Curly braced C-style syntax is better for people that already know how to program because everyone is already familiar with at least one curly braced language.

If you've dismissed a whole host of languages just at a glance, you're missing out. Lua has little in common with Pascal, which has little in common with Fortran, etc. As a sister post to this says, you see them more as tokens once you are familiar. Emboldening or coloring keywords also helps, as for any language.

Code is read much more times than written, and hieroglyphs don't help.

apart from that (which i agree with) is that in most pascal-like languages you have to define variables at the top of a function, and their scope is the whole function. both c (nowadays, define at top of a {} scope) and c++ (define anywhere inside a function) do much better which, together with irritating long names, may explain why c and c++ won out over the pascal-likes.

speaking as an ex professional delphi programmer here - i have written lots of object pascal code, and have no desire to write any more.

Pascal required BEGIN and END for every block, such as: IF <cond> THEN BEGIN <code> END ELSE BEGIN <code> END END, but Modula-2 and Oberon don't require BEGIN or END around code blocks: IF <cond> THEN <code> ELSE <code> END. BEGIN is now only used to denote the end of variable declaration and the beginning of the code. You can see this if you click the posted link. I think it was a valid complaint in Pascal, but not in it's derived languages.

I'm actually okay with begin and end, but, writing a function's name twice on both the declaration and after the end statement sounds like a HUGE chore. If that's mandatory, it's immediately a mood killer for me about Oberon+.

I think it's less about typing them and more about reading them. Curly braces reduce the number of keywords in the language (unless the alternative is indentation sensitivity like in Python or Haskell). This means that if I see a word, it is easier to infer if it is a variable name or if it does something structural.

How about a treesitter-based editor extension that converts between begin/end and {/}, as if they were ligatures? Actually this might not even need treesitter.

That seems like it would be a simple thing to change.

I studied CS at ETH from 2001 to 2006. Oberon was the main language used for teaching our introductory CS courses IIRC. Fun times. :-)

Note that the evolution of it was Active Oberon and AOS operating system, much more closer to modern languages and OS stacks.

Yea I was going to comment and say if anyone is interested in a modern language the follows in the tradition of Pascal/Oberon they should look into Odin

This is from normal traditional Oberon, however.

A few years ago i was also thinking of how Oberon-07 could be extended to support more generic types - mainly so containers, etc, can be more type safe - and pretty much came to the same conclusion that putting types on the modules themselves is by far the simplest approach. Though my approach was a bit different (judging from the code examples) in that parametric modules were more like templates that were specialized during import.

Specifically in Oberon-07 when you have a module "Foo" with a type "Bar" you use it in another module as "Foo.Bar". With parametric modules, a "Foo<T>" module would need to be imported an a specialized form as -e.g.- "Foo<INTEGER>" and thus the "Bar" type would need to be used as "Foo<INTEGER>.Bar".

In my mind that was both the simplest and smallest change that would allow for the most flexibility (the parameters would be any token acceptable by the language, not just types, meaning that they could be used for constants or even affect other imports).

I did consider implementing a compiler for this, but then i decided that if i'm going to make a compiler for an incompatible language that already practically nobody uses, might as well make my own language that also changes some things i dislike about Oberon-07 (like the uppercase keywords, using # for the inequality string and * to export stuff from modules).

I did coroutines under Turbo Pascal wayyyyy back in the 1980s[1]. It's really just a matter of copying the stack and some book-keeping.

Free Pascal has threads.

[1] https://www.pcorner.com/list/PASCAL/TASKER4.ZIP/TASKER.PAS/

Easy, Standard ML.

There is a version of the Oberon System compatible with the Oberon+ toolchain and IDE, see https://github.com/rochus-keller/OberonSystem

Only the language part of it

I like having a few different loops to keep code more readable. I think there should be two at a minimum for whether the condition is before or after the looped code.

I agree with the rest, but the rest of the language is great.

> extremely awkward and limited exception handling

The design is well-balanced and simple, and you can do essentially everything you can do with Java exceptions, just without complicated syntax constructions; see https://oberon-lang.github.io/2022/05/15/towards-exception-h... for more details.

> Four different loops

I think that having four different loops is better than jumping through four different hoops for different loop styles.

> - useless dinsctintion between procedures and functions?

Uh? care to elaborate?

No, much younger. See https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne...

That's like competing apples with oranges; some people like the former, some the latter, some both; if you prefer a Python like syntax an a much more complex language, then Nim is your choice.