MOCKUP of FreeBASIC 1.0 Goals

[anonymous1337]

(Lurking a bit, I've seen the change of heart/direction fbc is going through. Here's my ideal mockup for future fbc plans, written as though the developers themselves are saying it.)

After years of development, we are announcing that in the coming months, FBC will undergo significant changes to further its development. We have plans for both our current, "old" fbc and for a new fbc. We feel that such important changes should first be discussed with the community. Please give us your feedback, and remember, it's OSS; Everyone's opinion matters.


"Old" FBC - Current Compiler Goals:

Due to bottlenecks encountered in FreeBASIC's development, full implementation of FB's desired features is becoming increasingly difficult. Proper completion of FBC in its current form would require major rewrites and modifications of an already complex existing code base.

In light of this, it is unlikely that the current FBC will meet its goals of being a GCC frontend or even have a full functional C emitter. Instead, effort will be put forth in implementing features on the TODO list even if they can't all be done "properly". While platform portability, GCC optimizations and C++ lib compatibility is highly desired, the work needed to make FBC support these features is overwhelming.

To Summarize - Instead of waiting many months to morph FBC into what we need, we're going to try and get in features like Inheritance, Polymorphism, Templates, etc., even if the implementations aren't exactly "standard".


New FBC (FBC 0.3.0b - 1.0) Goals:

Once the original FBC has its remaining major features implemented, development will focus on rewriting FBC in GCC C++. From the beginning, the new FBC will be designed and built as a GCC frontend.

A new language specification will be used to aid FBC's development. This will make FBC easier to learn and maintain, and also let FBC become standardized. The compiler source will also be documented, using shorthand in code comments to reference sections of the FBC specification (which will be available online if possible). Using the shorthand requires little effort from the developers, while still providing insight on the compiler's internal workings.

Example Internal Documentation

Code: Select all

    // SPEC::FBC_AST_VAROP::3.1
    // SPEC::Section Title (Head)::Sub-Sections
    if( fb_node.op == OP_ADD ){
        // ...
    }

FB's QB-like syntax has been particularly difficult to work with at times. While a new language specification would make implementing quirky/archaic features easier, we now have the opportunity to change FB's syntax to meet its goals. The developers are aware that everyone has a different opinion about what is right for FB, and while FB's goals seem contradictory at times, we're confident that with time and effort, we can, as a community, let FB evolve to better suit its purpose.

Aside from the already stated goals, FBC will retain the goals that the original one eventually came to have. Now, however, with proper planning and development, the "behind the scenes" work will become much easier and overall, FB will become 10x better than it ever was.


Thank You,
FreeBASIC Development Team
Actually written by anonymous1337
Comments Appreciated

[Mysoft]

just that... WHAT THE HELL IS GOING ON? ._.

ok... and computers will not be used as mere calc tools... (who said that?) :P

[vdecampo]

@anonymous1337
I thought you left?

[eodor]

just that... WHAT THE HELL IS GOING ON? ._.
...

it's begining of the end...

[jevans4949]

If the devs consider a rewrite and changing the syntax is really necessary, can I suggest that the current version, with whatever fixes are to hand, be released as FB version 1.0.

The devs can then go away and develop FB version 2.0 without constant disruptions of new syntax to the current user base.

We probably need to establish a maintenance team to fix bugs in the 1.0 version, but if version 2.0 is going to be a complete rewrite there will be little need to synchronise the source code.

However, I think there is a danger that the new version could become the version most people never wanted.

[Lachie Dazdarian]

I agree with jevans here. If FB is going to be rewritten, please make the best of the current code and release a 1.0 version. Out of respect for the current userbase.

BTW anonymous1337, think twice before making another I'm leaving messages.

I really don't know what possesses the people to make them.

[Hexadecimal Dude!]

I think quite a few groups have been thinking along similar lines recently, and to me it represents the start of possibly the most positive phase in FreeBASIC development so far, one in which the community which FB nurtured becomes empowered to create alternatives to their various problems with FBC.

Now for specific (friendly!) criticisms of your specific vision.

I think that, first of all, it would be useful for two separate groups to work on the different versions of FB you set forth. These groups could actually consist of the same people, I just think that it would be useful if people could join one or the other without being seen to be working on both.

Secondly, I think it might be a waste of time to try to add advanced features to the "old FB", rather, fixing it's bugs and then calling it finished, possibly labelled FB 1.0 as jevans suggests, would be better.

Third, I don't think abbreviated comments in the source would be as useful as long ones. Maybe as a temporary thing, to be extended later.

Fourth, even though I'm one of the biggest haters of quirky statements, I think that we risk alienating a section of the community by removing them, and for a goal, namely having a clean language, which we could better achieve by abandoning the BASIC idea all together, which I don't think anyone wants.

Perhaps that point is a little nuanced, what I mean is, removing those features might move us a little way down the continuum between ugly hax and elegant beauty, but it might be a bigger loss of community happiness than is worth this. Although I agree than in general a review of syntax would be nice.

Finally, and this is more of a personal thing, I don't know how good C++ is as a choice of language to develop in, I know that self hosting is a pain, but I think that, the language which everyone here codes in as a hobby is FB, and the therefore there is a larger well of potential devs in that language. There is a "where is everybody" argument that so far not many have stepped forward (and I think all the current devs probably prefer C++), but FB is a young language. I started coding as a serious hobby the year FB was released, and only now am I starting to feel confident enough to consider working on the compiler.

Anyway, now I'm done playing devil's advocate, I think the take away is that this is not the beginning of the end, it's the beginning of the beginning, and if it's scary it's only because the stabilisers have fallen off, or the reaction has reached critical mass.

2009 FreeBASIC is about to E. X. P. L. O. D. E.

[MystikShadows]

I'm just going to wait on something like this from admins and dev team. If a rewrite is imminent (read a must) and a syntax change (that one I get less) well I would like to know what the new syntax should be (or is already planned to be perhaps). But I'd like to know what the new direction would be (if there is a new direction). Nonetheless, nice attempt ptrichard, but I'll wait on the admins at this point.

If anonymous1337 is right, how about a small text describing this "rewrite" and the intended syntax changes so we know what to expect a bit :)...I for one would appreciate it. :)

[Lachie Dazdarian]

I want ASCII Cube.

[jevans4949]

... how about a small text describing this "rewrite" and the intended syntax changes so we know what to expect a bit :)...I for one would appreciate it. :)

This is also a valid point.

v1ctor's original aim, as I understood it, was to produce a version of QB which was 32-bit, and with the ability to interface better to its operational environment. One could reasonably say, therefore that the orignal FB specification was the QB syntax with necessary bells and whistles.

The changes since then have all been rather ad-hoc, and sprung on the community with each new release.

Most new languages start with a written specification. Unless it's intended to be proprietary, or is something developed for the originators' own use, this specification is usually subject to review by the prospective (end-user) developer community.

If "FB 2.0" is going to depart even farther from the QB model, then maybe some sort of RFC procedure should be the first step.

[duke4e]

I never really got the whole "C++ with QBasic sintax" thing. Isn't that just a parser which whould translate sintax from QB to C++?

[SSC]

I also agree with jevans, the current FB should be polished up before committing to a 2.0 version, and for that matter if the syntax and code is going to change drastically maybe a rename would be appropriate . . . FB++? heh

[fabrizio]

I can't begin to say how much I like all of this. Thanks anonymous1337.

I agree with renaming "Old FBC" to "FBC 1.0" and "New FBC" to "FBC 2.0".

I think no programmig on FBC 2.0 should begin until there is a complete definition of the language and taht means we need a format for that, before the format for the code.

The syntax can be worked upon based on the present documentation (outlining the changes, keeping what will not change, and removing comparisons with QB).

Now, I suppose the internals will be the same a C++?

[brybry]

I've been watching the discussions about the future of freeBASIC for a few days now, and I just want to share my thoughts.

I know I'm not well known around here. I rarely post anything, but I have contributed some patches to the compiler. (Most significantly, I am the one who added SSE/SSE2 support.) I've been using freeBASIC for a few years now.

My understanding is that issues about keeping QB compatibility are not because of personal preference, but because supporting the quirks of QB make the compiler more complicated, and therefore more difficult to work with. Having looked at/studied a large part of the compiler's source, I know this is true.

I would not care one bit if QB compatibility was completely gone, but I understand that some people want it. I believe it can co-exist without complicating the modernization of freeBASIC.

My suggestion is to have the devs and community come up with a good way to keep QB support, while still allowing FB to grow unhindered. And to make things easier, just remove "fblite".

Once a plan for that has been made, then start a re-write process using only freeBASIC. C/C++ is completely unnecessary. Member functions, constructors, etc. should help significantly.

I'm unsure about a syntax change. Maybe a clean-up, but not a change. I don't believe that will help much. Even then, it will most likely help a little bit at the parser level.

And BTW, let's not discuss what the new versions will be called. There are such bigger issues to be dealt with.

[TheMG]

If a rewrite is needed, we must keep it in FreeBASIC.