Home > .NET, 8 bit, computing, OWL BASIC, software > Writing a BBC BASIC compiler for the CLR

Writing a BBC BASIC compiler for the CLR

Of late, I’ve picked up an interest in the CLR through learning C#. After being impressed by the performance of the .NET runtime (less so for Mono, although that’s another story) I decided that an effective way to really get to grips with the system would be to write a compiler which targets the CLR.

During a nostalgic poke around the web relating to Acorn hardware, over 12 years since my last contact with BBC BASIC, I stumbled across Richard Russell’s BBC BASIC for Windows (BB4W) which reminded me of my formative years learning to code on the BBC Model B and later various Acorn Archimedes computers under RISC OS. This led me to start down the road of implementing a BBC BASIC compiler for the CLR, although the original BBC BASIC, and BB4W are interpreted. The original BBC BASIC II resided in only 16 kB of ROM, so it can’t be that much work. Can it?

The BBC Basic for Windows implementation, from Russell actually goes to long lengths to provide good backwards compatibility with software originally developed for the Beeb or RISC OS, such as providing a Teletext MODE 7 equivalent, and ‘emulated’ sound and graphics support.

I will be taking a different tack with this project. Rather than focus on getting old code reliant on obsolete hardware features to run, I will focus on making a viable BBC BASIC compiler for the CLR, which could be used to port existing programs to .NET/Mono. It is likely that OS or machine specific functionality such as sound and graphics will be implemented in significiantly different ways compared to the originals, for example, by giving good language-level integration with the System.Console class in .NET, rather than trying to emulate screen modes from Acorn hardware.

The toolset I settled on is as follows:

  • IronPython in which to write the compiler
  • PLY – the Python Lex/Yacc-a-like
  • BeebEm – BBC Micro emulator with BBC BASIC II
  • Arculator – Acorn Archimedes emulator with BBC BASIC V
  • Documentation in the form of BBC Micro and Archimedes user manuals, and various other information and examples on the web

Mostly its an experiment, and for the fun of writing a compiler. I don’t expect anybody to start creating large software systems in BBC BASIC as a result of my efforts. Far from it; there are much better tools today. However, I must admit to a secret aim of producing the fastest BBC BASIC implementation yet!

Categories: .NET, 8 bit, computing, OWL BASIC, software Tags:
  1. June 14th, 2007 at 17:45 | #1


    I don’t want to pour cold water on a good idea, but do you realise that BBC BASIC *cannot* be compiled (at least, not in the conventional sense)? Apart from the obvious example of EVAL (are you just planning to omit it?) there are many other language features that are not fully compatible with the pre-processing performed by a compiler. Ones that come immediately to mind are that you cannot determine at compile-time which NEXT pairs with a given FOR (similarly REPEAT..UNTIL, WHILE..ENDWHILE), what is the scope of LOCAL variables, whether a function returns a string or a numeric etc. etc.

    The consequence is that any ‘compiled’ language you might develop is likely to be only partially compatible with BBC BASIC, and therefore of limited interest to BBC BASIC programmers. It is almost certain to fail in your aim of being used to “port existing programs”.

    Finally, but most importantly, don’t call it BBC BASIC! To do so you would require permission from the BBC (as I have) and I doubt that you would receive it, or indeed find anybody there who felt competent to give such permission (before I retired it would probably have been me!). Take a lesson from Dave Daniels who called his version Brandy to avoid upsetting the Corporation.

    Regards, Richard.

  2. Robert Smallshire
    June 17th, 2007 at 21:30 | #2


    Thanks for your interesting points. I’m fascinated by your assertion that BBC BASIC can’t be compiled. As you say EVAL is an obvious difficulty. However, this would just seem to be a case of needing to ship a run-time library against which compiled programs would link in order to provide such functionality. In a similar manner to how C programs use the CRT to provide a run-time environment for the application. It should be straightforward, in theory at least, to embed a small expression evaluator into the runtime library, and a symbol table with the program, to support use of EVAL. Whether its worth the effort of course is a different question.

    As for the other points, regarding matching paired FOR..NEXT statements, I’d be interested in seeing example from real-world BBC BASIC code, where this is the case. I appeciate that combining FOR..NEXT with GOTO, for example, could lead to such situations, but I’d be surprised to see this in real code, given the emphasis BBC BASIC puts on structured programming.

    Regarding determining the return type of functions, I can’t see any reason why its not possible for the type checker in the compiler to infer the return type of functions. However, again I’d be interested to see a counterexample.

    So far as compatibility is concerned, I’m certainly prepared to compromise compatibility with the original BBC BASIC to shoe-horn my compiler into working well with the Common Language Runtime. I view this in much the same vein as Managed C++ or C++/CLR – such changes are worth the inconvenience for the benefit they bring. As an example, I intend to use Unicode strings from the .NET string class, rather than BBC BASIC style strings.

    Your language implying imminent ‘failure’ seems a little strong. I’ve been involved in porting very large software systems through much larger transformations than the ones we’re likely to be discussing here. ‘Porting’ implies some degree of re-work.

    The point is probably moot however. As I suggested in my closing paragraph, I don’t really intend anybody to take this as a serious effort, or indeed use it as a serious tool; it is very much a personal project to exercise compiler building techniques using the excellent tools provided by PLY, IronPython and .NET. I certainly wouldn’t attempt anything but trivial programs in BBC BASIC these days, given the wealth of excellent tools available.

    Finally, I accept your final point that using BBC BASIC in the name is a mistake, both for reasons of limited compatibility with the original, and to avoid entanglement with the Beeb. I’ll come up with a suitable alternative…

  3. June 17th, 2007 at 23:09 | #3


    Your suggestion of linking with an expression evaluator and incorporating a symbol table will not fully implement the functionality of EVAL. Consider this piece of BBC BASIC code:

    dummy% = EVAL(“FNassign(“+name$+”,”+value$+”)”)
    DEF FNassign(RETURN n, v) : n = v : = 0

    What this rather sneaky code does is actually to *create* a new variable at run time and to assign it a value. Thereafter that variable can be used in the program exactly like any other. I think you would find that functionality (which is used in real programs) very challenging to implement fully.

    You ask for an example of the difficulty in matching a FOR with a NEXT at compile time:

    DEF FNscan(A()) : LOCAL I%
    FOR I% = 0 TO DIM(A(),1)
    IF A(I%) = 0 THEN
    I% = DIM(A(),1)
    NEXT I%
    = TRUE
    REM Some more code here
    NEXT I%
    = FALSE

    Here there are two NEXT I% statements; which gets used depends at run-time on the contents of the array. This is a real-world example (although the code could no doubt be written more elegantly).

    You suggest that the “type checker in the compiler” can infer the return type of a function. How can that be the case in this simple example:

    DEF FNunsuretype : LOCAL R%
    R% = RND(2)
    IF R% = 1 THEN = 12345 ELSE = “a string”

    Of course this is a little contrived, but I certainly have programs which rely on being able to return either a numeric or a string depending on a run-time decision.

    There are other areas where a compiled language will have great difficulty in being compatible with BBC BASIC, for which I am happy to give you detailed examples if you wish.

    It’s all very well saying that “porting implies some degree of re-work” but the level of compatibility you are likely, in my opinion, to be able to achieve means that it would not be practical to convert many of my programs.

    My aim was simply to ensure that you realised the compatibility limitations at an early stage; the phrasing of your original proposal suggested to me that you probably didn’t. If you want to proceed in that knowledge then of course that’s entirely your business.

    I do wonder why you think BBC BASIC is a good choice of language with which to experiment with writing a compiler. It’s a quirky language with a number of significant weaknesses, and its compensating strengths nearly all depend on it being interpreted. If you lose those, I’m not sure that what’s left is really worthwhile.

    Regards, Richard.

  4. Les May
    June 30th, 2007 at 18:25 | #4

    I have the Oak ABC compiler for BBC BASIC which I purchased in 1992. I used it extensively during the 1990s for my program development work when I was working on the analysis of bird calls. Compilation does work.

    However I will quote briefly from p15 of the manual. ‘The interpreter insists that there is a one-to-one correspondence between opening and closing structure markers in the case of CASE…ENDCASE and IF…ENDIF structures. The compiler takes this rule one step further and insists that the one-to-one correspondence is maintained between REPEAT…UNTIL, WHILE… ENDWHILE, and FOR…NEXT.

    The manual also covers some points raised by Richard Russell. The structures he describes cannot be compiled. But my answer to this is ‘so what?”. A compiler can handle the majority of the structures provided by BBC BASIC and these allow some very useful programs to be written.

    There were several other small changes that may be required to get a program to compile but my recollection of the first time I used the ABC compiler is that it took me less than an hour to get a large program, which had been written using the interpreter, to compile and run correctly. I cannot recollect an occasion in which I felt inhibited by any limitations of the compiler.

    Incidentally the compiler allowed conditional compilation. That meant you could have two procedures with the same name, one to meet the requirements of the interpreter and the other to meet the requirements of the compiler. The compiler ‘knew’ not to compile a procedure because it was preceded by REM {NOCOMPILE} and to compile the following procedure instead when it encountered REM {COMPILE}. As the interpreter started looking for a procedure from the top of the program code and terminated its search when it found a procedure with the correct name, it never encountered the second version.

    The manual runs to more than 80 pages and contains a lot of additional information.

    Please go ahead with your project to write a BBC BASIC compiler which takes advantage of the facilities of the CLR. Don’t worry about 100% compatibility.

    (To be honest I would rather you wrote a COMAL compiler for the CLR. BBC BASIC appears to have been influenced by COMAL, which is why it is so good, but someone seems to have lost their nerve and decided a computer without the language being called BASIC would not sell.)

  5. Robert Smallshire
    July 2nd, 2007 at 16:57 | #5

    Hi Les,

    Thanks for your support. In fact, I’m pretty sure that the ‘uncompilable’ structures with mismatching FOR..NEXT statements can actually be compiled using structures called continuations. I’ve working on using so-called ‘continuation passing style’, to do exactly this from BBC BASIC source. There are some examples here on using continuations to implement complex control structures in the compiled functional language Haskell.

    However, ultimiately I agree with you. The vast majority of useful programs can be made to work without these features for relatively little effort.

    I actually have experience with COMAL from my schooldays in the late 1980s. Somewhere I have the Acornsoft COMAL manual. I remember it as being a much nicer BBC BASIC than BBC BASIC! It should be possible to add a COMAL front-end to my compiler. Its probably possible to compile BBC BASIC and Acornsoft COMAL into the same intermediate form without too much difficulty, and retain the same back-end for code generation.

  6. July 5th, 2007 at 23:17 | #6

    “For obscure reasons, possibly to do with squeezing all this into 16 kB in the original ROM, there are 38 exceptions to this rule”

    There’s nothing at all ‘obscure’ about this, it was a quite deliberate decision made by BBC BASIC’s original designer Sophie Wilson.

    In BBC BASIC each keyword can be flagged as either being able to start a variable name or not being able to start a variable name. The interpreter will work fine whichever setting is chosen.

    At one extreme all keywords could be flagged as valid variable name prefixes; this would be compatible with most modern programming languages, but means every true keyword must be followed by a non-alphanumeric delimiter (typically a space). This is costly in memory usage (in the context of the original BBC Micro with as little as 5k of user memory).

    At the other extreme every keyword could be flagged as not being valid as the start of a variable name. This is potentially more efficient in memory usage, because an explicit delimiter will frequently be unncessary, but will significantly limit the variable names available (they can never start with a keyword).

    So a compromise was chosen, such that those keywords which can never in any case be followed by an alphanumeric character *are* permitted at the start of a variable name, whereas those keywords which can be followed by an alphanumeric character are *not* permitted at the start of a variable name.

    If you look at the list of 38 keywords you will find that because of the language syntax they can never be followed by an alphanumeric character; some must be followed by a # (e.g. BPUT, BGET, CLOSE, EXT, EOF, PTR), others only appear on their own as a statement or function (e.g. CLEAR, CLG, CLS) or can only be followed by a parenthesis (e.g. RND).

    An oddity is that OFF, which can never be followed by an alphanumeric character, is not included in the set. Sophie Wilson has admitted to me that this was probably a mistake, and in BBC BASIC for Windows I have changed its status so that variable names like ‘offset’ are permitted.

  7. September 11th, 2007 at 16:17 | #7

    This is a splendid idea, although of course Richard is right, you’re unlikely to get very good agreement with the original interpreters unless you choose an approach that is basically tokenise and interpret. JIT compilation might be a nice idea.

    Can I recommend the following BBC BASIC V program as a good goal to test how faithful your CLR version is? It’s only one line long so it shouldn’t present too many challenges:


  8. October 15th, 2007 at 17:15 | #8

    > Can I recommend the following BBC BASIC V program as a good goal to
    > test how faithful your CLR version is? It’s only one line long so it
    > shouldn’t present too many challenges:

    > http://www.survex.com/~olly/dsm_rheolism/

    Cruel! It would indeed be impressive if Rob’s implementation ran this program but I suspect he might consider that an unreasonable challenge. Interestingly, BBC BASIC for Windows *does* run it, and I supply it as an example program to prove the point.

  9. Robert Smallshire
    October 16th, 2007 at 18:00 | #9

    Regarding Olly’s Rheolism game, obviously the fact that its an obfuscated one-liner makes no difference whatsoever – it will be parsed correctly.

    The main challenge lies in the combined use of the text and graphics facilities in the same screen buffer. The program is dependent on the characteristics of the particular display (MODE 9 in this case) and I’m focussing on a language implementation rather than a BBC Micro or RISC OS graphics subsystem emulator. I don’t doubt for a second that if I wanted to run this program, or one needing the same facilities, on Windows I’d use BBC BASIC for Windows rather than my CLR based implementation. However, if I wanted to call some BBC BASIC routines from C++, or C# or Visual Basic or if I wanted to run on Linux with Mono, then BB4W probably wouldn’t be my tool of choice. Horses for courses.

    I could translate Olly’s program into C for RISC OS using the facilities of the OS, and it wouldn’t work on other platforms without emulation of the Acorn graphics subsystem at least. My program would still be written in C though!

    Having said that, it would be interesting to translate VDU calls to Windows console operations; certainly many of the text operations should be possible. There’s a nice tuorial here: http://www.benryves.com/tutorials/?t=winconsole&c=all

    Its a fun page, and interesting hear of Olly again, who I’ve previously known through speleological circles in the UK.

  10. October 16th, 2007 at 23:20 | #10

    > obviously the fact that its an obfuscated one-liner makes no difference
    > whatsoever – it will be parsed correctly

    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!

  11. Robert Smallshire
    October 17th, 2007 at 18:40 | #11

    Hi Richard,

    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!

  12. February 7th, 2008 at 14:35 | #12

    It’s kind of traditional in highly interpreted languages to allow language errors in parts of the program which haven’t been executed yet. After all you might never execute it, in which case it seems peevish to complain about the mistake.

  13. June 3rd, 2008 at 14:12 | #13

    “However, I must admit to a secret aim of producing the fastest BBC BASIC implementation yet!”

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

  14. July 17th, 2008 at 14:35 | #14

    I wrote a year ago pointing out that compilation of BBC Basic is possible. However I am writing this on a machine which runs 300 times faster than the RISC OS machine I used with the compiler. I am not convinced that compilation is superior to interpretation in this and similar cases. Richard Russell’s solution of packing the interpreter with the program solves the distribution problem of interpreters. However good luck with the project and please, PLEASE, include a Comal frontend.

  15. Robert Smallshire
    July 17th, 2008 at 15:51 | #15


    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?

  16. Les May
    July 21st, 2008 at 19:35 | #16

    I used COMAL to write my first ‘serious’ program in 1986/7. It allowed me to display the way that radio tagged animals used their home range. It was complex but maintainable because of the high readability of COMAL. I used this experience to write much larger programs for Acorn RISC machines, but BBC BASIC is much less readable. I also used this experience when I learned Pascal (Delphi) but COMAL has the better structure. I call it ‘full closure. i.e. a COMAL uses FOR … ENDFOR; Pascal uses FOR but what follows must be on one line or bracketed with BEGIN… END. Wirth did not improve upon this completely in MODULA 2 or OBERON and ZONNON has left it unchanged, thought they are better than Pascal.

    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!

  17. Kevin Swinton
    September 24th, 2008 at 21:40 | #17

    Hi Robert

    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.

  18. Robert Smallshire
    September 25th, 2008 at 19:52 | #18

    Hi Kevin,

    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…

  19. December 25th, 2008 at 14:20 | #19

    “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”

    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.

  20. Robert Smallshire
    December 27th, 2008 at 17:03 | #20

    Hi Richard,

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

  21. Anonymous
    January 26th, 2009 at 18:51 | #21

    Thing is, would you actually ever want to run a program that used Richard’s FNassign hack? If not, EVAL can be neatly implemented by shipping the compiler in the runtime library.

  22. munch
    January 26th, 2010 at 03:58 | #22

    Oberon absolutely discards BEGIN/END in control structures. I’m not sure why Les says it doesn’t, and belies an ignorance of the language from lack of use. The only use for BEGIN in Oberon is distinguishing program code from declarations in procedures.


    I invite Les to reconsider his position on Oberon.

  23. Les May
    February 6th, 2010 at 17:47 | #23

    I invite MUNCH to carefully re-read what I actually said in my posting. I did not say that OBERON does not discard BEBIN/END in control structures. None of the descendents of Pascal implement full closure of control structures. The single word ‘END’ is used to terminate all except the REPEAT..UNTIL loop. If full closure were implemented the examples given would read RECORD..ENDRECORD, FOR..ENDFOR etc. This may be just ‘syntactic sugar’ but it enhances readability. We spend more time reading programs than we do writing them, so readability is important. Lack of ambiguity is the first line of defence against logical errors in a program.

    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.

  24. Henry Keultjes
    September 7th, 2010 at 16:22 | #24

    To Robert Smallshire:


    Your article and the comments there to are quite fascinating to me.

    As a 71 year old Pick (see http://www.openqm.org or Ladybridge Software) user for thirty years, I have had this long-time desire to reform Pick. Your article is on the BBC compiler even more interesting because I have also been a longtime RISC fan, since one of the first super Pick implementations was on the IBM RT of which I still own a few.

    Thus my target for such a project would be an ARM-64 bit for which I would need a Quite Extended BASIC type language.

    Might you be willing to answer a few questions in that regard.

    Henry Keultjes
    Mansfield Ohio USA

  25. Toby Whaymand
    June 23rd, 2013 at 01:25 | #25

    The problem that I have with BBC BASIC is there isn’t any videos or any real support on how to learn the language. Reading tons of text is the worth way of learning because you are only shallow processing. We need quality You Tube videos.

    Secondly I’m in two minds half of me wants to learn BBC BASIC has a first language because it seems fairly easy and it’s the language that’s I’m most familiar with. The other half is worrying about investing so much time in a language that seems hopelessly out-of-date and isn’t being used in industry anymore. Even Visual BASIC has had it day and been discarded by Microsoft.

    Just after the year 2000 the Industry declared that COBOL was out of date and these programmers were no longer needed. The majority of COBOL writers found themselves going into retirement. Move on 13 years and the industry is in a panic because there isn’t enough COBOL writers. – Who to say that isn’t going to happen to BASIC?

  26. Toby Whaymand
    June 23rd, 2013 at 01:30 | #26

    The problem that I have with BBC BASIC is there isn’t any videos or any real support on how to learn the language. Reading tons of text is the wrong way of learning because you are only shallow processing. We need quality You Tube videos.

    Secondly I’m in two minds half of me wants to learn BBC BASIC has a first language because it seems fairly easy and it’s the language that’s I’m most familiar with. The other half is worrying about investing so much time in a language that seems hopelessly out-of-date and isn’t being used in industry anymore. Even Visual BASIC has had it day and been discarded by Microsoft.

    Just after the year 2000 the Industry declared that COBOL was out of date and these programmers were no longer needed. The majority of COBOL writers found themselves going into retirement. Move on 13 years and the industry is in a panic because there isn’t enough COBOL writers. – Who to say that isn’t going to happen to BASIC?

    I also feel that morally any peace of Free or Open Source software should preliminary be available on Linux then other platforms. Together we have a responsibility to try and make the market a fair one.

  27. Robert Smallshire
    June 23rd, 2013 at 10:21 | #27

    @Toby Whaymand
    Hi Toby, These articles are about writing a compiler for BBC BASIC, not about learning BBC BASIC. As such it’s much more about making a compiler than it is about BBC BASIC. I honestly can’t recommend learning BBC BASIC as a language for getting things done in 2013. Much better to choose a language such as Python which is easy to get started with and very productive to boot. Try http://python.org.

  28. Toby Whaymand
    June 24th, 2013 at 23:41 | #28

    Thanks Robert

    I like BASIC because it seems to be almost in plan English. Programming is an areas that I’m not well educated in. There doesn’t seem to be much support nowadays with regards to learning BASIC even if it just for pleasure.

    Simple things in BASIC seem to be a great challenge, for example knowing exactly where TAB 4,1 and TAB 2,5 will be on the screen.

    Python seems to be a good language but knowing the popularity of the ‘C’ family and the fact that it seems to be a lot like BASIC makes it very appealing for me. The final nail that sold ‘C’ is learning that Linux is mostly written from ‘C’ and I am a hardcore Linux fan.

    The majority of college’s and university seem to teach ‘C’ rather then Python the natural conclusion is that Python earns you more money. ;)

    I will not send anymore messages because I don’t want you guys to go off topic but I will consider python before making a final decision. Just knowing that I can go to an evening class and has a zillion questions to a tutor makes ‘C’ very appealing.

  29. November 13th, 2015 at 00:55 | #29

    Not sure if I should enter this discussion, but i have developed a BBC BASIC to Acorn ANSI C Translator. To do this I deveoped a Bison (Yacc) grammar for BBC BASIC. I shred the BBC BASIC into ‘tokens’, which I pass to the ‘grammar’, which gradually translates the whole program into C, and passes up a ‘string’, that is finally output. The Translator seems to ‘pass’ about 98% of such programs, without problems, albeit with some ‘syntax’ errors.

  1. June 11th, 2007 at 23:30 | #1
  2. June 19th, 2007 at 14:39 | #2
  3. June 20th, 2007 at 14:12 | #3
  4. July 2nd, 2007 at 17:32 | #4
  5. May 18th, 2009 at 10:45 | #5
  6. May 22nd, 2009 at 18:08 | #6