🚀 go-pugleaf

Okay, Simon Johnston just pointed me to Intermetrics efforts on an Ada 95
to Java bytecode compiler, so I probably should elaborate on my previous
posting:

First, note that I said "readily be done".

One could actually implement Oberon's semantics on the Java virtual
machine, but the performance characteristics would be horrendous.

For example, since the Java virtual machine doesn't allow stack allocation
of records or arrays, you would just have the compiler emit code to heap
allocate them. This will behave essentially the same but will result in far
more frequent garbage collection than in Oberon.

Similarly, since Java doesn't support embedding structured types inside
other structured types, you could simply silently allocate a separate heap
block for each embedded construct. An array of N records results in N+1
heap allocations, one for the array and N for the individual records.

VAR parameters make things particularly nasty. Since the Java virtual
machine has no support for passing values by reference, you have to pass an
object pointer. This means that even primitive values like integers have to
be stored as heap allocated objects if you want to pass them as VAR
parameters. Since you won't know whether a public record field will ever be
passed as a VAR parameter,  all public record fields will need to be stored
as separate heap objects.

The list goes on. Procedure types need to be classes and hence any
procedure eligible for use as a procedure variable needs to be a class.
Nested procedures will require the introduction of classes for their outer
scopes.

So, you could probably get Oberon to run on top of the Java virtual
machine. The results, however, would not be pretty and probably would not
well serve the Oberon community since it would make Oberon's performance
characteristics look significantly worse than Java's.

It could be that I've missed something, but without the ability to take
addresses of data on the stack or within a heap block and without the
notion of procedure pointers, this list of problems looks pretty imposing
to me.

Mark