[Oberon] Trivialising formality considered harmful

[August Karlstrom]

John Drake wrote:
> 
> --- August Karlstrom <fusionfive at comhem.se> wrote:

[snip]

>>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.
> 
> 
> Well you make a good point.  But then that
> further illustrates the difficulty of having
> a hard fast "rule" for capitilization.  

Common mathematical functions (with long traditions) are about the only 
acceptable exception I can think of. I wonder if the math function 
"dilemma" alone made the Java designers go with camel case (as opposed 
to Pascal case) for methods. On the other hand, the more I think about 
it, there is really nothing wrong with e.g. ArcSinH (or even ASinH), 
it's more a question of what you are used to.

> Hmmmm...I'm curious as to what things you think
> are non compliant in a typical Oberon-2 compiler
> like Pow for instance.  The extensions (like
> COMPLEX) are, of course, optional.  I don't
> know of a single Oberon-2 compiler that isn't
> compliant with what's written in the core
> part of the Oakwood document (which is
> basically the Oberon-2 language report).

I can't comment on POW since it's a Windows application and I'm using 
Ubuntu GNU/Linux. I'm also mainly referring to the Oakwood libraries. 
Basically, what I'm looking for is an actively developed free-standing 
open source (preferably cross platform) command line Oberon-2 compiler 
that comes with the Oakwood libraries. I want to be able to write 
portable programs and I want to be able to choose freely between text 
editors (presently Emacs would be my choice).

> Most compilers/systems I've used at least
> the Oakwood modules In, Out and XYPlane.  
> Typically Math and MathL are also there.
> Module Strings is where things get a bit
> hairy.  BlackBox and Linz V4 are compliant.
> ETH and Pow are not.  OOC implemented
> Strings, Files, In, Out, Math and MathL.
> (Basically everything except Input
> and XYPlane).  I like the way they
> named the modules, prefixing everything
> with "Oak".

The Oakwood modules were removed from OOC a couple of releases ago. OOC 
uses the names "Strings", "Files" etc. but these modules are more or 
less incompatible with the Oakwood modules. Confusion encouraged. ;-)

Here is how I see it:

There is a standard for the Oberon-2 language, namely the reports "The 
Programming Language Oberon-2 (March 1995 ed.)" and "The Oakwood 
Guidelines for Oberon-2 Compiler Developers". The Oakwood guidelines and 
in particular the Oakwood libraries may not be perfect, but they allow 
developers and students to write portable programs. If a compiler writer 
who develops an Oberon-2 compiler called "ABC" wants to include some 
fancier versions of the basic modules, the natural names for those are 
"AbcStrings", "AbcFiles" and so on. The Oakwood modules shall not be 
renamed. If they are the portability is lost. I think I'm really stating 
the obvious here.

>>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").
> 
> 
> Well, such a dogmatic approach doesn't even comply
> with the Oakwood document. 
> 
> =================================================
> The name Oberon has been trademarked by ETH in 
> the context of the operating system and the 
> language.  In order to respect the ETH trademark 
> any compiler that does not at least implement 
> ETH Oberon or Oberon-2 should not be referred to 
> or named as an Oberon or Oberon-2 compiler.
> When referring to features of ETH Oberon 
> in documentation it is acceptable to use 
> the terms Oberon or Oberon-2.  However when 
> referring to any compiler specific extensions 
> the term Oberon should be qualified with 
> an adjective.  For example :  "XYZ Oberon-2 
> supports complex numbers"
> =================================================

It's perfectly OK to implement the extensions described in the Oakwood 
guidelines or some other extensions, but I think a special compiler 
flag/option should need to be used to compile a module that uses these 
extensions, e.g. "--with-oak-extensions" or "--with-abc-extensions".

Anyway, Oberon-2 is an excellent design as it is. Let's use it! 
Personally I don't need additional experimental features. I would like 
Oberon to be (as least) as portable as C.

> Anyway, rather than trying to control the
> compilers (that will never happen, unless
> you write your own) I see the practical
> way forward as compiling a library of 
> modules without compiler/system 
> dependencies, or where such dependencies
> have been isolated as much as possible.

That's a good idea. I've actually started doing just that. The 
compiler/system dependencies are unavoidable as long as there are no two 
compilers that support the Oakwood way to interface to C. But anyway, 
that will only solve the problem for myself. I want to be able to 
recommend the Oberon programming language to others and I want them to 
be able (or even encourage them) to write portable programs.

>>[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.
> 
> 
> So then what happens with things like Math.arcsinh?
> If this is a compiler decision then there's no
> choice but to make it Math.ArcSinH.  It doesn't
> bother me either way (all lower case, or
> capitalized), but I think a compiler enforced
> convention would in general cause as many problems
> as it "fixed".

I agree with what Chris says in the quoted paragraph. I don't, however, 
believe in the compiler enforcing these rules. "To delegate the initial 
decisions to agreed rules to free-up mental creativity for real 
decisions" does not mean that the rules cannot be broken in exceptional 
cases. I see the mathematical functions as a (possible) exceptional case.


Regards,

August