[Oberon] Trivialising formality considered harmful

[jan verhoeven]

Op Wednesday 15 March 2006 22:24 schreef August Karlstrom:

 > there is really nothing wrong with e.g. ArcSinH (or even ASinH),

I like the ArcSinH since the capitals draw attention to the places where 
the significant things occur. It doesn't look good in a classroom or 
thesis. 

 > 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 think many more people are looking for that. Although most of the 
activity here is with respect to BlueBottle and the derivatives.

I'm just a chemical engineer who got lost in programming. But I'm working 
on my m4m compiler: Modula for Microcontrollers. Since I lack a suitable 
background things take longer than I expected or hoped.
Still, I learned a lot from the various forms of 'Compiler Construction' 
(by our Grand Master) and also the chapter about the compiler in 'Project 
Oberon' was very clarifying to me.

These Oberon books have converted me. The project is still called m4m but 
it will be an Oberon compiler for microcontrollers. Oberon0 for starters. I 
hope to slowly extend the language to something resembling true Oberon in a 
few months after completion of the first m4m version. Continuous code 
refining, as our Grand Master calls it.

As things look now, I want to have an m4m frontend that produces code for a 
virtual stackmachine, plus multiple backends that convert the stackmachine 
code to the target processors of my choice (Z80, GameBoy Color CPU, GameBoy 
Advance CPU, AVR Mega 16, Motorola 68K) and I will leave the PIC to other 
developers.

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

That rules out the XDS system.

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

Good thinking. 

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

The obvious is not always thought of in the first place. Remember the 
Einstein/Wirth motto: make it as simple as possible, but not simpler. 

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

That's what made gcc into the current monstruous program it is. It's a good 
C compiler, but it's just too big with too many flags. 
Why not make two compilers? One true Oakwood compiler and one or more 
others which are better, at least according to their developers. Having a 
choice is always good. 

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

Here's a quote from Dennis Ritchie that I dug up lately:

[Dennis] 

  C has been characterized (both admiringly and invidiously) as a portable 
  assembly language, and C++ tries to lift its level to object orientation 
  and a more abstract approach to programming. 

  The faults of both (in recently emerging standards) seem to be excessive 
  ornamentation and accumulation of gadgetry. They both have a certain 
  spirit of pragmatism, of trying to understand what's really needed. 

URL: http://www.linuxfocus.org/English/July1999/article79.html

C and C++ are too big! Lean is better. 

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

Which brings me back to another topic: it's apity that the great Oberon 
books are out of print. 
Although you still can get one at http://www.mediasell.de.

But the ACM book is only available as a PDF file. 

-- 
Met vriendelijke groeten

Jan Verhoeven
http://fruttenboel.verhoeven272.nl