[Oberon] Oberon usage

[spir]

On Sat, 10 Jul 2010 18:46:47 +0200
chris at gcjd.de-web.ws (Christian Demmer) wrote:

> spir wrote:
> >Sorry for coming back to the topic, but I still cannot figure out how open arrays are supposed to be used in Oberon, without any form of literal notation.
> >
> >PROCEDURE Sum(reals:ARRAY OF REAL) : REAL ;
> >PROCEDURE Max(reals:ARRAY OF REAL) : REAL ;
> >How can one pass [1,2,3] or [a,b,c] to one of those procedures?
> 
> VAR
>   in : ARRAY 3 OF REAL;
>   s  : REAL;
> BEGIN
>   in[0] := 1; in[1] := 2; in[2] := 3;
>   s := Sum(in);
>   
> But probably that is not what you really want.

You are right ;-)

> I have the impression you
> are trying to emulate the variable number of arguments to a function
> feature. That won't work in Oberon.
>
> >
> >TYPE STRING = POINTER TO ARRAY OF CHAR ;
> >PROCEDURE concat(ARRAY OF STRING) : STRING ;
> >PROCEDURE write(ARRAY OF STRING) ;
> >
> >How can one concat or write ["Hello, ", name, ", how do you do?"]?
> 
> I think you can't. Constants are mostly compile time features (strings
> beeing somewhat special) in Oberon compilers. You cannot get a pointer
> to a constant.
> 
> >Is there an answer?
> >If not, how to achieve that, or anyhow work around the issue?
> 
> Hmm. I am not sure what the issue is. Probably you can describe what you
> are trying to do on the problem level. Then it would be easier to
> suggest an Oberon style solution. 

Example usage: Say Sum is a slightly more complicated routine. How can one prototype and check it? How can one write a test suite for it? More generally, how are Oberon programmers supposed to explore and control possible solutions for their programming needs?
The above is in my sense _not_ a solution. (It can only encourage not testing, not exploring, etc...)
I am sure now there is no solution. After a few weeks intensively using Oberon (or trying), I can say that, in my sense:

* Oberon-2 is great! *
By far the best language in its category.
- structured code from Pascal
- structured data from Pascal, rightly enhanced by type extension
- modularity from Modula, concretely better implemented
- a wonderfully simple OO system
- numerous secondary features left out (but I regret enums)
- unsafe features clearly put apart
- 

* Oberon-2 is unusable! *
- no string type
- no literal notation for arrays and records/objects (center := Point{x:=0,y:=0};)
- no practicle output routine (write, or any other clear and praticle solution)
- no possible code organisation !!! (*)
- no initialisation, no field default, no param default, no ...

All of these elements not only map to real modelling notions (which means one needs them anyway & must write tedious workarounds), but make a language clearer and code simpler; without compromising with safety or any other wishable quality. Their absence, for me, transforms programming into a painful experience.

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



Denis


(*) 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).

(**) I mean both a way to get the type of a value, and such types to be live, accessible objectS. Oberon has all needed features to implement this in a clear, friendly, and simple way (TYPE = RECORD); but the system cannot be written on top of existing Oberon (else I would have written it already), since type data must be generated by the compiler.
In the solution as presented is a paper (for got the title), type data are not Oberon values/objects. The method is very low-level (based on memory address offsets).
________________________________

vit esse estrany ☣

spir.wikidot.com