[Oberon] Oberon usage

[Bob Walkden]

> * Oberon-2 is unusable! *

And yet, many people are using it.



> -----Original Message-----
> From: oberon-bounces at lists.inf.ethz.ch [mailto:oberon-
> bounces at lists.inf.ethz.ch] On Behalf Of spir
> Sent: 11 July 2010 15:43
> To: oberon at lists.inf.ethz.ch
> Subject: [Oberon] Oberon usage
> 
> 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
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon