Quadrescence wrote:
The FreeBASIC Compiler in Standard C89. After a specification is written, FreeBASIC (as in, a compiler) should be written strictly in ANSI C89, and code should adhere precisely to the standard, and the implementation should adhere exactly to the written specification.
Rational. What benefit does C89 give us? Correctness. If we know what C should do, we will know what FreeBASIC should do if it's written in C.
Nobody proves programs of that size mathematically. So while this sounds like reasonable, it doesn't add up IMHO.
A implementation of Basic in C that satisfies C89 rules perfectly doesn't automatically implement the correct FB rules.
I do think there is some intuitive point in that (avoid that problems with unstable compiler leave you without a running compiler in the FB-FB case) , but people have done that before (C is an example here), and there are standard ways to deal with that.
A similar fundamental thought mistake is in the portability suggestion further below. Being made in C89 makes only the C89 code implemented in it portable. It doesn't make the x86 codegenerator in it suddenly start emitting powerpc code.
Why not rewrite FreeBASIC in FreeBASIC right away? FreeBASIC isn't standardized nor well-documented. How can we be absolutely sure FreeBASIC runs exactly the way we expect it if it's compiling itself? I argue we can't without checking very extensively.
You run a testsuite. How else can you be sure that what you write down in C does exactly what you MEAN it to do?
The other large reason for writing it in C is because C is very, very portable. We all know that very well.
This is a dangerous (and incorrect) mind-jump too. While this goes for a normal application, it doesn't go for the compiler because it contains a large CPU dependant part (the codegenerator, assembler parsers etc), that must be explicitely ported.
Worse, _those_ non automatically ported parts are the parts that are actually the hard parts. Why? Large parts of the rest of the compiler are not that terribly OS dependant, at least not to the part that is already abstracted by the standard runtime. Files opening/reading - stringprocessing - writing are simply not the biggest porting problems. It _IS_ the OS and CPU dependant part that is the problem. And doing that part in C89 won't make it work on another sstme.
Rewriting in strict C89 would allow FreeBASIC to be ported to other platforms very easily. I think this is very beneficial, especially for up-and-coming 64-bit processors. It's well known, or at least it is to me, that FreeBASIC is rather tedious to install and get working (I don't know if it has been done) on a 64-bit operating system.
This has to do with a missing FB x86_64 codegenerator, not portability of the language in which it was implemented.
Rewriting to C89 won't help one bit with that, since it will leave you with a 64-bit compiler emitting 32-bit code.
SO you will need to add a x86_64 backend no matter what, and to do it in FB you might not directly have to rewrite, or make it very efficient.
C++ would definitely make things easier, especially for FreeBASIC's head to more object-oriented nature.
I think OOP-with-inheritance will improve maintenance. But that doesn't automatically makes a case for C++, one could also make a case to start adding this feature to the current compiler so that it can act as bootstrap.l
I argue that, for a compiler, C++ will likely lead to less efficient and sloppier implementations of things (no, I am not saying good code can't be written in C++, or bad code can't be written in C).
Agree, also I'd argue that C++ has a tendecy to overengineer, be overly complex and has horribly bad characteristics of the compiler (understanding the standard alone requires a lot of skills)
Lastly, not only is the C++ standard large, so is the run-time library, and its availability on other platforms in lesser than that of C's.
And its stronger version dependancy. C++ can't even link with different C++.
Write a FreeBASIC Compiler in "Standard FreeBASIC". "Um, Quadrescence? We just wrote the entire compiler in C. You want it in FreeBASIC now?" Yes.
Rational. I do think, in light of v1ctor's and others' views, that FreeBASIC should be a self-hosting compiler. It's kind of a . . . part of FreeBASIC's legacy (?). But why didn't we start with just writing it in FreeBASIC? We didn't have any insurance in correctness of the generated code for every case. Some have argued on IRC that we wouldn't have insurance with C-generated code either.
You need a stable starting point. But maybe the old FB stuff would have been more standard now if the effort had been put into it.
Note that a problem with FB->FB translation is also that you are creating a not exactly trivially sized codebase in FB. Long term dialect compatibility becomes way more important then.
I've refuted that with the fact that, though they might be correct for some probability, that probability would be a hell of a lot less than writing it in a language for compiler that didn't follow any clear rules. C is old, and very, very well tested both as a language, and as a good language implementation for systems-programming.
But lousy for compiler work, since basic structures are hard to get typesafe, and must be emulated manually.
To summarize, my ideal road-map for FreeBASIC is this:
- Write a FreeBASIC specification.
- Find community approval.
- Write a conforming compiler in ANSI C89 strictly.
- Test and test and test, iron out all the buggies.
- Write a conforming compiler in "Standard FreeBASIC"
- Test and test and test, iron out all the buggies.
- Continue with the development of FreeBASIC and its respective standard.
My big problems of that are
* "double work", and (I want one compiler, I have to write two to get there, including one I'm not interested in)
* a long time of not investing in FB code (but investing in C, doing that
work in FB would lead to high quality experience in using/improving FB)
* finding the ideal "program FB in FB" and "program FB in C" skills might not be in the same person, frustrating many of the core, alienating potential new ones.
* I don't buy the portability argument. Often the tighter coupling with a C compiler makes it harder rather than easier (e.g. having complete free C toolchain, on windows)
* the C part would be in a non OOP language, which is unnecessarily hard. If throw away anyway, then even C++ would be better (though more of a management problem)
My own list would be
- finalize the core FB dialect, preferably with OOP with inheritance. (good for symboltables and complex heterogenic trees)
- continue/start developing testsuite of typical test programs (e.g. old bugreports)
- branch
- Use the old "stable" branch to develop the new branch. Work around problems in the old branch by either relucatantly updating it in extreme cases and with ifdef otherwise.
- When the new branch autocompilate is systematically better than the old, branch a release branch and stabilize that branch to release. That is then the new stable compiler to develop the "unstable" branch.
- repeat ad infinitum. Keeping enhancing dialect.
