Just to clarify: I haven't sold EZGUI for as low as $24.95 or $14.95. The lowest price has been $39. The reason for this is that the current PB market can not support my old price range and I tried all sorts of prices and have now found $39 to be the sweat spot for the current market. I had a number of orders this month and sales continue. Future development though is currently on hold until I see a change in the PB market.
Now to the discussion at hand:
The key to a new compiler is as follows:
Support for the entire PB command set is not important. What is important is "core" BASIC which has been around since the DOS days. Commands like IF THEN, FOR NEXT, SELECT CASE, etc need to be fully implemented. Such commands can not be owned by anyone at this point since it has been around for decades. Even TurboBasic (aka. Powerbasic for DOS) copied previous BASIC's for its core command set.
Next, the language needs to support core functionality for working with the WIN32 API. Things like pointers, data types, etc. need to be supported so calling the WIN32 API can done without issue.
Next, expandability is vital. Things like Macros, DLL compiling and possibly some standard static library format (ie. COFF). The language needs to be sufficient enough so it can compile itself at some point and then future development would be in the language itself, rather than using C++, Freebasic or even Powerbasic. Inline assembler and other features which make expanding the language using itself are vital.
Next, the language initially should be able to code in just a simple code editor (allow one to use any code editor they like). Once this works, then step 2 is necessary.
Sept 2: GUI framework and Visual Designer front end.
BASIC needs to come out of the dark ages. Bob Zale didn't recognize this. Bob was great at core compiler development, but he was very weak at building a high level GUI development system. In this day and age GUI development at a high level is vital, especially for commercial development. If you compare the different iterations of DDT, each new version was years behind each iteration of EZGUI. Bob was tackling the standard controls, while EZGUI was doing the common controls and graphics. Bob implemented a decent, yet simple, Graphic engine based on simple GDI commands, while EZGUI pushed on to advanced 2D Graphics, animation and OpenGL 3D. The point is that, Bob never could catch up to modern development for the GUI side of things. This does not nullify his great achievements, but it was a simple fact that GUI development has been mainstream for years and Powerbasic lagged behind. Look at what Eros has done with ThinBasic. It has been expanded upon in many different ways.
The key to a new generation of BASIC is expandability. Like what happened with classic Visual Basic. Microsoft did not envision what would happen by third party developers. Sadly classic Visual Basic was not built from the ground up like Powerbasic was. Microsoft purchased a visual scripting engine from a third party (which was not BASIC either) and turned it into Visual Basic and seemed like they didn't intend it to be a professional development tool. In later versions they had to fudge it by using a C compiler backend just to turn it into a real compiler, rather than just pcode.
Powerbasic itself only really became productive when the likes of EZGUI, Firefly, Phoenix, etc. came along. Remember the days of Powerbasic being advertised as an addon to classic Visual Basic ? When classic VB died, Bob was not prepared for the next level he needed to accomplish. Bob had to catch up with his own PB Forms simply to keep GUI development done using his products, rather than third party. But third party developers were far beyond what Bob was doing when it came to drag and drop design, code generation and GUI frameworks. It just was not Bob's area of expertise. Third party developers helped keep Powerbasic alive, while Bob tried to catch up.
One of the projects I have in mind is to turn my EZGUI 5.0 Visual Designer into a generic front end which can be used with any language, even Oxygen, C++, etc. By building a plugin engine which allows third party developers to turn my generic designer into a front engine for any language they choose, it might open up possibilities for the like of Oxygen, Freebasic, Purebasic, Thinbasic, etc. This could open up some possibilities for Oxygen.
I am not a compiler developer and it currently is beyond my skillset right now. I have looked at LLVM and that is another good candidate for building new languages (generate LVMM low level macro code and LVMM does the compiling to any platform). For those interested in building a powerful compiler, take a look at LVMM for a back end. Apple is using it and so are many other companies.
I am willing to consider working on the next generation of BASIC where my skillsets apply, such a front end visual designers and GUI frameworks. I am watching the progress of Oxygen with interest.