Polymorphism, threading, ...

srenner@mail.ru — 2000-05-06 17:52:51

"Both of these languages

which I proposed would have to be written in themselves (although it

would

be permissable to write the second one in the first).



And GC is not trivial no matter what you do :-), and leaving it to

some

other language doesn't let you take advantage of how your language

behaves."



Probably true but not the only consideration. Building a VM in Oberon

for a language like Squeak, which already has its own memory model and

way of performing GC, might be clumsy. One would either have to use

Oberon much as one would use C, using the pseudomodule (actually

implemented in the compiler) SYSTEM to evade type-safety, or make

major changes to the VM, leaving it incompatible with images from

other systems. But we are not in the position of a Squeak porter. Joy

has no preferred memory model at this time, and no legacy images that

must be run bit-identically. If every box is an Oberon POINTER TO

RECORD, then GC is trivial enough to be called trivial. This wouldn't

be the best way to write Joy for a minimal (OTA-like) environment,

but 

is the best way I can think of otherwise. If we don't use Oberon, what

shall we use? C? Ugh! This is 21st! Leave C in 20th! 



C

****

efficient

portable to anything



Oberon 

****

efficient

portable to x86, ARM, can be ported elsewhere

typesafe

GC



I agree that there is an attraction to running on bare hardware.

(Which is why I prefer to run Oberon with Oberon as the OS). But it

will be far easier to make a Joy-like VM with static typing and

polymorphism in Oberon than in itself/over bare metal, and speed is

not important (not that I am conceding the spped argument) at this

point.



I suppose the new language will have to have a name besides "Joy-like

VM". "Surprised by Joy?" Suggestions?



sr



PS I am not making this up!