The HiSoft BASIC compiler may have been around £25 when it came out, but I have no doubt that for regular BASIC programmers it was worth it. So far, I've only used the 48K version, which I'm reviewing here although I believe the 128K versions are even better.
Integrating seemlessly with the native BASIC development environment, during regular programming, you can quite easily forget that the compiler is even loaded at all. All usual BASIC operations like editing your code and RUNing it in interpreted mode in the usual way are almost completely unaffected by the presence of the compiler. The only differences of note are that there's slightly less RAM available and there's a new interrupt handler running in IM2 mode, but these things generally don't make any difference to everyday BASIC programming.
The compiler commands are very simple and entered in immediate mode such as *c (compile your program), *r (run your compiled program) and *x (clear out previous compilations from memory). As with other compilers on the Spectrum, the screen area is used as the working area when compiling your code, so as to preserve memory. Compilation is surprisingly quick. It's also really handy how both your interpreted and compiled program versions can reside in RAM at the same time and be RUN independently of each other. Compiler directives are implemented in REM statements in the BASIC program with most important one being "REM: OPEN #' which means "start compiling from here". But an overwhelming advantage of the directives is the use of datatype declarations. You can now use 16-bit signed or unsigned integers from BASIC and also specify the lengths of un-DIMMED strings.
The lack of integer datatypes is something which unfortunately causes all operations in Sinclair BASIC on the ZX Spectrum to be performed with floating point arithmetic, via the calculator stack and although there are internal shorthand notations for 16-bit integers, the system would never be as quick as having a native 16-bit datatype within the BASIC language itself. It's really good then to see this issue addressed here. Two 16-bit numbers can be added on the Z80 CPU in a single instruction, vastly outperforming the addition of two 5-byte floating point numbers. But of course the other main advantage of having integer dataypes is the space saved in arrays. In your complied code, an array of a thousand integers would only occupy a little under 2kB, wheras stored as floating-point values would occupy almost 5kB and so on. So the enabling of these more efficient datatypes from BASIC makes the compiler useful in itself.
Then of course we come to the main objective of the compiler, to increase speed of BASIC programs. Here, the speed really can become several times faster than the original program (or even more when declaring integers), making sluggish games playable, or the impractical practial, without having to resort to manual programming in assembler. Of course the compiler does have limitations. If the source program is badly programmed, having flickery or jerky graphics then that will obviously persist in the compiled code too. There are also certain limitations and unsupported commands and tricks, mostly due to the fact that all compiled program data is statically allocated at compile time and there is no mechanism to allocate/deallocate memory dynamically. Also, things such as computed GO SUBs have to be manually set up for compilation using compiler directives. However, most programs can be converted to be compatible and if compilation is borne in mind from the beginning, then it's easy to write a 100% compatible program from the off without sacrificing any flexibility in what you can achieve.
Another impressive touch is that you can BREAK out of even your compiled program as long as the compiler is resident, thanks to the custom IM2 routine.
So overall, it's just an excellent product for BASIC coders and really well implemented.
