XB# Compiler (xbsc), by Gustavo Ramos http://www.grmexico.com.mx/xbsharp/ XB# (XBasic Sharp) will be a BASIC object oriented language, statically typed, with an easy syntax, yet capable to allow low-level programming for the most experienced programmer, and targetting the CLR initially. But ideally, it will have backends for targetting directly physical machines (Intel, Sparc, etc.) and executable formats. XB# existence reasons I love the XBasic in its original fashion. It's the best tool for high- performance programs you know always will be run on Windows or Linux and in an Intel 386. Damn! That's a serious restriction, and I could not sell the idea to my boss/clients, who for sure will tell me "Yeah, I trust you, I love your XBasic idea, deploy it in our Solaris/Sparc server". And any large application writer would want to enjoy the portability freedom. In most large organizations this is a must, a decision that a single software architect or developer cannot change. There are several scenarios where XBasic fail to qualify as the first- class citizen in compilers. And not because the language, but because the incompatibilities. 1. XBasic has a very good memory model... But it's not good at threading. It's not good for writing dynamic languages for use from another languages. Solution: It should use a standard memory model. 2. XBasic is not small enough in terms of distribution. Every programmer has to take the responsibility of making sure compatibility with the system- existing xb.dll is the right version for his program. Or to replace it. Or not to touch it, for the sake of non-intrusive software. Or to use its own copy of xb.dll in the program directory. What ever. Old problem of DLL hell is in XB. A terrific work has been done in XBLite, and size is not anymore an issue in that XB implementation (altough DLL hell remains, but I think they are working on eliminate the tiny runtime library). David Szafranski made an incredible work at cleaning up the compiler from the libraries, PDE, grahpics tools and libs, etc. Problem solved, but only a subset of the XB community will take advantage of it, as XBLite, the David's version of XBasic is just for Windows. 3. It's damn fast, but you can't use debuggers and other development tools for your XB programs. That will leave the XB community isolated from the huge amount of development tools. That means we should build debuggers, profilers, etc. I'm not saying that could not be possible, neither is not a good idea. I'd love to hear someone is taking over such a tasks. But in the meantime, there's no tools at all, other than the XBasic PDE. Solution: Target a standard code-generation format, understandable by other tools. 4. It's not easy to consume third-party libraries, and it's hard to find DEC files, or to get support from vendors. XB developers should have a very good understanding of linking for being successful in lib's integration. So, tough the language is very easy, not everybody could use it with his favorite library. It would prove error-prone to put novice developers hands at XBasic in it's current state, so anyone wanting to hire several developers and make a project with them, should hire higher-cost developers. It's a pity that many people don't use XB just because the lack of skills for library linking. Solution: A C/C++ preprocessor for consuming .h files should be great. 5. XBasic is not portable. It cannot target another processor, and does not have a solid build system, so it is not easy to target another operating system. Solution: Make one backend for each processor architecture, and use solid and proved tools for maximum portability between operating systems. This is not easily achievable. XBasic implementation does not have well separated the front end and the backend, so the previous solutions (except the 2nd point) are not reachable using the current code, unless someone make a big rework on it. I don't like good projects forking, because the user base gets divided. I would love to work with the existing XBasic community and developers, and will love to take this effort as the evolution of XBasic, not a branching. I would love to end up with a compiler that will satisfy XBasic users, XBLite users, and people that tried (and keep trying) to make difficult things work. For tacking the large task, I don't want to be involved in a rather artesanal task, and want to use existing compiler tools, like the great ANTLR (http://antlr.org and http://antlr2.org) by Terrence Parr. ANTLR generates Java or C#. That will make us earn a lot of time, and we'll be sure that the lexer and the parser are correct. Why reinvent the wheel? Temporary it will be fine to have a compiler in C# that have a backend for generating CIL code. We'll take advantage of debuggers, unit testing tools, profilers, and ANTLR. Later, we'll write an i386 code generator, and translate the compiler to XBasic, until it is self-hosted. Then, the C# version of XBasic will die, as all the new compiler improvements will take place in the XB version, and quickly, the C# version will get outdated. However, that day we'll have backends for both CIL and native code, and we all the community could then decide the future of XBasic, whether we'll keep .NET integration or not, whether we'll implement Java compatibility too or not, whether we'll implement a C/C++ preprocessor for library consuming or not, whether we'll add OOP or not, and so on. But that should be a community-driven process. Thus, the XB# name will exist during that temporary phase. Once we get the shiny new XBasic implementation, XB# should disappear, as it will have accomplished it's original objective. Roadmap First we'll write the compiler using ANTLR, and targetting the CIL. Once the compiler works decently, the source code should be converted into static code, that doesn't make use of OOP, yet fully functional (that fact should be unit- testing-proved :-), as later we'll convert the C# generated code into XBasic. The next step will be to write the backend for native code generation. Easier I think, altough I am not an asm wizard. We should debug thoroughly this phase in preparation for the next. All demo programs should run without problems. This should be the correct time for implementing the build system, as we'll need it for building the demo programs. As the next step, we'll translate the static, non-OOP, almost procedural C# to XBasic. That should be easy. But it's important to make sure first that the code doesn't use .NET specific features (like generics, collections and the such), and if adjustments are needed, made it before the translation (again, unit- tested). Once translated, we'll have a basic front and back ends for the XB compiler. It may have many bugs due to the translation, but should be easily tackled down. At this point, we should have a compiler fully interchangeable with the current implementations of XBasic, and naturally, this should be the right time for the community to switch to the new version. After integration, the next step should be to integrate a C/C++ preprocessor for avoiding DEC files or whatever the XB future is decided. It may make sense to decide on the OOP future prior to the preprocessor, so we'll know how to construct the preprocessor, for properly dealing with OO libraries.