5 ms·

As I described it to some folks recently, Go can be simply characterised as a slightly stripped version of the Oberon-2 (or Component Pascal) language, recast i

As I described it to some folks recently, Go can be simply characterised as a slightly stripped version of the Oberon-2 (or Component Pascal) language, recast in a C like syntax, and with a number of small additions. Removed from Oberon-2: Sets, Type Extension (classful OO scheme) Added by Go: Maps, Slices, Strings, Interfaces, Channels, Coroutines. Such that I suggested it is well worth reading the Oberon-2 language report. As to the coroutines, possibly Oberon-2 had them in its standard module library (as Modulo-2 did)?

Rochus 4y ago
> 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.
- dfawcus 4y ago
  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.
  - Rochus 4y ago
    > 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 http://www.oberon-lang.ch ); its specification is still small with about 50 pages.
- tanakian 4y ago
  coroutines module comes with Oberon S3 system. also Ulm's Oberon compiler has coroutines module.
  - Rochus 4y ago
    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.
    - pjmlp 4y ago
      System 3 is packaged as part of Active Oberon.
      - Rochus 4y ago
        Im looking for the original Ceres source code from 1992/1993.
      - Rochus 4y ago
        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 https://github.com/OberonSystem3/TheOberonCompanionCD. Note that there is no Coroutines.Mod; I neither found one in the A2 sources.
  - Rochus 4y ago
    Because of pjmlp's hint I just looked into the repositories https://github.com/btreut/a2 https://github.com/btreut/a2 and https://github.com/metacore/A2OS 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.
  - 4y ago
- pjmlp 4y ago
  And the unsafe vs SYSTEM package, and module initialization.
mseepgood 4y ago
> Added by Go: Maps, Slices, Strings, Interfaces, Channels, Coroutines. Also added by Go: Type parameters (generics)
- dfawcus 4y ago
  The characterisation was against Go 1.15 as that is what is current in the version of Debian we're using (11?). So other than noting that Go 1.18 adds Generics but they can be ignored due to us targeting 1.15, they weren't mentioned. As I recall the another thing we get in 1.18 (as a side effect of the Generics constraints mechanism) is a slight improvement in static checking for certain constructions of type switch.

Rochus 4y ago

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

dfawcus 4y ago
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.
- Rochus 4y ago
  > 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 http://www.oberon-lang.ch ); its specification is still small with about 50 pages.
tanakian 4y ago
coroutines module comes with Oberon S3 system. also Ulm's Oberon compiler has coroutines module.
- Rochus 4y ago
  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.
  - pjmlp 4y ago
    System 3 is packaged as part of Active Oberon.
    - Rochus 4y ago
      Im looking for the original Ceres source code from 1992/1993.
    - Rochus 4y ago
      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 https://github.com/OberonSystem3/TheOberonCompanionCD. Note that there is no Coroutines.Mod; I neither found one in the A2 sources.
- Rochus 4y ago
  Because of pjmlp's hint I just looked into the repositories https://github.com/btreut/a2 https://github.com/btreut/a2 and https://github.com/metacore/A2OS 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.
- 4y ago
pjmlp 4y ago
And the unsafe vs SYSTEM package, and module initialization.

mseepgood 4y ago

> Added by Go: Maps, Slices, Strings, Interfaces, Channels, Coroutines. Also added by Go: Type parameters (generics)

dfawcus 4y ago
The characterisation was against Go 1.15 as that is what is current in the version of Debian we're using (11?). So other than noting that Go 1.18 adds Generics but they can be ignored due to us targeting 1.15, they weren't mentioned. As I recall the another thing we get in 1.18 (as a side effect of the Generics constraints mechanism) is a slight improvement in static checking for certain constructions of type switch.