There is a price to pay for this ‘verbosity’. It produces larger source files and requires a bit more typing. The latter problem can be overcome by means of a good editor which will check for incorrectly closed control structures and automatically add in the needed terminating word. Interpreters written to the COMAL80 standard accept ‘NEXT’ and replace it with ‘ENDFOR’. If this could be done 30 years ago it could be done now with compiled languages.

Zonnon corrects one of the unfortunate aspects of MODULA 2 and OBERON which reduce their readability: their insistance on upper case keywords. It does not implement ‘full closure’. Editors of code for interpreters to the COMAL80 standard accept lower case keyword and silently change it the upper case. I know of only one editor of Component Pascal, a descendent of OBERON 2, which does this. Upper case keywords were fine when everyone used character based displays.

If anyone ever does produce a new COMAL interpreter for the CLR I hope the use of upper case keywords will be dropped. A good syntax highlighting editor would be far better.

One of the factors in making the BBC Basic for Windows so successful is the built in editor. Not perfect but good.

RECORD…END, FOR…END, WHILE…END, REPEAT…UNTIL, IF…(ELSE)…(ELSIF)…END, etc.

I invite Les to reconsider his position on Oberon.

As soon as I get the first full pass for a program like Sphinx Adventure through the compiler, that is from BBC BASIC source code through to .NET byte code, I’ll publish the whole thing.

I intend to leave the extensive diagnostic outputs, such as the abstract syntax tree and control flow graphs in the compiler, since as you indicate they can be very useful in their own right.

The current implementation, in IronPython, is actually very slow. The PLY code, which although its plenty fast enough on regular CPython, seems to hit some corner performance cases in IronPython. Once its compiling is fast enough, but the start-up time is on the order of tens of seconds. If I can’t solve this problem I may reconsider recoding the compiler in F#.

Is there any chance you could be persuaded to publish that as a tool in its own right? It could be an extremely useful pre-processor for BBC BASIC for Windows, because it could draw attention to obscure programming faults which might otherwise only show up, at run time, long after the program is deployed.

I started to write my own syntax checker, for the same reason, but gave up because of the complexities and idiosyncrasies of BBC BASIC’s syntax.

Well, building this compiler is nothing more than an exercise in learning about how compilers are put together. To me its similar to how I used to play with Lego as a child – I would spend hours and hours constructing some complex mechanism, only to play with it for five minutes before moving on to the next challenge. The eventual result of having a compiler for BBC BASIC is not the goal – rather it is the journey of how I get there that interests me.

BBC BASIC makes for an interesting source language precisely because it was never meant to be compiled – and indeed various people in the thread above have pointed out that it will be very difficult, or even impossible, to do so. I don’t subscribe to the impossible view, but I am prepared to accept that it is difficult, because of its quirky and dynamic features.

I haven’t had time to post about progress recently (I’ll try to correct that at least), but right now I have a fairly complete compiler front-end for BBC BASIC with lexer, parser and type-checker, which will parse real-world BBC BASIC programs such as Acornsoft’s Sphinx Adventure! I’m currently working on the Control Flow Graph construction and analysis which will enable me to untangle all of the interesting stack-based control structures in BBC BASIC (e.g. omitted NEXT statements) into something compilable.

An interest in code generation is the other purpose of this project. I’ve been doing a lot of experimentation with .NET, and this project also provides a reason for me to build an good understanding of CIL (MSIL as was) and the Common Language Runtime.

I spend my working hours being paid to make brutal/pragmatic software engineering decisions on a 3 million line C++ project, so spending a little time in the evenings now and again tinkering with a relatively small IronPython compiler for BBC BASIC is not something I take too seriously, and pretty harmless at that.

Ultimately, I don’t have a single BBC BASIC program of my own that I need to, or even want to compile, with this tool. I can’t retrieve my corpus of BBC BASIC programs I created in my formative years from the seized-up hard-drive in my old Acorn A4000 or any of the other Beebs or Arcs in in the family computer museum. Maybe eventually, I’ll get some of the Acornsoft text adventures to compile and run…

This is an interesting site/thread. I too had an urge about ten months ago to look into BBC BASIC – I spent formative years using it to write an awful lot of BASIC/6502 software without consciously stopping to appreciate how neat the interpreter itself was.

Perhaps I’m more brutal/pragmatic with such things but for me, rather than trying to create a BBC BASIC “to the nth degree” it’s been quite instructive and a lot of fun to simply knuckle down and build a BBC BASIC interpreter (using C) without worrying about backwards compatibility or the desire for the utmost efficiency.

IMHO I’d suggest that the efforts underway here are certainly well intentioned, but maybe a little askew? To explain: if the aim of all this is to ultimately produce a compiler, then BBC BASIC might not be the best language to base your efforts on. Whereas if you want to effectively emulate what Sophie Wilson did all those years ago, throw away the thought that it has to be compiled and lose yourself in the fun that is writing an interpreter!

Whatever you choose to do though, wishing you all the best.

The whole system is designed for ease of use. e.g. assignment is := but = is quietly converted to :=, cosmetic words like DO are inserted automatically to improve readability. Key words are automatically forced into upper case, others into lower case. This means that if you can touch type you can largely forget the shift key or CapLock keys. This of course is a function of the editor, but it shows the ‘ease of use’ approach.

COMAL does not have a lot of intrinsic data types, integer, real, string and boolean, although the latter are hardly noticed. Languages which do have a lot of types need GOOD type conversion functions which should check for overflow/underflow. Some don’t. Because the ’sizes’ of the two numeric types can be made compatible intrinsic type conversion is not a great problem.

COMAL87 includes a TRAP.. HANDLER.. ENDTRAP structure for errors. Much nicer than BASIC.

I could go on! There are few books on programming in COMAL. I just managed to get hold of Atherton’s ‘Structured Programming with COMAL’ today via Amazon. It does not have a grammer.

You could look at OpenComal on Jos Visser’s. There is a grammar in the documentation see ‘Guide’

He also provides the Source Code for his OpenComal system(s). I have tried the Win32 OpenComal system and it works a treat. Nostalgic too with its line editor!