general question about riscos.

I can’t remember much about its specifics, but like ABC it obviously suffered limitations compared with BBC BASIC.

No, I don’t think so. It was nominally identical in operation. You could add compiler directives in REM statements. EVAL was not supported but VAL("&04F6") would work.

ABC has several major bugs (like not supporting LOCAL variables correctly for one).

No, I don’t think so. It was nominally identical in operation.

Okay, it sounds like I don’t remember correctly then. I’m sure I recall reading in the manual about differences and how to address them/what to do instead – but perhaps I didn’t.

However, one thing I am definitely remembering correctly is that most of the programs I compiled were slower than interpreted BASIC.

That some (a very low number, three or four – but that’s an IIRC for certain) were faster suggests it may have been necessary to ‘optimise for RiscBASIC’ (and those particular programs happened to be written in such a way they benefited) – so perhaps it’s better to say “it suffered ‘considerations’ compared to BBC BASIC.”

EVAL was not supported but VAL("&04F6") would work.

Worlds apart. I’m not sure why it’s even worth mentioning – unless ABC doesn’t even support (that use of) VAL?

aaaaa

nearly 100% compatible with BBC BASIC including an extremely clever EVAL implementation.

I remember hints about that compiler, too, but never saw any independent reports of it working. I would love to know how EVAL worked. ;-)

It would be nice if people squeezed BASIC programs – they also provide a unsqueezed version.
I updated !BasFormat by G Crow – to try and get it to deal with some squeezed code.

I seem to remember ‘!Sick’ author M Seifert took on the BASIC compiler.
It would be handy if !NetSurf had SpellCheck :-)

Mention of other forms of BASIC on RO reminds me of one I think was called HelixBASIC. I bought and tried it many years ago. Then gave up on it for reasons I now can’t remember. Whereas I found ABC pretty useful until I got around to moving on to ‘C’. If nothing else, ABC gave me a way to write modules, which I’ve never understood for ‘C’! 8-/

Jim

If nothing else, ABC gave me a way to write modules, which I’ve never understood for ‘C’! 8-/

I heard you. :-)

Try this: http://www.heyrick.co.uk/blog/index.php?diary=20150323

aaaaa

aaaaa

aaaaa

Mention of other forms of BASIC on RO reminds me of one I think was called HelixBASIC.

There was indeed one called HelixBASIC – and, again, I bought it somewhere down the line, so it may very well be in the loft or in a dark corner of the deep and mysterious Cupboard of Ultimate Doom.

I bought and tried it many years ago. Then gave up on it for reasons I now can’t remember.

Ditto. I’m not even sure now what its purpose was. Was it designed for writing WIMP applications (like WimpBASIC, but earlier)?

[HelixBasic] I’m not even sure now what its purpose was. Was it designed for writing WIMP applications (like WimpBASIC, but earlier)?

I have a vague feeling that it was, but didn’t work properly – at least for my purposes at the time. But I can’t now recall much beyond that it came in a nice slipcase! 8-]

Jim

aaaaa

I had investigated alternative solutions to BASIC as the primary language – particularly JavaScript and Lua – but whilst these would have worked (to varying degrees) the general feeling that I got from most people was that acceptance would be very low.

Alas, this is very true, I fear. We all grow old. We stick to what we know.

aaaaa

This reminds be of that saying “Build it and they will come” if this the sort of project you where thinking then I for one would like to see it a javascript alternative to basic,
It would fit well with the Pi don’t you think, there is always room for a fresh approach to step back and see the garden not just the roses.

aaaaa

“Riscos doesn’t seem to swim very fast”

That’s a great quote :)

[Gerph’s ramble on BASIC and Toolbox] what do you think of this issue ?

This could be quite a long comment, so in short, I have been thinking of this for nearly 20 years and my answer is Basalt, or something similar.

In the early 90s Justin was mostly working with BASIC and we had a few exchanges, from which I learned a lot. The Toolbox was not well established and I do not think it was mentioned. When he went on to other things he passed over the development and maintenance of a new StrongHelp BASIC manual, which I have continued ever since.

I started reading the Rambles shortly afer they started, and I was very interested in this one, because it reflected some of the thoughts I had had. The two most relevant to me are that BASIC in its current form is not suitable to support the Toolbox and the one about not being able to introduce an alternative language to BASIC because the uptake would be low. I was very pleased to get a personal mention. ;-)

I want to add one other thought, that even a new version of the BASIC module that did support the Toolbox would be difficult to introduce, because it would not be backward compatible with earlier machines and in any case, softloading a newer version has the same problems as the SCL, something that has been much rehearsed here and in c.s.a.

Some history. By the end of the 90s I had been playing around with BASIC for many years and was pretty familiar with assember and modules. Along with a host of other programmers I had written my own Wimp support libraries of different value and had tried out all sorts of Wimp support modules and applications. I even had an OO system centred on my Basil module for sharing BASIC libraries among applications. However, I recognised that all these required the programmer to have a good knowledge of how the Wimp worked, a level that involves quite a lot of data manipulation.The Toolbox works at a more abstact level and I decided that if BASIC were to have built-in facilities for Wimp programming it would be eminently sensible to do this with the Toolbox.

The first page of the Toolbox manual has this:

it can be used from C, C++, BASIC or Assembler with equal ease

It lies. ;-)

I am unqualified to comment on C/C++, but it is not easy with the last two. I did write some BASIC support libraries for the Toolbox, even extending its possibilities, but I found them unsatisfactory and convoluted. I am a great admirer of AppBasic, which does a much better job of the necessary libraries than I achieved, but it is still not very suited to the essence of the Toolbox, which is OOP, despite the API being based on SWIs.

Back to BASIC itself. Because I was maintaining the SH manual and trying to incorporate information about how it works, I had contact with a number of knowledgeable people and acquired a copy of the source. This first copy was without any comments and I despaired. Nevertheless, I could work out the way the interpretation happened and how it would be possible to incorporate new keywords. I knew that there were some very clever programmers that had written quite extensive enhancements for their own use, but these could never be published. At the same time, I was accumulating from the newsgroups a long list of complaints about features that were missing from BASIC.

Around about the turn of the century I decided to see if anything could be done. The first decision was that I could not modify the BASIC module itself. First, it was beyond my competence. Second, it could not be published. Third, I quickly cottoned on to the limitations of a soft-loaded BASIC. Initially I a developed a system of *commands to extended the number of keywords, but soon realised that this was extremely slow and was little faster than using libraries. Then, while discussing some aspects of this with Martin Avison, I came up with the system that Basalt uses.

A program is written in the normal way except for a requirement for a star command at the very start. Some existing BASIC keywords can be used with alternative syntax and completely new keywords can also be used. When the program is saved it is tokenised in the usual way. When it is run, the command *Basaltinit, is executed before any BASIC. This then modifies the program, detecting alternative syntax for already tokenised keywords and any new keywords. These are replaced by BASIC CALL and USR to an address in the Basalt module. A single byte token is used to identify the new use. I call this process ‘Translation’ to distinguish it from tokenisation. In the module, the interpretation of the program following the token is similar to that in the BASIC module itself and a return is made to normal BASIC at the appropriate point.

Because BASIC documents the entry points to the routines it uses for interpretation, all this is entirely legal and it will work with any version of BASIC back to 1.05. The main penalties are the delay for translation, which is practically undetectable, and the overhead of CALL and USR instead of direct interpretation. However, all normal BASIC runs at without delay, only the alternative keywords are affected.

Translation also sets up necessary workspace and arguments for the alternative keywords. To do this I assume a knowledge about how BASIC itself uses its workspace. Some of it is documented, but none of this has changed since 1989. In that sense there is a risk that someone will break Basalt by a drastic change to BASIC, but I expect there would be some other serious consequences if this were done. ;-)

This outline of how Basalt works was established early and there have not been any major changes since. The Basalt module, unlike BASIC, can be RMEnsured for the version required and replaced on the fly.

Now I had a system for adding keywords, I wanted to incorporate the Toolbox in an OO fashion as BASIC’s Wimp programming interface. This was complete, with an event programming model, when the first version of Basalt was released in 2003. All the Toolbox calls were from assembler. The BASIC programmer interacted with windows and icons as objects with attributes and methods. The original assembler code has hardly been modified since then, although the BASIC programming model has been refined.

Of course, there is much more to Basalt than just the outline above and it may not be to anybody’s taste, but I want to answer the main points. It is possible to extend BASIC for all versions, without modifying the module itself and with only limited penalties. It is also possible to provide an OO model using the Toolbox to program the Wimp from BASIC.

As a postscript, I would like to note all the work that Justin did with the Toolbox and the useful extensions. I think these would would work with RO 5, but they are lost to us and we only have the public release from 2003. Even that is not universally used.

it can be used from C, C++, BASIC or Assembler with equal ease

It lies. ;-)

Perhaps not, it says “with equal ease” it does not state the level of ease…

Sin of omission?

Ease is not a term I would use at any level about the Toolbox and Assembler. BASIC? Hmm.

I feel a bit guilty about being reluctant to set a toolbox library in concrete for RiscLua. Other people have done some good development in this respect: 1. Michael Gerbracht and LuaFox, 2. Stephan Kleinert and Mitosis. LuaFox used a previous version of RiscLua but Mitosis uses the current one. Furthermore, the source directory in !Mitosis gives all the details on how to build it, making it very easy to understand his OO approach and his use of the toolbox. I recommend it for its educational value.

aaaaa

aaaaa

From what i could gather from justin’s site, it doesn’t look like toolbox really has a good system of dynamic typing, ex if properties would need to be added at runtime instead of precompiled static object definitions, even if he thought about that, it doesn’t look like he really did it.

Given that the ideas and concepts mentioned by Justin are, if implemented, in a fork that will be forever closed to us it is best to treat Justins text as ideas for possible guidance.

It’s like forward referencing :p

Sideways on a road we are not travelling.