Introduction to BBC BASIC

[RichardRussell]

I've today tried running BBC BASIC under the new Raspbian Buster OS (on a RPi 3B). On a quick test, everything seems to be working as expected; I note that the version of SDL2 at the repository is 2.0.9 compared with 2.0.5 with Raspbian Stretch.

Hopefully that augurs well for it running on the new Raspberry Pi 4, I would be interested to hear from anybody who has tried it.

[RichardRussell]

In another thread, about another BASIC (!), there are some examples of how to incorporate GUI features from a toolkit like GTK or IUP. Whilst you can do that (in BBC BASIC too if you want to) it seems to me that it's neither a good demonstration of the capabilities of your BASIC nor conducive to guaranteeing cross-platform compatibility. In BBC BASIC for SDL 2.0 I prefer to create my GUIs in native BBC BASIC code (there's a supplied library dlglib.bbc to make it easy); here's the main screen of a program I am currently working on:



Everything there created in 100% BBC BASIC code (which runs in BBC BASIC for WIndows too).

[John_Spikowski]

Richard,

Will you be submitting a GUI editor for the challenge?

[RichardRussell]

Will you be submitting a GUI editor for the challenge?

What challenge? I generally don't take an interest in challenges (I leave that to my users). The Liberty BASIC GUI editor FreeForm will be hard to beat (it runs in my LB Booster too), if existing programs are eligible.

[John_Spikowski]

Check out the spec. for the GUI Editor challenge and if you have something already built that comes close, feel free to submit it.

[RichardRussell]

Check out the spec. for the GUI Editor challenge

The only spec I can find refers to 'Rich Text edit control' and 'predefined dialogs'. That appears to rule out a native code solution (in BBC BASIC or anything else) since by definition it won't be using any 'predefined' library widgets.

[John_Spikowski]

Once again if you have a desktop editor written in BBC BASIC then please post the submission. AIR and I are both using code edit controls instead of rich edit. The point is I wanted it to be more than an ASCII text editor.

If you don't want to participate, that's fine too.

[RichardRussell]

If you don't want to participate, that's fine too.

The kind of challenge that would be more likely to attract a submission from me is one that specifies that only native code (including supplied standard libraries) can be used, in other words specifically excluding the use of external libraries and toolkits. That way the relative strengths of languages really can be tested.

[ejolson]

If you don't want to participate, that's fine too.

The kind of challenge that would be more likely to attract a submission from me is one that specifies that only native code (including supplied standard libraries) can be used, in other words specifically excluding the use of external libraries and toolkits. That way the relative strengths of languages really can be tested.

I agree, otherwise one ends up with challenge entries that look like

Code: Select all

#!/bin/sh
exec emacs "$@"

Note that this could be improved by checking whether the EDITOR environment variable was set and by default loading gvim if available, but otherwise it's quite functional.

[RichardRussell]

I agree, otherwise one ends up with challenge entries that look like

Code: Select all

#!/bin/sh
exec emacs "$@"

Quite. It ends up being a test of how easy it is to embed a library widget, which ought either to be straightforward (if the language supports that kind of thing) or impossible (if everything is sandboxed) and therefore neither interesting nor informative.

[PeterO]

It ends up being a test of how easy it is to embed a library widget, which ought either to be straightforward (if the language supports that kind of thing) or impossible (if everything is sandboxed) and therefore neither interesting nor informative.

Unless you are trying to get someone to write you a front end for your pet project without actually telling them that is what you are doing
PeterO

[John_Spikowski]

At least we have a pet project unlike you that wastes his time being a troll.

[Heater]

Now, now guys.

A bit of friendly rivalry between BASIC creators is OK. Let's not get carried away.

[John_Spikowski]

I take issue with PeterO insinuating that I created this code challenge so folks would write an IDE for the ScriptBasic open source project he refers to as my pet project.

With all the other threads on this forum, why does he keep trolling the ScriptBasic project? Sounds pretty sick to me.

[RichardRussell]

I agree, otherwise one ends up with challenge entries that look like...

Since you mention it, I felt that it was a flaw of the Fibonacci challenge too, as there was nothing to prevent a 'solution' consisting of calling GMP library routines. Writing a BigNum library from scratch in BBC BASIC (which admittedly has never been finished beyond what was necessary for Fibonacci) was in my opinion a more informative approach.

[John_Spikowski]

I paid my dues with the array driven fibo. Painfully waiting an hour and 15 minutes for it to complete. I'm so done with the fibo challenge.

[Heater]

RichardRussel,

I felt that it was a flaw of the Fibonacci challenge too, as there was nothing to prevent a 'solution' consisting of calling GMP library routines.

I don't know how you missed it but the Fibo challenge had a rule that disqualified using any libraries that were not a standard part of the language being used.

The rule was suggested by DavidS very early on. I and others agreed. It came up for discussion on every other page of the thread!.

The point of the rule was to stop "cheating" by simply calling the ready made fibo function in GMP or using it's big integers. Or any other libraries big integers.

ScriptBasic and I had a disagreement about this. But I decided that if a big integer module was created for ScriptBasic and included in the standard install, then it would qualify. No matter if it used GMP under the hood, that is an implementation detail at that point. After all, ScriptBasic was/is the maintainer and could define whatever he liked as a standard part of ScriptBasic.

We are still waiting for a working big integer module for ScriptBasic.

As it happens there is a C code in the Fibo Challenge repo that simply calls the GMP fibo function. It's not an entry to the challenge, it's just there as a reference. Where else would we get a million digit Fibonacci number from to check the correctness of entries against?

Writing a BigNum library from scratch in BBC BASIC (which admittedly has never been finished beyond what was necessary for Fibonacci) was in my opinion a more informative approach

Exactly what was intended. Great job.

My C++ big integer is also incomplete, no negative numbers, no division. Just enough to get the job done.

[RichardRussell]

ScriptBasic and I had a disagreement about this. But I decided that if a big integer module was created for ScriptBasic and included in the standard install, then it would qualify. No matter if it used GMP under the hood, that is an implementation detail at that point.

It's that solution I was referring to. It may be an "implementation detail" but it means that the value of the challenge as a way of assessing the language is pretty much zero. I can see that it would be difficult to frame a challenge in such a way as to disallow such a solution, but there could at least be a general encouragement to language maintainers to offer a solution that says something informative about his language other than being able to call a library function!

Where else would we get a million digit Fibonacci number from to check the correctness of entries against?

I have no issue at all with using GMP to create the reference solution used to verify others.

My C++ big integer is also incomplete, no negative numbers, no division. Just enough to get the job done.

Yep, exactly the same limitations as mine!

[ejolson]

RichardRussel,

I felt that it was a flaw of the Fibonacci challenge too, as there was nothing to prevent a 'solution' consisting of calling GMP library routines.

I don't know how you missed it but the Fibo challenge had a rule that disqualified using any libraries that were not a standard part of the language being used.

For me, the biggest difficulty with the Fibonacci challenge is that the person who proposed it didn't offer a free Pi 4B to the first person who submitted a complete solution written in classic line-numbered Basic.

Do you think upping the ante and offering a Pi 5 would motivate the challenge of making a graphical networked version of the classic Star Trader game?

[Heater]

RichardRussell,

It may be an "implementation detail" but it means that the value of the challenge as a way of assessing the language is pretty much zero. I can see that it would be difficult to frame a challenge in such a way as to disallow such a solution, but there could at least be a general encouragement to language maintainers to offer a solution that says something informative about his language other than being able to call a library function!

Yes, indeed, that is why ScriptBasic and I had a bit of a disagreement about allowing a ScriptBasic solution that used a GMP big integers module.

I think of it like this:

If GMP or some big number library were a standard part of C or C++. As much so as is printf or anything in libc, libm, etc, then it would be fair game for a C or C++ solution to use those big integers.

Similarly, if ScriptBasic had a big integer library out of the box then it would be fair game to use that.

The sticking point was that ScriptBasic did not have such a module before the challenge was created.

Ergo, the ScriptBasic solution may become a valid solution at some point in the future when it's big ints are working properly and included in the releases.

That leaves the issue of allowing one to simply use GMPs fibo function. That is clearly not on.

Even with a big int library available a solution still contains enough to say something about the language. One has to implement a fast fibo algorithm still.

After all, the spirit of the challenge is to actually show how the language's code looks, how readable it is, etc.

[RichardRussell]

After all, the spirit of the challenge is to actually show how the language's code looks, how readable it is, etc.

True, but the opportunity for showcasing a language's 'unique' features is limited if you are constrained by the interface imposed by GMP.

I reckon the BBC BASIC Fibo program is quite readable, but I admit that the BigInt library it calls is anything but! However I've always felt that it's acceptable for libraries to sacrifice clarity for performance, so long as they can be treated as 'black boxes' (especially with an interpreted language when worthwhile speed benefits may accrue from 'abbreviated' code).

[DavidS]

If you don't want to participate, that's fine too.

The kind of challenge that would be more likely to attract a submission from me is one that specifies that only native code (including supplied standard libraries) can be used, in other words specifically excluding the use of external libraries and toolkits. That way the relative strengths of languages really can be tested.

Agreed 100%. And the reason I am hesitant to make a submission, as I would be using native code and doing so in BBC BASIC V on RISC OS.

[RichardRussell]

And the reason I am hesitant to make a submission, as I would be using native code and doing so in BBC BASIC V on RISC OS.

Unless you want to use embedded assembler code, it ought to be relatively easy to write it in 'generic' BBC BASIC so that it will run in BBC BASIC for Windows, BBC BASIC for SDL 2.0 and Matrix Brandy, as well as ARM BASIC V. It won't show off the full potential of the language, since it wouldn't be benefitting from the enhancements in my versions, but at least it means your submission can be tested on more common platforms.

[ZXDunny]

In another thread, about another BASIC (!), there are some examples of how to incorporate GUI features from a toolkit like GTK or IUP. Whilst you can do that (in BBC BASIC too if you want to) it seems to me that it's neither a good demonstration of the capabilities of your BASIC nor conducive to guaranteeing cross-platform compatibility. In BBC BASIC for SDL 2.0 I prefer to create my GUIs in native BBC BASIC code (there's a supplied library dlglib.bbc to make it easy); here's the main screen of a program I am currently working on:



Everything there created in 100% BBC BASIC code (which runs in BBC BASIC for WIndows too).

Yours has more colours than mine, but I've been working on precisely the same thing:



The whole editor is gradually being replaced by SpecBAS code. Once all the controls are done and working, I'll make them available to the user via UI commands and functions.

[DavidS]

And the reason I am hesitant to make a submission, as I would be using native code and doing so in BBC BASIC V on RISC OS.

Unless you want to use embedded assembler code, it ought to be relatively easy to write it in 'generic' BBC BASIC so that it will run in BBC BASIC for Windows, BBC BASIC for SDL 2.0 and Matrix Brandy, as well as ARM BASIC V. It won't show off the full potential of the language, since it wouldn't be benefitting from the enhancements in my versions, but at least it means your submission can be tested on more common platforms.

How do I do that? How do I create a window, handle menus, handle Window Manager events, handle messages, etc in a way that is OS independant without using libraries, while maintaining compatibility with RISC OS?