[Oberon] Trivialising formality considered harmful

[Alan Freed]

On Wednesday 15 March 2006 05:27 pm, jan verhoeven wrote:
> 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.

I feel I need to add my two cents here.  In my libraries (CAT for O2 
and later CAPO for BB and AO) I use the name ArcSinh :-)  If you're 
not familiar with these libraries, check them out.  They are on the 
ETH server somewhere.

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

-- 
Alan D. Freed, PhD               AlFreed at ohio.net
-----
Bio Sciece & Technology          Alan.D.Freed at nasa.gov
NASA Glenn Research Center
-----
Dept. Biomedical Engineering     FreedA at ccf.org
The Cleveland Clinic
-------------------------------------------------------
The opinions expressed are my own and do not reflect
those of either NASA or the Cleveland Clinic.