[Oberon] (no subject)

[Frank van Riet]

Most of the traffic on the mailing list is devoted to the OS aspects of
Oberon. I'd like to digress from
this for a while and get some feedback on the language itself. First of
whatever I say is only aimed at
Oberon 1 and 2 i.e not Active Oberon, although some of it may be applicable.
I have used Oberon in developing
commercial software for some time. I'd like to know if anyone else has been
doing the same. I have the following
comments on some limitations that I have experienced.  Some of my comments
are specific only to the ETH
implementation of Oberon while others are fundamental to the language.

Please note that this is not an attack on the language, I'm asking :)

Oberon per se:
1) The lack of unsigned data types is a great annoyance. Sure there are ways
of getting around this, but
	I cannot see that Oberon has gained anything as a language by not
supporting unsigned types. Sure
	it makes the compiler simpler, but not significantly. Perhaps it is
because of the potential complexities
	of mixing signed and unsigned types in expressions ?  This also does
not seem like a convincing argument.
	It could simple have been disallowed.

2) In developing large systems for different platforms, conditional
definintions are a real life saver. 
	(e.g. (Borland?) Pascal's $IFDEF) I'm not sure if this is a language
or an implementational issue, 	although I suspect it is the former. Apart
from having code for differing platforms. Conditionals will 
	get rid of the clutter of debugging code

	CONST
		debug = TRUE;
	;;;
	IF debug THEN ....

	which is painfully inefficient.

The below is perhaps more related to the ETH implemetation. Others may very
implement these differently.

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

4) Pragmas are only allowed on a per module basis. It would be very usefull
to disable type guard checking
	in many cases, simply for the sake of efficiency. True it
compromises security, but why allow it
	at all then.


As an aside does anyone know whether read-only exports are still supported ?
  
  Frank
---------------------------------------
Frank van Riet (Software Developer)
Datavoice  (Pty) Ltd 
Snail mail	PO Box 582
		Stellenbosch 7599 
		South Africa 

Tel         +27 21 888-2118
Mobile	+27 82 970 5704

Web 	      http://www.datavoice.co.za
----------------------------------------