Presumably because no-one has had the time to do the necessary work. It would happen automatically if the FPE coding were converted seemlessly to use the new FP hardware, but I think that is a major task.RichardRussell wrote:Why isn't BASIC64 the default ('ROM') version on a machine with FP hardware? Presumably memory usage is a little greater, with floats needing 8 bytes each rather than 5, but are there any other reasons? Is the 64-bit version fully up-to-date with the later features such as DIM LOCAL?
BBC Basic V and VI are the last official versions supplied with BBC branded Acorn computers. Any BB4W extensions used in Rosetta code make them non-BBC Basic and it is those examples that should be labelled as something other than BBC Basic!tenochtitlanuk wrote:Two observations.
1 Rosetta Code uses the section title BBC BASIC, but many examples use bb4w-specific code. This could potentially confuse & put people off Pi's BBC BASIC, 'tho I appreciate it often shows really neat aspects of bb4w.
2 More of a problem is that code copy/pasted from Rosetta Code viewed with NetSurf HAS to be first search/replaced, since many of the spaces are changed to hard-spaces. A typical example had 420 hard-spaces & they cause BASIC to barf badly.
I don't know a good answer to prevent confusion. I suppose I could go through all the examples & note those which need modifying for PI. I don't have the time.
It doesn't seem sensible to add 'Pi BASIC' as a new language & start from scratch, & that isn't the implementation's official name anyway.
This 'feature' has been fixed in the current development versions of NetSurf. (The version on the ROOL disc image is the so-called 'stable' version, but IME 'stable' software has a tendency to have more bugs, as well as fewer features, than cutting-edge software. NetSurf is far from the only program with this problem.)tenochtitlanuk wrote:2 More of a problem is that code copy/pasted from Rosetta Code viewed with NetSurf HAS to be first search/replaced, since many of the spaces are changed to hard-spaces. A typical example had 420 hard-spaces & they cause BASIC to barf badly.
I am sure Richard will have something to say about that! AFAIK he wrote the original specification and has the rights on all machines except RISC OS.sawdust wrote: BBC Basic V and VI are the last official versions supplied with BBC branded Acorn computers. Any BB4W extensions used in Rosetta code make them non-BBC Basic and it is those examples that should be labelled as something other than BBC Basic!
Completely untrue. The 'Wilson' and 'Russell' branches of BBC BASIC are equally deserving of being called BBC BASIC! The specification was after all developed jointly by Acorn and the BBC, and neither party has an exclusive claim to be the custodian of the language. I even have formal written permission from the BBC to call my products 'BBC BASIC'.Any BB4W extensions used in Rosetta code make them non-BBC Basic and it is those examples that should be labelled as something other than BBC Basic!
You have missed a category:RichardRussell wrote: It is a great shame that, despite the ongoing efforts by the likes of Jonathan Harston, ARM BBC BASIC still lags so far behind the specification of BB4W. As far as Rosetta Code tasks are concerned a large number simply could not be solved in ARM BASIC or Brandy.
The BBC BASIC solutions (over 440 at the last count) basically divide into three main categories:
- 1. Those that use 'generic' BBC BASIC code and should run OK on BB4W, ARM BASIC and Brandy. Inevitably not all have been tested on all three platforms so there may be a few examples where they don't run, but in such cases it should be easy to correct them.
2. Those that are marked 'Works in BBC BASIC for Windows' but could be modified to work in the other dialects without too much difficulty. Typically they use the line-continuation character to improve layout (RC doesn't like very long lines) or the EXIT statement (can usually be fudged in ARM BASIC with a GOTO or a conditional block) or 'byte' variables (could be changed to integers) etc.
3. Those marked 'Works in BBC BASIC for Windows' but which cannot realistically be adapted to work in the other versions. Typically they use structures, or function pointers, or event interrupts etc.
I simplified the list in other ways too. For example those solutions that can be adapted to run under Brandy but not ARM BASIC (e.g. because of the use of long strings) or ARM BASIC but not Brandy (e,g, because of the use of assembler code).You have missed a category:
4. Those that can be adapted to work with ARM BASIC with Basalt extensions.
These BB4W solutions use timer interrupts:I have not seen a Rosetta task using interrupts yet - could you suggest one?
But ...RichardRussell wrote: As you know I am well aware of Basalt, and as a way of extending ARM BASIC without actually modifying the existing interpreter it is very clever.
I guess that's one of the main reasons why I'm not enthusiastic about it. One of the great strengths of BBC BASIC is that it isn't bloated like so many BASIC dialects are; only the essential and most commonly used functions are built into the core language. Everything else is done via libraries, which you can choose to install or not - I sometimes describe BBC BASIC as the 'C' of the BASIC world! That way 'compiled' executables (and of course that is my main interest) are as small and fast as possible - considering that the language is interpreted.To be brief, Basalt has dozens of function keywords
AFAIUI BB4W produces a runtime containing only those bits of the interpreter and libraries required to run the program, making it 'lean and mean'. However, if your machine had many BASIC programs running, as with RISC OS, that could result in duplication, making it less 'lean'.RichardRussell wrote: I have every respect for your technical achievements in Basalt, but it's taking BBC BASIC in a very different direction to that which I have been following, and goes against the philosophy of BBC BASIC as a 'lean and mean' language which I feel so strongly about and which I think was shared by Sophie all those years ago.
Faster I would of course believe, but smaller? In my experience tokenised and crunched BASIC code is usually more compact than the equivalent machine code. But either way I don't think it has much relevance to the current discussion because BB4W libraries are commonly partly or mostly assembler code as well.A keyword written in machine code can be an order of magnitude or more faster and smaller than the equivalent BASIC code
You might replace a routine written in BASIC to do a particular job, say make a string uppercase, with a single keyword written in machine code and achieve such an increase in speed and saving of code. You cannot count the keyword code, because that is a shared resource. However, if you write a specific machine code routine within your program, then the size will quite possibly not be reduced.RichardRussell wrote:Faster I would of course believe, but smaller? In my experience tokenised and crunched BASIC code is usually more compact than the equivalent machine code.A keyword written in machine code can be an order of magnitude or more faster and smaller than the equivalent BASIC code
I wish I had the time to get involved with this, too.To bring this back on topic the number of Rosetta Code tasks solved in BBC BASIC is now in excess of 450, and should shortly overtake the current leading BASIC dialect - PureBASIC. I particularly enjoyed coding the 'QR Decomposition' task because the built-in array/matrix arithmetic allowed an elegant translation of the mathematics into BBC BASIC
To create a 'shared resource' in Windows one would have to make it a DLL. From time to time I've been asked whether it would be possible to compile BBC BASIC code to a DLL, but it would be difficult to meet the requirement of being thread-safe.You cannot count the keyword code, because that is a shared resource
It is quite possible to make BASIC libraries a shared resource for any BASIC program in RISC OS. I wrote a module to support that way back in the mists of time, but it was taken up by only a handful of programmers, who have left the scene now. Mainly, developers include libraries within their applications, which means much duplication, or they do something similar to BB4W and extract and crunch a runtime. This still leads to more bulky programs than I prefer. But memory is cheap ...RichardRussell wrote:To create a 'shared resource' in Windows one would have to make it a DLL.
That's not necessarily such a bad idea, because it guarantees that the version of the library used by the application is the one with which it was developed and tested. On the other hand it means that if a bug in a library has subsequently been fixed the application won't benefit from it. There is no 'correct' answer.Mainly, developers include libraries within their applications