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!

Other more important projects have had to take priority over much of the past year, but you have caught me at a good moment! I’m currently working on the type-checker and flow-graph analyser of the compiler, and making good progress. Soon I will be a position to put up some new posts detailing the latest activity…

You seem pretty keen on a COMAL front-end, and I have to agree that COMAL is what BBC BASIC should have been. COMAL programs will have much saner structure than what BBC BASIC allows you to get away with. Can I ask why COMAL is so important to you? Providing a COMAL front-end should be relatively straightforward. Do you have a COMAL grammar?

Stay away from the DLR as a runtime in that case.

If you’re mostly doing Java, I suppose. But there’s so much useful stuff written in CPython that Jython feels like a second stringer.

I do both, and Jython is great, but CPython is more useful for general work. Jython is only really useful for Java scripting. I would never write an entire application in Jython, I would wind up implementing most of the core in Java for speed and reuse.

You are quite correct. I’ve just thrown the text version of Rheolism at my parser and it chokes on “dVDUd”, “RNDMOD7″, “TRUETO1″ and “rANDSGNt” before it gets too confused to continue.

Adding support for pre-tokenized files isn’t a priority for me, but it would be straightforward to convert a the encoded token stream into the PLY Lex objects I user today to feed into my parser. If I do get round to this Rheolism will provide an excellent test!

The multi-line versions of Rheolism and Extra Rheolism with the requisite spaces parse as you would expect. I certainly won’t be losing any sleep over the fact I can’t directly parse programs which can’t be typed directly into the original interpreter.

I’ll stick my neck out and claim that I don’t think the GOSUBFALSE issue will be a huge problem. The basic block analysis should figure out that a subroutine starts at the beginning of line 0 since it is the target of the GOSUBFALSE call. The compiler should be able to determine that the RETURN is therefore within a subroutine. As you know, the semantics of BBC BASIC are such that subroutines can either be called with GOSUB or just directly executed. Of course, this approach will fail with computed GOTO or GOSUB destinations, which I don’t plan to support.

It is these idiosyncracies which make the project more difficult, and therefore more interesting that I expected. This, of course, will be no surprise to you.

Finally, before you ask, I think the final trailing :Z of Extra Rheolism, which generates a Mistake is fair game for for a compilation error!

That doesn’t follow. My understanding is that you propose to parse an ASCII (text) program, *not* a pre-tokenised program. To squeeze Rheolism into one line all the spaces necessary for correct parsing have been removed, so although it is a valid tokenised program it is not a valid ASCII program. I would therefore expect it *not* to be parsed correctly by your compiler.

Another aspect of Rheolism which might cause your compiler indigestion is the fact that the code calls itself using GOSUBFALSE. Normally, encountering a RETURN when not in a subroutine would cause a compiler to report an error, but in this case it must realise that later on that same code will be executed as a subroutine.

I’m afraid the word “obviously” always arouses my suspicions!