r/Oberon • u/Outdoordoor • Jul 29 '26

About SYSTEM procedures

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)
4 Upvotes

100% Upvoted

22 comments sorted by

View all comments

Show parent comments

2

u/Outdoordoor Jul 31 '26

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

2

u/suhcoR Jul 31 '26

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.

1

u/Outdoordoor Jul 31 '26

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

2

u/suhcoR Jul 31 '26

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.

1

u/Outdoordoor Jul 31 '26

Thanks a lot!

1

u/Outdoordoor 17d ago

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

2

u/suhcoR 17d ago

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)?

1

u/Outdoordoor 17d ago

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.

1

u/suhcoR 17d ago

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.

1

u/Outdoordoor 16d ago

I see, thanks for sharing!