[Oberon] Trivialising formality considered harmful

[August Karlstrom]

John Drake wrote:
> 
> --- easlab at absamail.co.za wrote:

[snip]

> A concrete example.  It's irritating to me
> that the ETH Math module uses lower case for
> the procedure names.  
> 
> http://www.oberon.ethz.ch/ethoberon/defs/Math.Def.html
> 
> It's doubly irritating when one considers
> that there was no rational reason for this.

One reason may be that these functions are commonly written in lower 
case in mathematics. Moreover it feels kind of awkward to write e.g. 
arcsinh (arcus sinus hyperbolicus) as ArcSinH. To use Arcsinh would be 
inconsistent.

> The ETH Math module is moduled off of the
> Modula-2 ISO math module which uses upper
> case.  Also Math procedures are upper case
> in the Oakwood guidelines (the one and only
> serious attempt to standardize Oberon compliers
> and libraries.)  
> 
> http://www.comp-inspirations.com/docs/oakwood.pdf

No, the Oakwood math procedures are in lower case for sure.

It's ironic that despite the relative smallness and simplicity of Oberon 
and the Oakwood libraries, as far as I know, there is *not a single* 
freestanding Oakwood conforming Oberon(-2) compiler. Not even Oakwood 
library conforming.

What the language needs is a complete Oakwood compliant compiler that 
supports standard Oberon-2 and nothing else! If you want lots of extra 
features you can go Java and I don't see why you appreciated Oberon in 
the first place. (Here, "you" is of course a general "you").

[snip]

> FAR more irritating to me are the ETH modules
> Strings and Dates.  While they got the cases
> right, they got the functionality wrong IMO.
> I started to include what I don't like about
> them in this reply, but I realized that would
> make it too long. ;)  I'll put that in a 
> seperate post.

Please, do! The only oddities I have noticed are the procedures In.Open 
and Out.Open. On mainstream operating systems the IN and OUT streams are 
always open.

[Chris Glur said:]
>>The only way to advance is to delegate the initial
>>decisions [eg. the
>>syntax of identifiers- uppercase..start-char
>>...etc.] to agreed rules,
>>to free-up mental creativety for REAL decisions.   

I agree 100 percent.

> And yet every other programming language on the
> planet has people making all sorts of creative
> "REAL" decisions without resorting to
> artificially forcing a case convention.

I don't see anything artificial about it. If I want to use a library 
that has its own conventions, I have to waste time and study those 
conventions and if my client module uses libraries with different 
conventions the program text will be inconsistent (and look ugly as 
well). If the language designer defines the conventions and everyone 
adheres to those it's all really a non-issue. In this case Eiffel got it 
right.


August