The Direction of FreeBasic development...

General discussion for topics related to the FreeBASIC project or its community.
Trenton_net
Posts: 44
Joined: Jun 16, 2008 1:42

The Direction of FreeBasic development...

Post by Trenton_net »

Hey Everyone,

Just some general forum chatter! :-) With the news of Cha0s taking a brake is there any word on FreeBasic development and/or the direction it will take?

Although I don’t know much about how the inner workings of the compiler, I’ve found FreeBasic, syntax, and functionality to be wonderful. I would hate to see things go on the way-side.

Hrm… And on another note, how do people feel about FreeBasic (in general) as a cross-platform language vs. Python vs. LUA vs. etc… ?

In my opinion, I prefer FreeBasic much greater over anything else I’ve played with so far and I hope the project stays around for a long time!

PS: General rant - I deeply hate how Python is Tab sensitive (We aren’t kids. We know indentation is good form) :-)
McLovin
Posts: 82
Joined: Oct 21, 2008 1:15
Contact:

Post by McLovin »

FreeBASIC is alive and strong. It is a great compiler that has features that other BASIC compilers can only wish that they had.

Developers will come to FB. It is the circle of life.

----
Fogell
Eponasoft
Posts: 264
Joined: Jul 26, 2007 2:40

Post by Eponasoft »

Don't forget that some assemblers are also tab-sensitive. But Python is a joke. Yeah, go ahead and quote me. :)
Trenton_net
Posts: 44
Joined: Jun 16, 2008 1:42

Post by Trenton_net »

Well people, I sure hope so...

Before FreeBasic (and after I tried other languages, like Pyton), I always wondered why nothing could be made as simple yet useful as it was back in the QB45, C, Pascal days. I remember as a kid I used QB45 an awful lot and wrote wonderful console-mode applications like MS-Edit clones and the like. I always wondered why it had to be such a pain to do something similar on modern languages like Python (You need a crap load of extra libraries just to do things like text color and locate!?!).

From using QB45 and QB7 a lot as a kid, I found lots of things I liked and things I wish MS improved or made better in the future. And amazingly, I think FreeBasic addressed almost all of those features stock!

In my option, FreeBasic is pretty much *the standard* for modernized open sourced basic bar-non. I can't think of any other derivative that has gotten so many things RIGHT like FreeBasic has.

Speaking of derivatives, am I right to assume FreeBasic is the most popular modernized Basic distribution out there? If not, what other distributions exist that are more popular or within the same realm?
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: The Direction of FreeBasic development...

Post by marcov »

Trenton_net wrote: Just some general forum chatter! :-) With the news of Cha0s taking a brake is there any word on FreeBasic development and/or the direction it will take?
As other discussions have concluded, information is a bit thin. Probably it will continue as it has till now, with stuff being announced when it is ready.
Hrm… And on another note, how do people feel about FreeBasic (in general) as a cross-platform language vs. Python vs. LUA vs. etc… ?
For any comparison, you first have to define what you want to do with them. If you do in game scripting, LUA will win. If you need to run binaries without installing anything, FB will win. (I can't imagine a scenario where I would use Python, but imagine one here).

Keep in mind that the most isolated systems are the most portable, but also the hardest to do realworld stuff with.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Post by marcov »

Trenton_net wrote:I remember as a kid I used QB45 an awful lot and wrote wonderful console-mode applications like MS-Edit clones and the like. I always wondered why it had to be such a pain to do something similar on modern languages like Python (You need a crap load of extra libraries just to do things like text color and locate!?!).
All those were not portable. As soon as you become portable, you need to have libraries to shield the differences in locate behaviour etc.

And specially Unix terminals are more a family of console types than a single one. IOW it is not the language, but the demand for crossplatform portability
Speaking of derivatives, am I right to assume FreeBasic is the most popular modernized Basic distribution out there? If not, what other distributions exist that are more popular or within the same realm?
Basic is a language kept alive by Microsoft. Most dialects are MS centric, and not portable.
McLovin
Posts: 82
Joined: Oct 21, 2008 1:15
Contact:

Post by McLovin »

I have been working on a parser front-end for FreeBASIC written in BNF and using GOLD as the parser generator. It has been a fun experience so far. I have the engine written that reads the GOLD generated tables. I have a GOLD template that receives the GOLD tables directly so that they can be compiled directly into the engine rather than being read separately from disk (similar to Kessel's engine written in C). It has been really fun trying to design the GOLD syntax modelled after the FB language - BNF is is somethign that I have never done before. FB has many ways to do different things. For example, the simple DIM'ing of variables:

Code: Select all

! -------------------------------------------------------------------
! Variable Declaration
! -------------------------------------------------------------------

<IntLiteral>           ::= IntLiteral
                         | HexLiteral
                         | OctLiteral

<VarDimSharedOpt>      ::= 'Shared' 
                         |                     ! allow it to be optional

<VarDim>               ::= 'Dim'
                         | 'Static'

<ArrayBoundTo>         ::= 'To' <IntLiteral>        
                         |                     ! allow to be optional

<ArrayBounds>          ::= <IntLiteral> <ArrayBoundTo>  

<ArrayBoundsOpt>       ::= ',' <ArrayBounds> <ArrayBoundsOpt>    ! so we can handle multiple array dimenensions
                         |                                       ! allow to be optional

<VarNameListOpt>       ::= ',' <VarName> <VarInit> <VarNameListOpt>
                         |                                       ! allow to be optional

<VarNameDeclListOpt>   ::= ',' <VarName> As <DataType> <VarInit> <VarNameDeclListOpt>
                         |                                       ! allow to be optional

<VarName>              ::= ID '(' <ArrayBounds> <ArrayBoundsOpt> ')'    ! handle arrays
                         | ID

<DataFixedString>      ::= ID '*' <IntLiteral>

<DataTypePointer>      ::= ID 'Pointer'
                         | ID 'Ptr'

<DataType>             ::= ID 
                         | <DataFixedString>
                         | <DataTypePointer>

! TODO: Need to modify in order to handle initializing UDT's with embedded arrays and arrays of UDT's with embedded arrays
! { (100,{1,2,3,4,5}) }

<VarInitValueOpt>      ::= ',' <Value> <VarInitValueOpt>
                         |                 ! allow to be optional

<VarInitValue>         ::= <Value>
                         | '{' <Value> <VarInitValueOpt> '}'
   
<VarInit>              ::= '=' <VarInitValue>
                         | '=>' <VarInitValue>
                         |                  ! allow to be optional
 
<VarDecl>              ::= <VarDim> <VarDimSharedOpt> <VarName> <VarNameListOpt> 'As' <DataType> <VarInit> <NL>       ! Dim a, b, c As Integer
                         | <VarDim> <VarDimSharedOpt> 'As' <DataType> <VarName> <VarInit> <VarNameListOpt> <NL>       ! Dim As Integer a, b, c
                         | <VarDim> <VarDimSharedOpt> <VarName> 'As' <DataType> <VarInit> <VarNameDeclListOpt> <NL>   ! Dim a As Integer, b As String, c As Byte
I have many aspects of the language modelled using the VBScript and VB.Net grammars as guides (DIM, Subs/Functions, Parameters, Namespaces, Declares, Enumerations, Types, With, Expressions, Loop, For, If/Then, etc...). It has been a really fun experience so far. Nothing may ever result from it but you never know. If nothing else I am learning a lot about parser generators.

I believe that using the grammar approach to the front end and then using the resulting parse trees to generate the gcc GENERIC trees could significantly reduce development time and allow easier understanding of the FB compiler for new developers.

----
Fogell
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Post by marcov »

McLovin wrote: I have many aspects of the language modelled using the VBScript and VB.Net grammars as guides (DIM, Subs/Functions, Parameters, Namespaces, Declares, Enumerations, Types, With, Expressions, Loop, For, If/Then, etc...). It has been a really fun experience so far. Nothing may ever result from it but you never know. If nothing else I am learning a lot about parser generators.
Note that even if not useful for the compiler, it can still be useful for auxilary utils where the full parser is too painful. Like doc tools, pretty printers, cross references.
I believe that using the grammar approach to the front end and then using the resulting parse trees to generate the gcc GENERIC trees could significantly reduce development time and allow easier understanding of the FB compiler for new developers.
Read: http://groups.google.com/group/comp.com ... ae91069efd#

Note the comments of Barry Kelly, and several other commercial compiler developers.

Parser generators are great initially, but get a burden when your compiler progresses, and you have legacy and correct errorgeneration to do.
fabrizio
Posts: 73
Joined: Sep 29, 2006 13:39
Location: Roma, Italy

Post by fabrizio »

I thought I was the only one here comparing FB with Python. Both are great high level languages.

Python is readable. IMHO Python readability comes from two things: indentation and implicit variable declaration, particularly in function parameters.

I like indentation. If you take out curly braces from C, parens from LISP, BEGIN..END from Pascal, and retain indentation to signal blocks, what you get is a clearer language in all cases (and of course something similar to Python).

Basic is similar to Pascal but doesn't have BEGINs. As showm by McLovin better than I could do, this is because formally Basic isn't very good. It was born as a series of separate commands, each with its own syntax.

(@ McLovin: I noticed in LISAAC the concept of "separators", ie. pieces of text which separate variables in function parameters, which are customisable, not just "," as usual; could this could be used to maintain the expressiveness of Basic and also simplify the overall structure?)

From Python I also like lists, tuples and the syntax of classes. To teach programming to a kid, I would choose Python.

FB has great built in graphics, very powerful string instructions, powerful arrays ... and it is compiled, that is, really fast.

In the end I choose Basic because of speed and easy graphics. If a compiled subset of Python with easy graphics existed ... then I don't know.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Post by marcov »

fabrizio wrote:I thought I was the only one here comparing FB with Python. Both are great high level languages.
I would intuitively not, since FB is not an interpreted language. (or with a really heavy VM, like QB64)
Python is readable. IMHO Python readability comes from two things: indentation and implicit variable declaration, particularly in function parameters.
Strange, implicit variable declaration is one of the things I consider unreadable.
I like indentation. If you take out curly braces from C, parens from LISP, BEGIN..END from Pascal, and retain indentation to signal blocks, what you get is a clearer language in all cases (and of course something similar to Python).
Well, traditionally whitespace has always been expendable. This means that you have to take care with any editor to avoid problems with python code. (e..g it might compress repeated spaces to tabs).

Also half way through editing, you might have lost your block structure, because you didn't reindent parts yet.

The idea was fun, but IMHO it is practically more trouble than it solves.
Basic is similar to Pascal but doesn't have BEGINs. As showm by McLovin better than I could do, this is because formally Basic isn't very good. It was born as a series of separate commands, each with its own syntax.
Yes. But that is the problem with many really old languages (Cobol also comes to mind). Basic is *old*.
From Python I also like lists, tuples and the syntax of classes. To teach programming to a kid, I would choose Python.
Depends what the kid is going to do. If he is really going in the direction of IT, I would have him do something more formal. If he is going to do only office automation, why not?
In the end I choose Basic because of speed and easy graphics. If a compiled subset of Python with easy graphics existed ... then I don't know.
I ended up with Pascal actually because QBasic's graphics were too slow. After the chaos of C=64 and QBasic, Pascal was pretty much an oasis of rest.

When I later reevaluated, I liked the fact how Pascal's syntax (and Modula2's even more) seems to reduce the number of mistakes somewhat, and also got addicted to sets and optional runtime checking.
And recent Pascal/Delphi's also have top class stringroutines.
McLovin
Posts: 82
Joined: Oct 21, 2008 1:15
Contact:

Post by McLovin »

marcov wrote: Note that even if not useful for the compiler, it can still be useful for auxilary utils where the full parser is too painful. Like doc tools, pretty printers, cross references.
Ah, good point! Right now all of this is just an academic exerice for me to stretch my brain when it comes to syntax directed parsing. If it results in a simplified compiler then great, however if it realistically ends up being able to create doc tools, pretty printers, cross references, etc... then the whole exercise was not a wasted effort and may be of benefit to others in the community.
Note the comments of Barry Kelly, and several other commercial compiler developers.

Parser generators are great initially, but get a burden when your compiler progresses, and you have legacy and correct errorgeneration to do.
Yes, I guess so. The 'problem' I see is that there needs to be a clear (and clean) definition of the language. It is when the language tries to be everything to everyone that the problems creep in. For example, as I write the BNF I am only concentrating on new FB constructs rather than trying to shoe horn 20 year old QB syntax and all of its quirks. The way I see it, FB already exists with enough QB support - anything I create will not try to reinvent that.

I hope that when I'm done that at least there will be some type of roadmap that others can use to take the code and even build compilers, interpreters or script languages for themselves using FB. That would be kind of cool.

----
Fogell
rolliebollocks
Posts: 2655
Joined: Aug 28, 2008 10:54
Location: new york

Post by rolliebollocks »

fabrizio wrote:
From Python I also like lists, tuples and the syntax of classes. To teach programming to a kid, I would choose Python.

FB has great built in graphics, very powerful string instructions, powerful arrays ... and it is compiled, that is, really fast.

In the end I choose Basic because of speed and easy graphics. If a compiled subset of Python with easy graphics existed ... then I don't know.
Firstly, I think you should teach kids free basic over the standard python just based on FB's library versatility. As far as graphics engines go, pygame is a free engine which can handle FBGFX-like sprites and circles, and alpha blending, transparency etc... and it will do it slightly faster than FB will. Who cares? It's called pygame, it's free, its fast, its python... Who cares?

FreeBASIC comes with FBGFX stock, along with OpenGL, Allegro, and Cairo, SDL, TinyPTC etc... all included with examples. You *cannot* beat FB as a general all purposes tutelary language. This is BASIC - it was *made* to teach.

Once the kids know basic, you can skip over python and teach them Java/C++.

Learning Python first would *i'll grant this* make that transition slightly easier. At any rate, I get rather defensive about FreeBASIC. Please excuse me.

rb
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Post by marcov »

McLovin wrote: For example, as I write the BNF I am only concentrating on new FB constructs rather than trying to shoe horn 20 year old QB syntax and all of its quirks.
It is not just evil syntax. When you are busy for a few years, compatibility with older versions of self also get a problem. People have large codebases, and you can't break them totally every half year because it is easier to solve in Yacc.
I hope that when I'm done that at least there will be some type of roadmap that others can use to take the code and even build compilers, interpreters or script languages for themselves using FB. That would be kind of cool.
A real pure model (BNF based I mean) can also be a means to identify/generate test cases. OTOH that is very difficult and probably means you need to have vast experience with the main compiler first.
McLovin
Posts: 82
Joined: Oct 21, 2008 1:15
Contact:

Post by McLovin »

Hi Marcov,

Just curious as to why you believe that maintaining a BNF grammar file would be more difficult then maintaining the actual rules in the code base itself. I see your point about maintaining backwards compatibility as new versions are released, but I also see that as being easy to maintain via BNF.

New BNF's can be added and existing ones easily extended without breaking existing rules and backwards compatibility. I think it would be easier to follow the changes via a BNF grammar file than trying to wade through mountains of parser source code for the changes and quirk handling. Once modified the tables are regenerated and automatically added to a template file that beomes part of the compiler. All that needs to be worked on from there is the code emitting. GOLD is a powerful LALR(1) parser and handles all of the messy shift/reductions, etc... All I need to do is add the 'engine.o' object file that I wrote to handle the source file/GOLD interaction (which also handles unicode files).

The way I see it, a lot of development effort could be simplified by having a source code flow like the following:
(1) Configuration and set up compiling options (via command line or config file)
(2) Load source files and run them through a Preprocessor to handle the "#" instructions.
(3) Parse the source and create the trees.
(4) Walk the trees and emit to assembly, C, C++, GENERIC, etc...
(5) Feed the output to the GNU tools.

I'm not trying to be difficut here - just trying to understand all angles of this. Maybe I'm missing something big. Maybe there's stuff that simply can not be modelled via BNF? I read the Barry Kelly comments in your google link - thanks. Maybe I am just being naive but I believe that a properly formalized grammar should not allow things like keywords being treated as identifiers. The BASIC language should be more easily modelled than the langauages that he works on.

I have reviewed the compiler source code. I can follow it (been a programmer for over 20 years) but this is the first time that I have ever done any compiler work and it is pretty refreshing and exciting.

Thanks for your help. :-)

----
Fogell
fabrizio
Posts: 73
Joined: Sep 29, 2006 13:39
Location: Roma, Italy

Post by fabrizio »

rolliebollocks wrote: I think you should teach kids free basic over the standard python just based on FB's library versatility.
Yes, FB has a lot of libraries available. For me, I always use FBGFX. It is there, it is easy, it is fast and it is fun. I think a kid would reason the same way.

Pygame: I couldn't figure out how to locate 10,15 : print "ciao" just as easily -- I think it needs images of the letters and furthermore it doesn't automatically scroll... TkInter IMO is even worse. Turtle is much better but it's limited. Xturtle is the best so far, but not quite it. (Always IMO)
You *cannot* beat FB as a general all purposes tutelary language. This is BASIC - it was *made* to teach. Once the kids know basic, you can skip over python and teach them Java/C++.
Here I don't agree. It was made to be taught ... 40+ years ago. Basic is not good for teaching now. It is not consistent. It is a stack of procedures, each with its own syntax. It is nothing like the elegance of Pascal, C, Ruby, Python, LISP. (FB is evolving out of there, but backwards compatibility forces it to carry the old burden.)

If you teach Basic as a first programming language to a kid , it will not harm, it's just that the kid will not be offered much of the beauty (ie. formal elegance) in programming languages.
Post Reply