[Oberon] Oberon usage

[Christian Demmer]

spir wrote:
>* Oberon-2 is unusable! *
>- no string type

Actually oo2c has a builin string type STRING. Did yu check it out? It
maps to Object.String which is in the library. I have never used oo2c
myself so I don't know how well it works.

>- no practicle output routine (write, or any other clear and praticle solution)

I think that's the way it should be. Ouput is system dependent and
varies greatly. It should not be build in the language but in the
library.

>- no possible code organisation !!! (*)
>(*) Procs must be "defined before use"; this principle may look sensible, but is simply wrong: an object's set of "slots" (fields, procs) forms a whole system of interrelated elements. It is not a sequence.
>Enabling sensible code organisation would require, at the module level only, procedure definitions to be parsed before type-checking of their input/output happens. Meaning the compiler is no more strictly single-pass, but overhead is certainly close to null.
>The issue is made worse because types that play together must be defined in the same module (else we get circular imports, even if imported elements are only used in implementation).
>

What abaout forward declarations of procedures? Or am I missing the
problem.  Btw. the complexity of a 2 pass compiler is a lot greater
than 1 pass as it requires an intermediate representation. Lots of work
you can avoid by using single pass.

>- no initialisation, no field default, no param default, no ...

initialisation should be done in the module body and is executed at
module load time.

Default values? Really? How can this work in safe way: IMHO never.

>Things I wish to use, that map to sensible notions, but can live without:
>* traversal (foreach, across) (replaced by hand-coded stepping)
>* parametric types/generics (replaced by supertype)
>* method overloading (replaced by more names) (default params would be better)
>* anonymous procs (replaced by loop and/or external def)
>* live type info (no solution) (**)
>* live scope access (what lives there?)
>* live module objects

I still don't understand your application field and your set of
requirements. It looks like you want a meta object system like Smalltalk
or Objective-C.
Or something like the Moessenboeck group did in 1996/97 with Oberon-2?
http://www.ssw.uni-linz.ac.at/Research/Papers/
loook for the term reflection

In my view, Oberon is from it's origin a system programming language
with ibraries and application programming build on top. The language
itself is small and has no hidden machinery beside the garbage collector
which is essential and the type info. 

Also the language and compiler is so simple that you can adapt and
extend the base language to different problem areas if you feel the
need. It has been done at ETH and elsewhere. Writing or extending an
Oberon compiler is not that difficult and gives you great freedom. ;-)

Greetings, Christian