specification VS vos

Great, thanks!

There are books online for free, e.g.

https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf

and https://ssw.jku.at/Research/Books/Oberon2.pdf

Oberon+ is a superset of Oberon 90 and Oberon-2. Here is more information: https://oberon-lang.github.io/, and here is the current language specification: https://github.com/oberon-lang/specification/blob/master/The.... I already had valuable feedback here on HN concerning the channel extensions. Further research brought me to the conclusion, that Oberon+ should support both, channels and also monitors, because even in Go, the sync package primitives are used twice as much as channels. Mutexes and condition variables can be emulated with channels (I tried my luck here: https://www.quora.com/How-can-we-emulate-mutexes-and-conditi...), but for efficiency reasons I think monitors should be directly supported in the language as well, even if it might collide with the goal of simplicity.

Feel free to comment here or e.g. in https://github.com/rochus-keller/Oberon/discussions/45.

Oberon+ already has generics and they should play well with my present proposal: https://github.com/oberon-lang/specification/blob/master/The...

> Most of the time people don't want unbounded and unknown lifetimes on the executors, but instead want to be able to see that directly in the code.

You mean something like join? This can easily be done by adding a channel on which each thread of the interesting group sends when finished. Thanks for the link, I will have a look at it.

A proc is a function with no return.

A function is a function that returns something.

Oberon+ keeps it's predecessors' idiotic distinction, but takes it one step further: both functions and procedures are decalred with `proc` or `procedure`, functions are `proc`s that have a return type.

And yet:

- procedure calls don't have to specify parameters apparently, but function calls must specify all parameters

- functions cannot be used in Oberon+'s weird exception handling. [1] You do a call with `PCALL(res, P, args)` where res is a variable that will hold the result of the exception if it happened, and P is the procedure. You cannot pass functions (aka procedures which have a return type)

As the spec so wonderfully says [2],

--- start quote ---

There are two kinds of procedures: proper procedures and function procedures. The latter are activated by a function designator as a constituent of an expression and yield a result that is an operand of the expression. Proper procedures are activated by a procedure call. A procedure is a function procedure if its formal parameters specify a result type. Each control path of a function procedure must return a value.

--- end quote ---

[1] https://github.com/oberon-lang/specification/blob/master/The...

[2] https://github.com/oberon-lang/specification/blob/master/The...

> Although the relative plethora of Oberon variants [..] suggests that maybe it was still not quite fully evolved.

That's a reasonable conclusion, but one has to consider that most variants came from academia and focused on specific scientific questions, not on the adaptation to practical needs of the industry.

> it would be possible to re-unify them under one standard, in the way that Common Lisp managed to do

I did that with Oberon+ which unifies Oberon, Oberon-07 and Oberon-2.

It also includes ideas of Component Pascal and Active Oberon (though I don't like the syntax of these two languages very much).

See https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w... and https://github.com/oberon-lang/specification/blob/master/The....

> ...from the point of definition to the end of the scope..

Not sure what you mean. Is it about the fact that all variables are declared in the header of the procedure, i.e. not somewhere in the body as e.g. in C# or Java? This is actually the same with Active Oberon and Modula-3 (though the latter can have nested blocks like Ada). In case you mean that the order of declarations is relevant, Oberon+ assumes at least a two phase parser by design; a declaration sequence can contain more than one CONST, TYPE and VAR section in arbitrary order, interleaved with procedures, and the order of declaration is not relevant; see e.g. https://github.com/oberon-lang/specification/blob/master/The...

PL/SQL and Ada are powerful languages but rather complex and likely not well suited for beginner courses. Delphi is great, but actually I prefer the type-bound procedure notation introduced with Oberon-2 and also adopted by Go. The original Oberon syntax is a bit old-fashioned, but there is a more modern variant, Oberon+, which supports both the old and more modern syntax and a few more streamlined Oberon-style features, and should appeal more to the younger generations. See https://github.com/oberon-lang/specification.

Here is an example: https://oberon-lang.github.io/, see section Generic Programming; note how the modules have type parameters and how generic modules are instantiated by the import declaration in section Object Oriented Programming.

Here is the specification: https://github.com/oberon-lang/specification/blob/master/The...

Here is a discussion why it is designed like this

The creator of V made some big claims that raised a few eyeballs, they've gained a reasonable following over the years, have a pretty serious looking website (https://vlang.io) a beer-money level Patreon following and some corporate partnerships/sponsors. However have experienced some pretty brutal takedowns over the years, with some of the bolder claims about the language/compiler being exposed as being.

A word I keep seeing in relation to V is "aspirational" - the project aspires to be a serious language with some major features, so I think it's fair to approach it with a more critical eye than one would a kid's side-project. I think HN would have been pretty understanding if they were open about the state of the various features and were a little less defensive when they encounter articles that treat it like a Real Language and review it as such. If the authors don't want this kind of feedback they can just say front-and-centre (or on their FAQ @ https://github.com/vlang/v/wiki/FAQ) "this is a toy" or "this is pre-alpha"

Autofree has existed for years and can work. Here is a demo. It is used in V's Vinix OS, Ved, and other applications. Part of the issue is there are detractors who purposefully spread misinformation nor know about its other memory options, and the other part is understanding how to use it.

Another option is to write the kernel in V. Vinix is an OS written in V. You can use it for reference when building your project.

And that's why vinix [1] is full of manual free call? That tells how good autofree is, isn't it? Can you compile v compiler with autofree? Last time I checked, you can't.

[1] https://github.com/vlang/vinix/search?q=free&type=code

vweb, volt, and ved are not a "little more than alpha"

yes, the os is being developed in V, and it can already run bash, GCC, G++, and Doom.

https://github.com/vlang/vinix

It's a great concept, but languages like Rust (https://www.rust-lang.org/), Zig (https://ziglang.org), Vlang (https://vlang.io/), etc... are already running with a similar idea to being easy to interact with C and are viable alternatives to it as well. Vlang even created its own OS, Vinix (https://github.com/vlang/vinix), to show its capabilities in this regard.

Seems to me, Cello would be more for those C programmers that didn't want to try the various alternative languages that are now out, and happen to agree with its developer's interpretation of what high level constructs would look like. The point of these alternative languages is to offer features that C doesn't have or to implement them in easier or clearer ways.

Vinix shows the capabilities of V on bare metal, in additional to it being useful for high-level programming as well. https://github.com/vlang/vinix