[Oberon] Trivialising formality considered harmful
AlFreed at ohio.net
Thu Mar 16 03:02:48 CET 2006
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
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
> > 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:
> 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.
More information about the Oberon