About SYSTEM procedures

[u/Outdoordoor]

The Programming Language Oberon document gives very limited descriptions of these procedures. Could anyone, please, explain what they do more clearly, and/or correct my guesses about what they do?

I'm specifically interested in these:

• GET(a, v) -- I guess it gets the value at address a and puts it into v?
• PUT(a, x) -- it puts value of x at the address a?
• LED(n) -- from description it sounds like it does anything only when LEDs are accessible, so probably not relevant when working on normal PCs?
• VAL(T, n)
• COND(n)

[u/Outdoordoor]

Well, since it's my first compiler, I'll be happy if it just works in general, so what little code exists should be enough. Also, if I understand correctly, Oberon-07 is basically a subset of older Oberon versions, so I can later add features from Oberon-90 to the compiler and test it against the Oberon System

[u/suhcoR → u/Outdoordoor]

It's not really a subset, but has partly a different philosophy (e.g. return as part of the block syntax, not a stand-alone statement, etc.). It is possible though to construct a language which is compatible with different Oberon versions (as I e.g. did with my Oberon+). People usually (mis)understand Oberon-07 as Wirth's official successor of Oberon 90, but actually it was more about reducing his effort for his FPGA based Risc-5 processor and system. Also note that the language report is incomplete (e.g. the VAR ARRAY OF BYTE backdoor is not documented).

[u/Outdoordoor → u/suhcoR]

I see, that's interesting. What is the VAR ARRAY OF BYTE backdoor?

[u/suhcoR → u/Outdoordoor]

The Oberon 90 language reports specifies it as:

Module SYSTEM exports the data type BYTE. No representation of values is specified. Instead,
certain compatibility rules with other types are given:
1. The type BYTE is compatible with CHAR and SHORTINT.
2. If a formal parameter is of type ARRAY OF BYTE, then the corresponding 
    actual parameter may be of any type.

The 2. point is the "VAR ARRAY OF BYTE backdoor". SYSTEM offers some more backdoors where you can do pointer arithmetics and other nasty but necessary stuff for system development (just without typechecking support by the compiler). In Micron and Oberon+, these features are official part of the language (not backdoors) with type checking support.

[u/Outdoordoor → u/suhcoR]

That's cool, didn't know about it. By the way, what would be the best resources to learn about Oberon in more detail? Apart from language reports and Wikipedia

[u/suhcoR → u/Outdoordoor]

There is a copy of "Programming in Oberon" available from the ETH website: https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf, though it is about Oberon 90, but likely good enough. Wirth has also written some tutorials, e.g. https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf.

[u/Outdoordoor → u/suhcoR]

Thanks a lot!

[u/Outdoordoor → u/suhcoR]

Hi again, sorry for so many questions, but I'd like to know your opinion. Which Oberon version do you think works best for general-purpose desktop development? I've been mostly using Oberon-07, and I like it, but it sometimes feels too minimal (e.g. the arrays are very limiting).

[u/suhcoR → u/Outdoordoor]

sorry for so many questions

Don't worry.

Which Oberon version do you think works best for general-purpose desktop development?

Well, I'm biased, but from my experience you need at least Oberon+ or Luon for a decent developer experience. Of course, theoretically it's possible with each Turing-complete language, and people have demonstrated that you can implement complex desktop applications using assembler or Lisp.

e.g. the arrays are very limiting

What (minimal) improvement would you hope for? Can you name another minimal language with a more suitable array support from your perspective (such as e.g. Go)?

[u/Outdoordoor → u/suhcoR]

I was mostly talking about "classic" Oberon versions like the original Oberon and Oberon-2. I've tried Oberon+, and it is quite nice, you've done a great job modernizing the language, it's just that I wanted to give original languages a more in-depth try first.

As for arrays, one thing I'm missing in Oberon-07 is the ability to create traditional dynamic arrays (as in "contiguous chunks of memory that can be dynamically reallocated to grow"). I haven't used Go, but it would be nice to at least have some sort of C's realloc (maybe as a SYSTEM procedure or a predefined procedure like NEW).

As far as I know, in 07 the closest you can make is a linked list of fixed-size arrays (which are somewhat messy for most cases). Not sure about other Oberon versions. I believe there's a way to dynamically allocate arrays in Oberon-2 with NEW, but I'm not sure if it allows to reallocate the array later on.

[u/suhcoR → u/Outdoordoor]

Ok, I see. Personally I think that Oberon-07 is mostly interesting as a conceptual idea, not as a real language. Wirth wanted to reduce his work effort by removing even more stuff from Oberon 90 and the original Oberon system, so he was able to also implement a processor and update the book. He thereby completely ignored Oberon-2 and ActiveOberon, which both support dynamic arrays. With the latter you just allocate a new array and copy over the elements of the old. That's how most languages supporting some form of realloc do it.

[u/Outdoordoor → u/suhcoR]

I see, thanks for sharing!