[Oberon] (no subject)

[muller at inf.ethz.ch]

"Frank van Riet" <Fvanriet at spescom.com> wrote:
> 3) Dynamic array headers: Why was the decision made to to stick the header
> in the middle of the structure
> 	and not in-front as with other structures. Not only is it
> non-intuitive nit having the pointer point
> 	to the firts element, but it would also make language
> interoperability very difficult. Let alone the
> 	nightmare of porting older code in which this was not the case...

I think the heap structures are evolutionary and there were some 
backward-compatability issues.  Remember that the Ceres GC didn't 
support pointers in array elements at all.  Re-doing and simplifying 
the heap structures would be a nice improvement.

> Again I'm doing system programming, where we really don't use GC, so if I
> want to pass a
> pointer to an array to a C rountine (say) I don't want the GC specific stuff
> to get in the way.

A workaround is to declare the parameter of the C procedure as a LONGINT 
in the Oberon signature and pass the address of the first element:

  SomeProc(SYSTEM.ADR(arrayptr[0]))
  
> To conclude. Let me be clear about this. I work in Oberon every day, and I
> enjoy it. That does
> not mean that one should not think about what goes on behind the scenes, and
> what the reasons
> are (or agree with all of the choices). If anything this will only make us
> better programmers.

Good to hear.  I wonder how many of us here use Oberon every day?

> Would anyone who'd like to write
> a runtime system in Java please raise their hands  :)

This is not so far-fetched.  Java is used for embedded systems work,
and there are even Java VMs written in Java (with some interesting
bootstrapping): http://researchweb.watson.ibm.com/jalapeno/

-- Pieter

P.S. The absence of unsigned numeric types in Oberon is one of the perennial
topics in Oberon discussion forums.  Search a bit in comp.lang.oberon
a few years back:
  http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.lang.oberon
Some others are: the absence of enumerated types, System 3 vs. V4, 
the 3-button mouse interface, the flat file name space, the absence 
of processes, extending the user base.  So much for progress :-)

--
Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich
Native Oberon OS: http://www.oberon.ethz.ch/native/