I know that a lot of people will argue the fact that FreeBASIC's goals include QB compatibility. As far as that goes, were not getting any more compatible than we are now and the QB quirks are only holding back the progress of the compiler into OO, inheritance, GCC back-end, etc. I think a rewrite of the core is necessary, we already have support for C libraries (C++ libraries to?) and inline ASM. We have to keep those, but release the current version with bug fixes as FB 1.0 and focus FB 2.0 on what we want FreeBASIC to be, with all the bells and whistles like GCC and drop trying to add QB and FBLite support in FB 2.0. Focus FB 2.0 on the explicit style of lang FB and implement all the C features and the GCC back-end. I'll repeat it anyway, QB is holding back FB.
Just my thoughts on the whole "Future of FreeBASIC" ordeal.
MOCKUP of FreeBASIC 1.0 Goals
If you want a compiler written in C++, there is QuickerBasic.
If you want a basic-to-gcc front-end, there is GNU liberty basic (GLBCC).
If somebody want to change FB in to a BASIC-TO-C translator, or in to a C-written code, he/she should start another project, with another name.
Other basic compilers have stopped development because the author was going to "rewrite from scratch", to have a better/faster/cleaner program, like GABasic, WxBasic.... Guess what, they are ALL DEAD.
Good, unique features of FreeBasic are the self-compiling code and the direct output to ASM code (that can even be used for OS writing). Please don't drop that.
Maybe a GCC front-end could be done using a RTL (register transfer language) emitter, it would allow multiplatform codes and a faster compiling time (FB=>RTL=>ASM=>native code, instead of FB=>C=>RTL=>ASM=>native code, or even worse FB=>C++=>C=>RTL=>ASM=>native code), but only AFTER more needed features (inheritance).
Since RTL is similar to ASM code, it should be easier building a RTL emitter than a C emitter, (somebody is building a translator from assembly to RTL at http://revenge.berlios.de/revenge-status.php), and the result would be the same.
If you want a basic-to-gcc front-end, there is GNU liberty basic (GLBCC).
If somebody want to change FB in to a BASIC-TO-C translator, or in to a C-written code, he/she should start another project, with another name.
Other basic compilers have stopped development because the author was going to "rewrite from scratch", to have a better/faster/cleaner program, like GABasic, WxBasic.... Guess what, they are ALL DEAD.
Good, unique features of FreeBasic are the self-compiling code and the direct output to ASM code (that can even be used for OS writing). Please don't drop that.
Maybe a GCC front-end could be done using a RTL (register transfer language) emitter, it would allow multiplatform codes and a faster compiling time (FB=>RTL=>ASM=>native code, instead of FB=>C=>RTL=>ASM=>native code, or even worse FB=>C++=>C=>RTL=>ASM=>native code), but only AFTER more needed features (inheritance).
Since RTL is similar to ASM code, it should be easier building a RTL emitter than a C emitter, (somebody is building a translator from assembly to RTL at http://revenge.berlios.de/revenge-status.php), and the result would be the same.
-
BastetFurry
- Posts: 255
- Joined: Jan 05, 2006 0:56
My 2 Eurocent:
The main goal of fbc is done, QB45 in 32bit as FOSS.
Lets call that fbc 1.0, bugs will be fixed when they arise, but no further development in this branch.
The next step would be freeing fbc from the quirks that hinders its advanced development, lets call this fbc 2.0.
This branch will be in development, if some QB compatibility quirk hinders development it gets kicked out.
Besides that, there should be a better documentation of the compilers inside workings, i couldn't make heads or tails from the code because i couldn't get the idea behind it. I could get the idea when i make the source a bedtime reading for the next three week, but that wont work for me and most people out there when we just want to assist hunting for a bug, the dreaded reallife wants its attention too. ;)
The main goal of fbc is done, QB45 in 32bit as FOSS.
Lets call that fbc 1.0, bugs will be fixed when they arise, but no further development in this branch.
The next step would be freeing fbc from the quirks that hinders its advanced development, lets call this fbc 2.0.
This branch will be in development, if some QB compatibility quirk hinders development it gets kicked out.
Besides that, there should be a better documentation of the compilers inside workings, i couldn't make heads or tails from the code because i couldn't get the idea behind it. I could get the idea when i make the source a bedtime reading for the next three week, but that wont work for me and most people out there when we just want to assist hunting for a bug, the dreaded reallife wants its attention too. ;)
-
John Spikowski
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
I couldn't agree more. It's hard enough to find people with a talent at that level and not have developer docs is sure doom if the orignal developers move on.Besides that, there should be a better documentation of the compilers inside workings, i couldn't make heads or tails from the code because i couldn't get the idea behind it. I could get the idea when i make the source a bedtime reading for the next three week, but that wont work for me and most people out there when we just want to assist hunting for a bug, the dreaded reallife wants its attention too. ;)
Here is the ScriptBasic Developer Guide as an example what an open source project needs to attract new team members to the effort. Not many programmers like writing docs when coding is much more fun.
John
I have been looking at the source code for the compiler for a little while. I can follow it but it could definitely use a lot more comments. :-)BastetFurry wrote: ...there should be a better documentation of the compilers inside workings, i couldn't make heads or tails from the code because i couldn't get the idea behind it. I could get the idea when i make the source a bedtime reading for the next three week, but that wont work for me and most people out there when we just want to assist hunting for a bug, the dreaded reallife wants its attention too.
Maybe a new wikki page could be started where people could contribute their understanding of the structure and flow of the compiler and how it all "fits" together.
Thats the kind of thinking that will hurt the freebasic advancement, and the whole purpose of 2 different versions, so that people that want QB can use the 1.0 version and people (most people I think) that want to used a more andavned version and that don't care about the qb compatability can use the 2.0 version.jdebord wrote:Abandoned since 2002 apparently...angros47 wrote:If you want a basic-to-gcc front-end, there is GNU liberty basic (GLBCC).
I think that the FB project should not abandon QB compatibility, even if a more sophisticated (or C-like ?) version is developed independently.
Any significant development reaches a point where it is necessary to stop and think. It is quite normal to blame “lack of documentation” as the reason for the halt. Documentation does not solve the problem however, it is often the kiss of death. What really stops progress is the continuous rise in complexity that occurs when humans try to make things fit. Software is developed and tested until the programmers understand the problem and the specifications can be written. Unfortunately this means that programmers do not understand the problem until they have finished the prototype. Naturally they want to start again and do it better, but there is never time for that.
As complexity accumulates the size of the developer pool is reduced. There is a limit to how much complexity any individual programmer can handle. As development continues, self preservation requires individual developers to escape the project. It is now very difficult for a new developer to enter the FreeBASIC development group due to the accumulated complexity.
Once complexity accumulates to a critical point the development ceases in that direction. A back step followed by a degree of rationalisation can side step around the obstruction. Only then can progress again be made. FreeBASIC is a collection of dialects that represent these waypoints. It has been necessary to keep the past dialects to maintain backward compatibility.
FreeBASIC 1.0 should be a bug fix of the current menagerie without over-emphasis on documentation or adding more features.
If you want the features of C++ without a cryptic syntax then a translator is an obvious choice. But that is another project.
As complexity accumulates the size of the developer pool is reduced. There is a limit to how much complexity any individual programmer can handle. As development continues, self preservation requires individual developers to escape the project. It is now very difficult for a new developer to enter the FreeBASIC development group due to the accumulated complexity.
Once complexity accumulates to a critical point the development ceases in that direction. A back step followed by a degree of rationalisation can side step around the obstruction. Only then can progress again be made. FreeBASIC is a collection of dialects that represent these waypoints. It has been necessary to keep the past dialects to maintain backward compatibility.
FreeBASIC 1.0 should be a bug fix of the current menagerie without over-emphasis on documentation or adding more features.
If you want the features of C++ without a cryptic syntax then a translator is an obvious choice. But that is another project.
The compiler source code is complex and unless the user has a very good grasp of compiler construction theory then it is very easy to get lost in it. The lack of comments and documentation certainly doesn't help. The casual programmer who wants to help by finding bugs in the compiler or implement new functionality is certainly left in the cold... or left with a really long learning curve.
Has there been any consideration given to writing the grammar of the language using well known and tested parser generator programs to do the actual parsing? The developer could then concentrate on building and refining the grammar and producing the emitted code through dealing with the parse trees that are created by the generator. I think of a tool like the GOLD Parser that would automate a lot of this stuff while still freeing the developer to use FB for the code generation to gcc. IIRC, GOLD Parser already has a grammar created for VB.Net so maybe an FB grammar would be able to be written as well. Just a thought. Of the top of my head it would seem like a good idea that would reduce the complexity and increase the participation in the development process. What would be the counter argument to this? Thanks.
Has there been any consideration given to writing the grammar of the language using well known and tested parser generator programs to do the actual parsing? The developer could then concentrate on building and refining the grammar and producing the emitted code through dealing with the parse trees that are created by the generator. I think of a tool like the GOLD Parser that would automate a lot of this stuff while still freeing the developer to use FB for the code generation to gcc. IIRC, GOLD Parser already has a grammar created for VB.Net so maybe an FB grammar would be able to be written as well. Just a thought. Of the top of my head it would seem like a good idea that would reduce the complexity and increase the participation in the development process. What would be the counter argument to this? Thanks.
Yeah, I guess it will first come back to the primary discussion about whether the legacy QB syntax should be maintained or not. Personally, I agree with a previous poster who said that the QB features should be frozen now as a version 1.0 snapshot and then move ahead with FB only features from there. QB has been a great language for a long time but just how long should it be held on to to the detriment of forging ahead with new syntax and less quirks? It appears that a pretty stable and complete 32-bit version of QB compatible syntax already exists in FB. Is there really any need to continue support for it indefinitely? Split the project if necessary. People will gravitate to the feature base that they prefer and you'll see development continue because people will work on what's common and important to them rather than $#@$& and complain with each other about "direction". I believe Chaos said once that he was seriously in favor of forking development (hopefully I am not putting words in his mouth here).
McLovin, the fbc source has a BNF-style grammar sprinkled throughout the source (primarily in comments preceding the src/compiler/parser*.bas::c* procedures), but unfortunately there is not a single place to look. A few users have expressed the desire to consolidate these comments into a single document; that would require checking their validity against what the parser's (and other modules') procedures actually do. But, this would be a great first step in creating a specification for FB, allowing one to possibly see areas for improvement and/or expansion in the current source code much easier.
Stuff like gold parser are usually not used for the bigger production compilers but more for tools. They are cheap to use, but limited.McLovin wrote:hen concentrate on building and refining the grammar and producing the emitted code through dealing with the parse trees that are created by the generator. I think of a tool like the GOLD Parser that would automate a lot of this stuff while still freeing the developer to use FB for the code generation to gcc. IIRC, GOLD Parser already has a grammar created for VB.Net so maybe an FB grammar would be able to be written as well. Just a thought. Of the top of my head it would seem like a good idea that would reduce the complexity and increase the participation in the development process. What would be the counter argument to this? Thanks.
I don't know the exact reasons (the choice was already made when I joined FPC), but problems you often hear are amongst others ambiguities that need complex context, performance reasons, quality of error generation (not stop at first error) are main reasons. Moreover, the grammars for production compilers tend to become simply unwieldy, as productions are added to fix/diagnoze corner cases.
Another problem is that you don't have a complete grammar up front in a compiler with compatibility modi anyway.
But you could start trying to write one anyway. Even if it fails for the compiler, it could still be used for tooling like doxygen like documentation generators, converters, prettyprinters, testsuite comparison etc. If it is really a success, the compiler devels could adopt it for the compiler too.
A grammar is also great to create documentation that describes the dialect.
Btw, what I miss a bit about the whole discussion is a bit of nuance about the dropping QB compatibility issue. At least if I got the original post ok.
At least I assume the devels are simply thinking in a direction where for 2.0 QB compatibility is not directly the top priority, but that doesn't automatically mean QB compat is fully dropped? It means some of the more quirky syntaxes and ambiguities are dropped, no more?
marcov, in case you haven't noticed, no developers have posted in this thread. cha0s expressed his desire for a complete rewrite in a different thread, but since he will not be an active developer anymore, you have to take that with a grain of salt. It was unfortunate for anonymous1337 to speak for and mislead others like that, but here we are. Anything posted in this thread about rewrites, versioning and other issues not coming straight from the development team is simply user opinion and speculation.
Personally, I don't see that anything has changed in the past week except for the fact that cha0s is now officially "on hiatus", which, admittedly he has been for a while anyway. And I will, just like many others will and have been doing, continue to help out where I can. For example, I've set up Natural Docs in my working copy of the compiler, and have begun documenting parts that I can understand; currently I'm working on the lexer, as it seems very straightforward to me. If it seems to be working out OK, I will submit a patch. I've looked into modifying doxygen for FB support in the past, but I'm not very familiar with flex, and its language module is one huge monolithic mess.
Personally, I don't see that anything has changed in the past week except for the fact that cha0s is now officially "on hiatus", which, admittedly he has been for a while anyway. And I will, just like many others will and have been doing, continue to help out where I can. For example, I've set up Natural Docs in my working copy of the compiler, and have begun documenting parts that I can understand; currently I'm working on the lexer, as it seems very straightforward to me. If it seems to be working out OK, I will submit a patch. I've looked into modifying doxygen for FB support in the past, but I'm not very familiar with flex, and its language module is one huge monolithic mess.