Bob's your uncle

I have just put back on my website
a brushed-up version of Armbob. This is a small object-oriented language, with a syntax resembling a simplified C++, developed, with his permission, from David Betz’s Bob. He originally wrote it for an IBM PC. He described it in an article A tiny object-oriented language in Dr Dobb’s Journal, September 1991, p.26. Soon after developing it for RISC OS my attention was diverted to Lua. Last night I dug it out of my archives and found that it still ran fine on my Raspberry Pi. At an Acorn computer show I was surprised to see on the iconbar of a stallholder’s computer the Armbob icon, and discovered that APDL had made it available. I did not remember being asked to give my permission, but I suppose I was flattered to find somebody using it. Its copyright belongs to David Betz, but it is free to be used and modified by RISC OS users.

I know that there are probably not many programmers around any more, and no doubt they have other fish to fry, but I thought it worth pointing out. The download contains the C sources. There are lots of ways it could be developed further – more libraries, more documentation. It uses a stack virtual machine, something no longer in fashion, which could be replaced by a faster register-based one. It could be converted from an interpreter to a compiler. The language itself would be better with multi-assignment (why should functions only return one argument?), but it is quite capable as it stands – not just a toy.
It has error-throwback, macros and a fully-featured preprocessor. Anybody with any experience of C will find Armbob much simpler (no pointers, no types). Classes have only single-inheritance. It could be a good language for beginners.

If anybody does try it I would be grateful for feedback.

Well, I’m glad to see this!

ArmBob sounds pretty neat. I admit I like the idea of a C++ subset.

Hi Gavin,
I have just started playing with !armbob, and indeed with riscos, having started on a C^$ back in the day, rather than the BBC. I am using a Pi 1b, with 512mg ram.

!armbob seems to work well so far as I have looked (I have even modified the odd example program) whereas GCC will not even run on this hardware.

It may be worth pointing out that ‘Chess’ and Draw’ require a pre-existing RAM disk to show anything.

Thanks, Colin McMurchie

I have just started playing with !armbob, and indeed with riscos

Welcome to RISC OS and to the forum. I am glad to hear that ArmBob is being used. Maybe David Betz is too; it is thirty years since he wrote Bob.

It may be worth pointing out that ‘Chess’ and Draw’ require a pre-existing RAM disk to show anything.

You are quite right. Maybe I should put a Readme note in the examples directory.

Bob was written to show how to write a simple interpreter in C for an object-oriented language. The C sources are very readable and I learned a lot from them. There are many ways in which they could be developed; turning them into a Bob compiler, for starters. Even the interpreter could probably be made a lot faster. I see it as an educational tool to tempt BASIC programmers toward wider horizons.

I don’t think I will be any help in developing !Armbob. I am no more than a dabbler in coding really. I might find something useful for other dabblers, perhaps. If so i will post again.

I am using a Pi 1b, with 512mg ram … GCC will not even run on this hardware.

GCC 4.7.4 release 5 runs on my 512MB RPi1, and with 350MB free.

OT for here but if assistance is required post any error messages to a new topic.

I shall have a look at armbob, it is up and running on the RPi400 and Titanium.

Thank you David, I shall try to find out what I am doing wrong.

GCC is now working for me. I found out I had to tweak the memory through task manager first. It is good to learn something new every day.

The original article about Bob is still online. There’s also a git repository on GitHub with the code, relicensed under the MIT license last year.

ArmBob is based on Bob 1.5. The code in the git repository carries Bob somewhat further – the compiler and interpreter are separated, and the OO is more developed – but I cannot find a version number. I can verify that it compiles with the latest Acorn C compiler, with the obvious tweaks: convert to Unix line-endings, change file-extension character from dot to forward-slash. I have not yet tried it with GCC, which will be necessary for VFP floats. I was not sure, until I saw the MIT license, what the legal status of this code was. I probably do not need to say that it is rare to find clearly-written C source-code that can be compiled under RISC OS. Almost everything demands a Unix, MacOS or Microsoft platform. So this is quite a juicy gift to RISC OS C-programmers who might like to toy with it (if there are any). David Betz used it for various projects: the NUON DVD player, his AdvSys adventure-writing system, an embeddable macro system, DROOL (David’s Recycled OO Language), TOOL on Code Project.

I am not an expert on OO languages; my impression is that they are no longer flavour of the month because they present such an embarras de richesses . There are so many types of object and types of inheritance possible. Now let us see … if we can enhance Bob with a nil object, with multi-returns from functions and multi-assignment, a class-based SWI-interface , a faster register-based VM, … .

I didn’t know about his NUON connection.

AdvSys sounds familiar, though perhaps that’s because there were a few similar systems and it looks LISPish. His collection of GitLab repositories contains a few language implementations. It seems that, once you start writing them, it becomes addictive!

I am not an expert on OO languages; my impression is that they are no longer flavour of the month because they present such an embarras de richesses

Not all all, OO is regarded as de rigueur.

There are now, thank God, dissenters

One tacked on paragraph about what Facebook and Twitter might be experimenting with, does not an industry make. Encapsulation rules.

Encapsulation rules.

Indeed it does. And what a strain it puts on the programmer having to think up names for variables all the time. At one end of the scale we have the influence of mathematics with single-character names like x , useful for when the imagination flags but hopeless for imparting meaning, and at the other the monstrous verbosities of Java where you must SpellOut_every.laborious.CamelCase.detail .

Fortran got it right with a max of 6 chars

Encapsulation rules.

But encapsulation isn’t unique to OOP; it’s achieved via abstraction in functional programming languages.

OK, Haskell might be niche but the fact you can build .Net Core apps in F# demonstrates functional languages are carving out a bigger space for themselves.

Whatever. Vive la différence! And OOP certainly doesn’t rule on RISC OS…

And OOP certainly doesn’t rule on RISC OS

What does seem to rule on RISC OS is its legacy from BCPL – everything comes down to blocks of bytes or words. OK, pointers maybe. But datatypes, objects, all that fancy stuff? Stick to BASIC as the Good Lord intended!

And OOP certainly doesn’t rule on RISC OS…

Stick to BASIC as the Good Lord intended!

It has been my ambition for a quarter of a century to combine the two. It really is possible. ;-)

It has been my ambition for a quarter of a century to combine the two. It really is possible. ;-)

ARM BBC Object Basic ?

ARM BBC Object Basic ?

Hardly.

My first was a response to the Toolbox, before I could get hold of a copy without buying the DDE, although the manual was available. It replicated pretty much all the TB did at that time plus the ability to be extended. It was ‘tricky’ and rather ‘heavy’ for the machines at that time and never documented for release. Many years later I was pleased to see parallels to my structures in the Res file structure.

Then I developed Basalt and incorporated the TB as an OOP interface. I never got round to implementing the possibility of extending the classes.

More recently I wrote Oobi – Object Oriented BASIC Interface. Apart from a handful of assembler ‘codelets’ it is entirely in BASIC, but even ‘trickier’ below the waterline than before. Pleasing, though. ;-)

ARM B BC O bject B asic ?

Hardly.

Maybe if I did the little quip with emphasis as above?

What I would like to see in the way of a development of BASIC would be a compiler rather than an interpreter, building on the BASIC assembler, and producing ELF files, using the BASIC runtime. As a language I see the basic elements as blocks , either of executable code (functions) or of labelled values (classes). Values would be integers or pointers. Blocks cannot have subblocks. Labels would only exist for the compiler; they would be resoved to addresses by the linker. Local variables in a block would be simply offsets. There would be nil value, representing false , all other values (including 0) representing true . Functions can return multiple values; very necessary for passing error conditions. Strings are of little use unless they can have holes in them; so it is ropes that one wants. These are useful for format strings, which are basically strings with functions embedded which transform values to strings – i.e. format specifiers. The basic building blocks for ropes are of the form

class rope {(string) head; (rope) tail;}

The one development BBC BASIC needs is to become fit for the purpose of writing programs for RISC OS. OO would be nice, but first it needs to be able handle in memory structures for things like window blocks with named fields, instead of indirection operators with magic numbers. Secondly it needs proper dynamic memory support, without any nasty hacks.

As for interpreted or compiled, I feel interpreted is easier for beginners, and it’s fast enough for most purposes. However there seems to be a number of people that want it compiled, instead of learning a proper compiled language.

but first it needs to be able handle in memory structures for things like window blocks with named fields

That would be nice. But it would need to be able to deal with things like the return from Wimp_GetWindowInfo, that (from memory) returns a window block offset by 4 bytes, because it starts with the window handle, and consists of a window block followed by a number of icon blocks.