OberonSystem
specification
OberonSystem | specification | |
---|---|---|
7 | 7 | |
39 | 89 | |
- | - | |
0.0 | 3.6 | |
7 months ago | 7 months ago | |
C++ | HTML | |
- | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
OberonSystem
-
Project Oberon (New Edition 2013)
> gain a deep understanding of it .. generate smaller subsets of the system
You can use the OberonViewer for this purpose with the original source code, or the Oberon IDE with a version of the Project Oberon System which runs with SDL on all platforms, see https://github.com/rochus-keller/oberon/#binary-versions and https://github.com/rochus-keller/OberonSystem/tree/FFI
-
The Oberon+ Programming Language
There is a version of the Oberon System compatible with the Oberon+ toolchain and IDE, see https://github.com/rochus-keller/OberonSystem
-
GCC 13 to support Modula-2: Follow-up to Pascal lives on in FOSS form
> that's just a compiler on other OSes, right?
It's possible to run an Oberon System with it (see https://github.com/rochus-keller/OberonSystem); it runs on all platforms and the generated C code could even made run as OS on an embedded system if need be; I currently also experiment with System 3 and alternative backends; but this is more for curiosity; from my humble point of view the OS topic is solved with Linux (which can also be configured for very low resource systems).
- Oberon: The tiniest but richest FOSS HLL and OS you've never heard of
-
Show HN: New Oberon+ to C99 transpiler for near native performance
Thanks. It's not only Oberon, but Oberon+ as specified here: http://oberon-lang.ch. You can even mix the traditional and new syntax, as e.g. demonstrated here https://github.com/rochus-keller/OberonSystem/tree/FFI.
-
New Oberon+ IDE based on the Mono CLR - lean and fast
Yes, Oberon+ is on the direct hereditary line to Oberon 90, Oberon-2 and Oberon-07. Here is more information about the language: http://oberon-lang.ch. There are also implementations of the Oberon System compatible with my compiler and IDE (the LuaJIT version so far): https://github.com/rochus-keller/OberonSystem/.
-
Oberon OS Walkthrough
Interesting article, but I would rather go for http://www.projectoberon.com/.
Oberon is a really nice and very well documented programming language and operating system to experiment with. Unfortunately not that much distributions are still available (most links seem to be dead).
If you're interested in the OS or the language, here is a platform independent, stand-alone version running on LuaJIT: https://github.com/rochus-keller/OberonSystem
There is also an integrated IDE with syntax coloring, semantic navigation, and a source level debugger.
The compiler supports small-case keywords and underscores in identifiers. I'm currently working on an extended version of the language.
specification
-
Niklaus Wirth, or the Importance of Being Simple
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.
-
Show HN: Towards Oberon+ concurrency; request for comments
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.
-
The Oberon+ Programming Language
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...
-
GCC 13 to support Modula-2: Follow-up to Pascal lives on in FOSS form
> 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....
-
V Language Review (2022)
> ...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...
-
Open source vs proprietary compiler
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.
-
Modern programming languages require generics
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
What are some alternatives?
Oberon - Oberon parser, code model & browser, compiler and IDE with debugger
tccbin
a2 - Active Oberon System (AOS), aka A2, and Bluebottle OS
vos - Vinix is an effort to write a modern, fast, and useful operating system in the V programming language
TheOberonCompanionCD - This is the original contents of the CD to the book "The Oberon Companion" (vdf, 1998)
vc - V compiler's source translated from V to C
inai - An experiment in structuring a NodeJS application *internally* using REST principles.
x-language-review - Reviews of up and coming programming languages
oberon-compiler - N. Wirth's Project Oberon RISC compiler ported to Go.
A2OS - Unofficial mirror of the ETH A2 repository
ved - 1 MB text editor written in V with hardware accelerated text rendering. Compiles in <1s.