> Go can be simply characterised as a slightly stripped version of the Oberon-2
Well, not really; there are not much similarities between Oberon and Go besides the receiver syntax of Oberon-2 bound procedures (which was invented by Mössenböck btw) and the fact that both are garbage collected. In your list "removed from Oberon" you should add type inclusion (Go doesn't even have implicit coercion); there is an intersection of keywords and also := appears in Go, but the semantics are rather different; coroutines were defined as an option in the Oakwood guidelines, but by different people than the language authors; I never met an Oberon compiler which implements them.
Yeah - I skipped the type inclusion, as I just viewed it as a misfeature, assuming we're talking about the implicit casts between different number types.
As to ':=' in Go, yeah - a new thing over Oberon-2.
Since assignment in Go uses C style '=' whereas Oberon uses Pascal style ':=', I certainly was not confusing them.
The characterisation came about because of an implicit complaint (from C programmers) about a choice of Go for a project. Now never having used Oberon-2, but having read the report, I used the comparison to a stripped version it as a way of showing how simple the language actually was. Something like 25 pages being sufficient to describe it.
The things which struck me were:
O2 MODULE becomes Go package (and similar syntax use)
O2 NEW retained as Go new, but &Foo{} generally preferred
O2 export of symbol via '\*' tag becomes Go export via capital letter.
O2 Open arrays replaced by Go slices or strings.
O2 WITH because Go 'type switch'
O2 'type guard' becomes Go 'type assertion'
O2 VAR parameters to PROCEDURES become Go pointer parameters to funcs
But in the end it is very much a subjective thing, so unless using the non classful parts of Oberon-2 reveals significant differences, I'd have to stick with my evaluation.
> Something like 25 pages being sufficient to describe it.
Wirth attached importance to the fact that there are only 16 pages; on closer inspection, however, one realizes that not everything has been specified and the omission of redundant descriptions easily leads to ambiguity in the given writing style.
> in the end it is very much a subjective thing
The differences and little similarities, as far as specified, are objectively ascertainable. But of course there are far more important things. From my point of view Oberon (including Oberon-2 and especially Oberon-07) is too minimalistic for non-academic projects anyway. That's why I threw my hat into the ring with Oberon+ (http://www.oberon-lang.ch ); its specification is still small with about 50 pages.
Thanks. I don't know the Ulm compiler, and I unfortunately don't have System 3 (can you please provide a link with the source code and/or a working Linux binary?), but I have the source code of V2 and V4 (both ETH and Linz versions, from 1992 to Linz 1.7) where there are no coroutines.
In case you're interested: I realized that I indeed already have System 3 binaries and source code in my collection; unfortunately the original links at ETH don't work anymore; but I have a physical copy of the book "The Oberon Companion" which includes a CD; I now have uploaded the CD contents to Github; here it is: https://github.com/OberonSystem3/TheOberonCompanionCD.
Note that there is no Coroutines.Mod; I neither found one in the A2 sources.
Because of pjmlp's hint I just looked into the repositories https://github.com/btreut/a2 and https://github.com/metacore/A2OS, but didn't find a coroutines module. I'm aware that Active Oberon (Patrik Reali, 2004) includes concurrency, but this is a different language than the one used for System 3.
Well, not really; there are not much similarities between Oberon and Go besides the receiver syntax of Oberon-2 bound procedures (which was invented by Mössenböck btw) and the fact that both are garbage collected. In your list "removed from Oberon" you should add type inclusion (Go doesn't even have implicit coercion); there is an intersection of keywords and also := appears in Go, but the semantics are rather different; coroutines were defined as an option in the Oakwood guidelines, but by different people than the language authors; I never met an Oberon compiler which implements them.
reply