I think there should be an interpreter and compiler for BASIC in a fashion similar to VB6 and VB.NET (in that it uses objects, and those objects have properties/functions), and could use external objects (through Corba, KDEParts, JavaBeans??, gmodule loading, xml-rpc, etc..). Sadly, I simply don't have the time to make something like it (and on my attempts to do so, under OpenBasic, it's a mess of code, and that's just the object manager!).
Perhaps we, as a community that obviously likes Basic (some of us, at least), could get together and merge some of these smaller projects into an Object Oriented basic interpreter/compiler. I have some code that I can clean up to do the object interface - we'd only have to get some event handling code, some threading code (for the GUI toolkits like GTK and QT that have their own thread for events), and something to load the code into memory (from source, P-Code, etc..), and then something to run through the code and interpret it...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are a lot of attempts to write Basic compiler/interpreter and many of them try to be object oriented. Sadly that leads to mess as men working on their own project tend to invent their own style and standard for basic and it's object oriented extensions.
I am working myself on the object-oriented basic (lemick basic - http://lemick.narod.ru\) and has my own approach. However I would like to keep my lemick as compatible with other basic compilers and interpreters as it's possible.
I suppose, Basic developers community should make an effort to develop an up-to-date and complete standard that will include all the best features of existing basic implementations.
If there will be one united basic standard all the existing basic projects will beinifit from it as it will attract more people to using it.
Here are the sections that I think should be included into the standard:
0) OOP support
1) code import
2) GUI
3) graphics
4) network
5) various i/o functions
6) CGI programming support
Who if not those who have spent a lot of time developing Basic comp./inter. can cook such a standard?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is no need for a universal BASIC compiler framework because there already _is_ a universal compiler framework. It's called GCC :)
Unfortunately, BASIC languages do not fair well with lex/yacc style LALR(1) parsing so it's a bit difficult using it like C/C++ do (I know the GnomeBasic guys had to write their own lexer), but I have just started experimenting with ANTLR which is an LL(k) based lexer/parser and it seems to handle the BASIC dialect with incredible ease.
I'm still trying to get a full grammar together and have it generate C code but the next step is translate the ANTLR AST tree into a GCC RTL tree and then pass it off to GCC. That should actually be easier than it sounds too :)
So, as far as dialects are concerned, the best way to have a way to implement multiple BASIC languages would surely be to just have an ANTLR/GCC framework where only the grammar needed to be modified.
I saw some things in your post too that really don't have anything to do with a BASIC language (i.e. CGI support/network/GUI). They are all user level functionality that can be added after the language.
One cool thing I always wanted to be able to do with GLBCC is to have statements be user definable. That is proving rather difficult to parser correctly though so it's on hold right now.
OOD is scary and IMHO, does not belong in BASIC. If trying to implement OOD though in BASIC, I suggest outputing to C++ and let a C++ handle all the vtables and stuff because otherwise, it's not exactly a trivial task... (similiar to what B++ does).
You say:There is no need for a universal BASIC compiler framework:
I wish you success with you attempts but there is still a GREAT NEED in basic unification/standartization.
You say:Unfortunately, BASIC languages do not fair well with lex/yacc style LALR(1) parsing so it's a bit difficult using it like C/C++ do
I don't understand what problems you mention. I wrote yacc grammar for basic with lex scaner and don't think there's any special in it. look at lemick.narod.ru for example.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Doh! I never had heard of Lemick Basic (although Liberty Basic has been around ~92). GLBCC has a tool call LBPP as Lemick Basic does too :) Small namespace collision apparently...
I know it's possible to use lex/yacc to create a BASIC grammar but it's not terribly easy because BASIC tokens tend to be very dependent on their context. The token 'END' turns out to mean lots of different things depending on the context of the token and using a large lexical rule such as 'END[ \t]+SUB' makes for very large parser tables. Which means slow parsers.
LL(k) is definitely incredibly useful for BASIC simply because one can use LL(2) to find the SUB token and keep the parser tables small.
GLBCC also has a lex/yacc grammar available in the GLBCC CVS.
As far as a single BASIC standard, I think there are two schools of thought on BASIC languages out there. Those that are more consumer oriented that desire to replace VB and those that are more BASIC purest who wish to implement a solid BASIC language.
I think there's a general need for both schools of thought though, so I think before any standardization process can be discussed, it needs to be clearly stated whether this is going to be a pure BASIC language, or VB for Linux.
After that, I suggest maybe starting a new SF project and using a mailing list because this forum is a bit annoying since lazy guy's like me have log in and stuff ;-)
Regards,
Anthony Liguori
GLBCC - (GNU/Liberty Basic Compiler Collection) http://lbpp.sf.net
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> context. The token 'END' turns out to mean
> lots of different things depending on the
> context of the token and using a large lexical
> rule such as 'END[ \t]+SUB' makes for very
> large parser tables. Which means slow
> parsers.
I don't see that. END[ \t]+SUB is 1 token (for yacc). How does that make a large parser-table? It does add to the lexical analyzer table, but not significantly more than a keyword.
CU, Eddie.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Basic has a keyword END (to exit a program) but also has various END statements to end subs and so forth. If you use END as a lexical token and SUB as a lexical token, then in yacc you can expect END SUB. Or, you can define END[ \t]+SUB in lex and then have an END_SUB keywork or something.
Problem is that states checked for _every_ keyword whereas in yacc there is more logic.
I don't know, maybe I'm just a bit old school considering how fast computers are, but I always was of the opinion that lex should have very short simple tokens and the rest should be in yacc.
Anyway, it all really doesn't matter because there's a better argument against using lex/yacc for a BASIC language.
a.print = 1
is valid in most BASIC languages. Try writing a rule to parse that correctly when PRINT is a token. Isn't very fun. ANTLR is much better at handling stuff like that. This is why, I believe, GnomeBasic choose to write their own lexer. lex just isn't meant to parse something like that...
Regards,
Anthony Liguori
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> END SUB. Or, you can define END[ \t]+SUB
> in lex and then have an END_SUB keywork
> or something.
Yes, that's (END_SUB keyword) how I do it. Note that lex always returns the longest matching sequence so 'END SUB' is always matched as END_SUB and never as an END and a SUB token.
> I don't know, maybe I'm just a bit old school
> considering how fast computers are, but I
> always was of the opinion that lex should
> have very short simple tokens and the rest
> should be in yacc.
I have exactly the opposite opinion (but I don't know if it's better, faster, ...): do all lexical analysis (i.e. splitting a character stream in tokens) in lex and do only parsing in yacc...
> Anyway, it all really doesn't matter because
> there's a better argument against using lex
>/yacc for a BASIC language.
> a.print = 1
> is valid in most BASIC languages. Try
> writing a rule to parse that correctly when
> PRINT is a token. Isn't very fun. ANTLR is
It depends on what you mean by a.print. QuickBASIC allowed the . both as part of the identifier and as a way to select fields from a struct ('user defined type') and is (therefore) ambiguous. The way to solve it is to make 'a.print' as a whole a (symbol) token and do some symbol-table magic in the parser.
If you don't allow . as part of the identifier (only as field selection): it's defininetely a bad idea to allow reserved words as fields.
OTOH antlr is a good tool too. If you're comfortable using it: please don't let me convince you otherwise ;-)
CU, Eddie.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure, I agree with You guys but please keep in mind that (that's my opinion) we should all gather and make GNU BASIC that follows standards, compiles and runs on all platforms that has GNU tools ported on themselves etc...
My opinion that we can all take THE BEST from our projects (which are small or big, no matter) according to some TODO list made by ourselves and than put everything there.
Also my opinion that that new BASIC should be a part of GNU Compile Collection! :)
If there is interest in such thing I would like to hear from You, and later we can make "gnu-basic" SourceForge project and start working on it.
Please respond! :) The main goal of this foundry IS to gather all developers willing to contribute on ONE BASIC that works/serves well.
Are you talking about 1 standard GNU BASIC language (dialect) or about a GNU BASIC compiler framework, supporting multiple BASIC dialects? If you're talking about the former: greater powers than you and me have tried and failed ;-) (e.g. ANSI BASIC, QuickBASIC (if you don't want to call that a standard, at least it was a de facto standard for a while), ...).
For the next version of XBasic I am using the latter approach. It will consist of a frontend (scanner/parser) written using Lex/Yacc that generates an abstract syntax tree and a backend that converts that abstract syntax tree into code. At first C, later maybe assembly but probably RTL (the intermediate language used by the GCC). The abstract syntax tree is not XBasic specific but can be generalized to support more BASIC dialect. Using this approach implementing another BASIC dialect means implementing a scanner/parser for it. That still won't be trivial but at least it won't be as large a task as writing a full compiler.
An Object Oriented XBasic compiler is only planned for later, but it will be able to use the same framework (only the AST and probably the symbol table need to be extended to support object oriented constructs).
Unfortunately not much code is already available, due to (as always) lack of time.
I am interested in cooperating with other compiler-writers for this framework, or maybe even use an existing framework (I know currently of none).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We talk about BASIC but we actually we talk about the keywords and the style of the standard commands (like the IF-THEN-ELSE, FOR-TO-NEXT etc).
It cannot be a standard for all BASICs. btw the BASIC itself has no standard.
Take a look of GWBASIC, QBASIC, VB; all those are created by the same company but had too much differences.
There are differences inside the base of every implementetion (example: there are BASICs with and without data-types (variants); of course there are and mules (call me VB) which supports both).
There are easy implementations (like my SB), there are complex implementations too (with OOP, dynamic-lists etc).
If we want a standard, that standard cannot be one for all but 3-4 different.
like:
a) old-style (with numbers)
b) simple structured style (without numbers, with procs/funcs).
c) strict structured style (like b, but with data-types).
d) like (c) but with objects
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Every basic implementation has something common with others (that's why they are called Basic :-) ), but all the time they tend to have differences with the existing versions and a lot of them arn't forced by the base if the implentation. It is a serious problem for those who prefer to programme in Basic.
BTW:VB is a weak-typed language. when variable isn't defined explicitly it has type "Variant" that can be dynamically casted to any-other built-in type.
Who on the earth now will need basic with numbered lines? Who will programme in it?!
The same about b). c) and d) - only these can be talked about as a "programming language". We are in 21 century folks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Every basic implementation has something common with others (that's why they are called Basic :-) ), but all the time they tend to have differences with the existing versions and a lot of them arn't forced by the base if the implentation. It is a serious problem for those who prefer to programme in Basic.
I agree.
> Who on the earth now will need basic with numbered lines? Who will programme in it?!
I agree, but it is part of BASIC's world.
> The same about b). c) and d) - only these can be talked about as a "programming language". We are in 21 century folks.
I totaly disagree. SB is working on (b) and it will stay on it. That exactly is what I was tried to do. A simple language for simple things (don't cared about speed, memory, low-level). Just simple as was our old home computers. If I want something more then I'll use a more powerfull tool like C++ or C or Java or something else (it is depended on what I want to do).
BASIC was created for beginners, and that is the advantage.
=== Is simple that (random selection from MSDN):
' The property value can only be set once.
Public Property Set Parent(ByVal NewParent _
As Department)
If deptParent Is Nothing Then
' Assign the initial value.
Set mdeptParent = NewParent
Else
Err.Raise Number:=vbObjectError + 32144, _
Description:="Parent property is read-only"
End If
End Property
=== Or that:
FUNC F(x)
IF x THEN
f = 1/x
ELSE
PRINT "F(x): div. by zero"
STOP
ENDIF
END
Sorry, but I want only the second style
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I totaly disagree. SB is working on (b) and it will stay on it. That exactly is what I was tried to do. A simple language for simple things (don't cared about speed, memory, low-level). Just simple as was our old home computers.
Well, have you ever thought about anyone else then you using you basic? or it's just for personal use? If you want it to be useful you will have to add a lot of functions behind those you'll find in gw-basic or qbasic.
>If I want something more then I'll use a more powerfull tool like C++ or C or Java or something else (it is depended on what I want to do).
Why not a more powerful Basic instead?
>BASIC was created for beginners, and that is the advantage.
Do you think all Basic programmers are dummies? No, I hope.
Basic is a simple language, that's it's advantage. But that doesn't obligate it to be primitive.
I think I was wrong about b) class. It also offers a good subset of Basic language.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it is great that there many basic projects and I hope there always will be. There hardly could be some one "big" basic compiler/interpreter that will satisfy all the users/developers. BUT, why not standardize Basic language itself? If someone writes Basic-like language for game development he will need a lot of graphics functions and a almost none, for example, for databse connections. But he should keep the syntax in accordance to some standard, even if he will require to add new function he should do it in some standartized way. If someone writes language for operations with db he will have to follow all the standards for db functions and may omit all the rest and son on.
That will help users a lot, as they won't have to relearn the language. It is even better when there are many basic implentations as every has it's own string sides. Just imagine what a powerful tool will be a dozen of basic compilers/interpreters if they would share the same standard?
I don't think it is possible to achieve full compatibility, when one will be able to use this or other compiler/interp. for the same source code. But it is possible to code the same things in some unified way in all basic flavours.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know if it's a good idea to create a 'one size fits all', 'universal' BASIC, because changes are it will become just 'yet another BASIC dialect'.
The beauty of a good component model (and I don't mean just UI components) is that it's not important in which language a component is written to be able to use it. You only need the component itself (probably as a compiled binary, maybe even as a 'web service'), it's interface and some documentation on how to use it.
I.e. a component model can be integrated into any existing BASIC compiler / interpreter. Obviously an Object Oriented component model fits better in a Object Oriented language, but it's not impossible to use it in a non object oriented language.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
KBasic1 - 1st Generation, old standard BASIC, qbasic like (1.1 - 1.9) <--- we are here
KBasic2 - 2nd Generation, GUI BASIC, vb like (2.1 - 2.9)
KBasic3 - 3rd Generation, OO-BASIC, vb.net like (3.1 - 3.9)
As you can see there is a long way to go, but v1.0 will be released in February 2002. We reached many milestones yet. It contains a clean structure in scanner, parser and interpreter. The tokens are defined in a list, the parser is handwritten 100% syntax compatible with qbasic and the interpreter is a pcode stack machine and all in C++. A (66% finished andcopyright free ) command help already exist. And many other parts...
~Bernd~
bernd@kbasic.org
www.kbasic.org
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunatelly my opinion is that BASIC (or any other compiler/interpreter) language should be aware of GUI ToolKit...
KBasic is strictly KDE stuff, the same is with (wanderfull) GnomeBASIC which is GREAT project! BUT, what if I don't want to make KDE or GNOME application? Per example, i like FLTK more than GTK or KDE! :)
KBasic is cool project but it's goal is to be specifis in some way...
XBASIC, YaBASIC, ScriptBASIC, Lemmick BASIC are projects that are more opened than KBasic when we consider that, that's my opinion.
Best regards! :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, we don't need a 'Univesal' product, but we do need one or two 'Leader' product, with modern and high-class features and cross-platform, widely supported and used, just like VB in the commercial software world, so BASIC can be a real living language.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The more I read these posts the more I'm wondering if a simple C++ namespace framework that could be used by multiple Basic parsers would be a better solution than trying to build compatible Basics.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would be important to have a universal BASIC, but it is equally important to have different 'flavors' as well. There might be a way that both of these may be possible.
A new standard could be created stating the rules of BASIC. These rules would inlcude all of the statements in BASIC. These would then be programed into a 'core module'. This project would be in an open forum so that people could make suggestions to the updating and improvement of the module.
Programers and developers could then take this core module and use it when writing their own BASIC interpreters/compilers. However, they could still be able to define their sintax to their personal preference. They would create a 'front end' the the standard core BASIC module that would translate, if necessary, their own functions, into the standard BASIC form.
Thier could also be another version that would just use the standard core module without any modifictions. This would then be the 'official/standard' language for BASIC.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds just like my own idea!
First of all we all should define set of "standard" statements and functions and their syntax as well.
Implementation of "core" basic is something mmm... mystical becouse there are basics which compile to object code and others to bytecode and some are plain interpreters. But i see no problems in implementing a pair of good .so libs that will implement BASIC's functions and some other things like support for symbol table operations, hashes and etc.
I will be happy to take part in this new project. does it has sourceforge location/url?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would to be a part of such a project, but I think that it would be crucial to get as many viewpoints as possible. This way, the standard for this new BASIC language would be the oppinions of many instead of a few. If there is enough interest in this, a project site could be started on Sourceforge. Let me know what u think.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> language would be the oppinions of many
> instead of a few. If there is enough interest
> in this, a project site could be started on
> Sourceforge. Let me know what u think.
I hate to sound like a newbie, but: Me too ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think there should be an interpreter and compiler for BASIC in a fashion similar to VB6 and VB.NET (in that it uses objects, and those objects have properties/functions), and could use external objects (through Corba, KDEParts, JavaBeans??, gmodule loading, xml-rpc, etc..). Sadly, I simply don't have the time to make something like it (and on my attempts to do so, under OpenBasic, it's a mess of code, and that's just the object manager!).
Perhaps we, as a community that obviously likes Basic (some of us, at least), could get together and merge some of these smaller projects into an Object Oriented basic interpreter/compiler. I have some code that I can clean up to do the object interface - we'd only have to get some event handling code, some threading code (for the GUI toolkits like GTK and QT that have their own thread for events), and something to load the code into memory (from source, P-Code, etc..), and then something to run through the code and interpret it...
There are a lot of attempts to write Basic compiler/interpreter and many of them try to be object oriented. Sadly that leads to mess as men working on their own project tend to invent their own style and standard for basic and it's object oriented extensions.
I am working myself on the object-oriented basic (lemick basic - http://lemick.narod.ru\) and has my own approach. However I would like to keep my lemick as compatible with other basic compilers and interpreters as it's possible.
I suppose, Basic developers community should make an effort to develop an up-to-date and complete standard that will include all the best features of existing basic implementations.
If there will be one united basic standard all the existing basic projects will beinifit from it as it will attract more people to using it.
Here are the sections that I think should be included into the standard:
0) OOP support
1) code import
2) GUI
3) graphics
4) network
5) various i/o functions
6) CGI programming support
Who if not those who have spent a lot of time developing Basic comp./inter. can cook such a standard?
There is no need for a universal BASIC compiler framework because there already _is_ a universal compiler framework. It's called GCC :)
Unfortunately, BASIC languages do not fair well with lex/yacc style LALR(1) parsing so it's a bit difficult using it like C/C++ do (I know the GnomeBasic guys had to write their own lexer), but I have just started experimenting with ANTLR which is an LL(k) based lexer/parser and it seems to handle the BASIC dialect with incredible ease.
I'm still trying to get a full grammar together and have it generate C code but the next step is translate the ANTLR AST tree into a GCC RTL tree and then pass it off to GCC. That should actually be easier than it sounds too :)
So, as far as dialects are concerned, the best way to have a way to implement multiple BASIC languages would surely be to just have an ANTLR/GCC framework where only the grammar needed to be modified.
I saw some things in your post too that really don't have anything to do with a BASIC language (i.e. CGI support/network/GUI). They are all user level functionality that can be added after the language.
One cool thing I always wanted to be able to do with GLBCC is to have statements be user definable. That is proving rather difficult to parser correctly though so it's on hold right now.
OOD is scary and IMHO, does not belong in BASIC. If trying to implement OOD though in BASIC, I suggest outputing to C++ and let a C++ handle all the vtables and stuff because otherwise, it's not exactly a trivial task... (similiar to what B++ does).
Regards,
Anthony Liguori
Author - GLBCC (GNU/Liberty Basic Compiler Collection)
http://lbpp.sf.net
You say:There is no need for a universal BASIC compiler framework:
I wish you success with you attempts but there is still a GREAT NEED in basic unification/standartization.
You say:Unfortunately, BASIC languages do not fair well with lex/yacc style LALR(1) parsing so it's a bit difficult using it like C/C++ do
I don't understand what problems you mention. I wrote yacc grammar for basic with lex scaner and don't think there's any special in it. look at lemick.narod.ru for example.
Doh! I never had heard of Lemick Basic (although Liberty Basic has been around ~92). GLBCC has a tool call LBPP as Lemick Basic does too :) Small namespace collision apparently...
I know it's possible to use lex/yacc to create a BASIC grammar but it's not terribly easy because BASIC tokens tend to be very dependent on their context. The token 'END' turns out to mean lots of different things depending on the context of the token and using a large lexical rule such as 'END[ \t]+SUB' makes for very large parser tables. Which means slow parsers.
LL(k) is definitely incredibly useful for BASIC simply because one can use LL(2) to find the SUB token and keep the parser tables small.
GLBCC also has a lex/yacc grammar available in the GLBCC CVS.
As far as a single BASIC standard, I think there are two schools of thought on BASIC languages out there. Those that are more consumer oriented that desire to replace VB and those that are more BASIC purest who wish to implement a solid BASIC language.
I think there's a general need for both schools of thought though, so I think before any standardization process can be discussed, it needs to be clearly stated whether this is going to be a pure BASIC language, or VB for Linux.
After that, I suggest maybe starting a new SF project and using a mailing list because this forum is a bit annoying since lazy guy's like me have log in and stuff ;-)
Regards,
Anthony Liguori
GLBCC - (GNU/Liberty Basic Compiler Collection)
http://lbpp.sf.net
> context. The token 'END' turns out to mean
> lots of different things depending on the
> context of the token and using a large lexical
> rule such as 'END[ \t]+SUB' makes for very
> large parser tables. Which means slow
> parsers.
I don't see that. END[ \t]+SUB is 1 token (for yacc). How does that make a large parser-table? It does add to the lexical analyzer table, but not significantly more than a keyword.
CU, Eddie.
'END[ \t]+SUB'
Here's the problem:
Basic has a keyword END (to exit a program) but also has various END statements to end subs and so forth. If you use END as a lexical token and SUB as a lexical token, then in yacc you can expect END SUB. Or, you can define END[ \t]+SUB in lex and then have an END_SUB keywork or something.
Problem is that states checked for _every_ keyword whereas in yacc there is more logic.
I don't know, maybe I'm just a bit old school considering how fast computers are, but I always was of the opinion that lex should have very short simple tokens and the rest should be in yacc.
Anyway, it all really doesn't matter because there's a better argument against using lex/yacc for a BASIC language.
a.print = 1
is valid in most BASIC languages. Try writing a rule to parse that correctly when PRINT is a token. Isn't very fun. ANTLR is much better at handling stuff like that. This is why, I believe, GnomeBasic choose to write their own lexer. lex just isn't meant to parse something like that...
Regards,
Anthony Liguori
> END SUB. Or, you can define END[ \t]+SUB
> in lex and then have an END_SUB keywork
> or something.
Yes, that's (END_SUB keyword) how I do it. Note that lex always returns the longest matching sequence so 'END SUB' is always matched as END_SUB and never as an END and a SUB token.
> I don't know, maybe I'm just a bit old school
> considering how fast computers are, but I
> always was of the opinion that lex should
> have very short simple tokens and the rest
> should be in yacc.
I have exactly the opposite opinion (but I don't know if it's better, faster, ...): do all lexical analysis (i.e. splitting a character stream in tokens) in lex and do only parsing in yacc...
> Anyway, it all really doesn't matter because
> there's a better argument against using lex
>/yacc for a BASIC language.
> a.print = 1
> is valid in most BASIC languages. Try
> writing a rule to parse that correctly when
> PRINT is a token. Isn't very fun. ANTLR is
It depends on what you mean by a.print. QuickBASIC allowed the . both as part of the identifier and as a way to select fields from a struct ('user defined type') and is (therefore) ambiguous. The way to solve it is to make 'a.print' as a whole a (symbol) token and do some symbol-table magic in the parser.
If you don't allow . as part of the identifier (only as field selection): it's defininetely a bad idea to allow reserved words as fields.
OTOH antlr is a good tool too. If you're comfortable using it: please don't let me convince you otherwise ;-)
CU, Eddie.
Sure, I agree with You guys but please keep in mind that (that's my opinion) we should all gather and make GNU BASIC that follows standards, compiles and runs on all platforms that has GNU tools ported on themselves etc...
My opinion that we can all take THE BEST from our projects (which are small or big, no matter) according to some TODO list made by ourselves and than put everything there.
Also my opinion that that new BASIC should be a part of GNU Compile Collection! :)
If there is interest in such thing I would like to hear from You, and later we can make "gnu-basic" SourceForge project and start working on it.
Please respond! :) The main goal of this foundry IS to gather all developers willing to contribute on ONE BASIC that works/serves well.
Best regards to all!
------------------------------------------
Dejan Lekic <dejan linuks.org>
Are you talking about 1 standard GNU BASIC language (dialect) or about a GNU BASIC compiler framework, supporting multiple BASIC dialects? If you're talking about the former: greater powers than you and me have tried and failed ;-) (e.g. ANSI BASIC, QuickBASIC (if you don't want to call that a standard, at least it was a de facto standard for a while), ...).
For the next version of XBasic I am using the latter approach. It will consist of a frontend (scanner/parser) written using Lex/Yacc that generates an abstract syntax tree and a backend that converts that abstract syntax tree into code. At first C, later maybe assembly but probably RTL (the intermediate language used by the GCC). The abstract syntax tree is not XBasic specific but can be generalized to support more BASIC dialect. Using this approach implementing another BASIC dialect means implementing a scanner/parser for it. That still won't be trivial but at least it won't be as large a task as writing a full compiler.
An Object Oriented XBasic compiler is only planned for later, but it will be able to use the same framework (only the AST and probably the symbol table need to be extended to support object oriented constructs).
Unfortunately not much code is already available, due to (as always) lack of time.
I am interested in cooperating with other compiler-writers for this framework, or maybe even use an existing framework (I know currently of none).
We talk about BASIC but we actually we talk about the keywords and the style of the standard commands (like the IF-THEN-ELSE, FOR-TO-NEXT etc).
It cannot be a standard for all BASICs. btw the BASIC itself has no standard.
Take a look of GWBASIC, QBASIC, VB; all those are created by the same company but had too much differences.
There are differences inside the base of every implementetion (example: there are BASICs with and without data-types (variants); of course there are and mules (call me VB) which supports both).
There are easy implementations (like my SB), there are complex implementations too (with OOP, dynamic-lists etc).
If we want a standard, that standard cannot be one for all but 3-4 different.
like:
a) old-style (with numbers)
b) simple structured style (without numbers, with procs/funcs).
c) strict structured style (like b, but with data-types).
d) like (c) but with objects
Every basic implementation has something common with others (that's why they are called Basic :-) ), but all the time they tend to have differences with the existing versions and a lot of them arn't forced by the base if the implentation. It is a serious problem for those who prefer to programme in Basic.
BTW:VB is a weak-typed language. when variable isn't defined explicitly it has type "Variant" that can be dynamically casted to any-other built-in type.
Who on the earth now will need basic with numbered lines? Who will programme in it?!
The same about b). c) and d) - only these can be talked about as a "programming language". We are in 21 century folks.
> Every basic implementation has something common with others (that's why they are called Basic :-) ), but all the time they tend to have differences with the existing versions and a lot of them arn't forced by the base if the implentation. It is a serious problem for those who prefer to programme in Basic.
I agree.
> Who on the earth now will need basic with numbered lines? Who will programme in it?!
I agree, but it is part of BASIC's world.
> The same about b). c) and d) - only these can be talked about as a "programming language". We are in 21 century folks.
I totaly disagree. SB is working on (b) and it will stay on it. That exactly is what I was tried to do. A simple language for simple things (don't cared about speed, memory, low-level). Just simple as was our old home computers. If I want something more then I'll use a more powerfull tool like C++ or C or Java or something else (it is depended on what I want to do).
BASIC was created for beginners, and that is the advantage.
=== Is simple that (random selection from MSDN):
' The property value can only be set once.
Public Property Set Parent(ByVal NewParent _
As Department)
If deptParent Is Nothing Then
' Assign the initial value.
Set mdeptParent = NewParent
Else
Err.Raise Number:=vbObjectError + 32144, _
Description:="Parent property is read-only"
End If
End Property
=== Or that:
FUNC F(x)
IF x THEN
f = 1/x
ELSE
PRINT "F(x): div. by zero"
STOP
ENDIF
END
Sorry, but I want only the second style
>I totaly disagree. SB is working on (b) and it will stay on it. That exactly is what I was tried to do. A simple language for simple things (don't cared about speed, memory, low-level). Just simple as was our old home computers.
Well, have you ever thought about anyone else then you using you basic? or it's just for personal use? If you want it to be useful you will have to add a lot of functions behind those you'll find in gw-basic or qbasic.
>If I want something more then I'll use a more powerfull tool like C++ or C or Java or something else (it is depended on what I want to do).
Why not a more powerful Basic instead?
>BASIC was created for beginners, and that is the advantage.
Do you think all Basic programmers are dummies? No, I hope.
Basic is a simple language, that's it's advantage. But that doesn't obligate it to be primitive.
I think I was wrong about b) class. It also offers a good subset of Basic language.
So, are we agree?
There must be at least 2 or 3 standards.
a) for history reasons, old-style BASIC with numbers
b) Simple style for novices, calculus, perhaps, for cgi too (instead of perl)
c) Strict style (with or without objects) for developers
Are we agree on that?
I think it is great that there many basic projects and I hope there always will be. There hardly could be some one "big" basic compiler/interpreter that will satisfy all the users/developers. BUT, why not standardize Basic language itself? If someone writes Basic-like language for game development he will need a lot of graphics functions and a almost none, for example, for databse connections. But he should keep the syntax in accordance to some standard, even if he will require to add new function he should do it in some standartized way. If someone writes language for operations with db he will have to follow all the standards for db functions and may omit all the rest and son on.
That will help users a lot, as they won't have to relearn the language. It is even better when there are many basic implentations as every has it's own string sides. Just imagine what a powerful tool will be a dozen of basic compilers/interpreters if they would share the same standard?
I don't think it is possible to achieve full compatibility, when one will be able to use this or other compiler/interp. for the same source code. But it is possible to code the same things in some unified way in all basic flavours.
I don't know if it's a good idea to create a 'one size fits all', 'universal' BASIC, because changes are it will become just 'yet another BASIC dialect'.
The beauty of a good component model (and I don't mean just UI components) is that it's not important in which language a component is written to be able to use it. You only need the component itself (probably as a compiled binary, maybe even as a 'web service'), it's interface and some documentation on how to use it.
I.e. a component model can be integrated into any existing BASIC compiler / interpreter. Obviously an Object Oriented component model fits better in a Object Oriented language, but it's not impossible to use it in a non object oriented language.
The following list shows the future of KBasic:
KBasic1 - 1st Generation, old standard BASIC, qbasic like (1.1 - 1.9) <--- we are here
KBasic2 - 2nd Generation, GUI BASIC, vb like (2.1 - 2.9)
KBasic3 - 3rd Generation, OO-BASIC, vb.net like (3.1 - 3.9)
As you can see there is a long way to go, but v1.0 will be released in February 2002. We reached many milestones yet. It contains a clean structure in scanner, parser and interpreter. The tokens are defined in a list, the parser is handwritten 100% syntax compatible with qbasic and the interpreter is a pcode stack machine and all in C++. A (66% finished andcopyright free ) command help already exist. And many other parts...
~Bernd~
bernd@kbasic.org
www.kbasic.org
Unfortunatelly my opinion is that BASIC (or any other compiler/interpreter) language should be aware of GUI ToolKit...
KBasic is strictly KDE stuff, the same is with (wanderfull) GnomeBASIC which is GREAT project! BUT, what if I don't want to make KDE or GNOME application? Per example, i like FLTK more than GTK or KDE! :)
KBasic is cool project but it's goal is to be specifis in some way...
XBASIC, YaBASIC, ScriptBASIC, Lemmick BASIC are projects that are more opened than KBasic when we consider that, that's my opinion.
Best regards! :)
Yes, we don't need a 'Univesal' product, but we do need one or two 'Leader' product, with modern and high-class features and cross-platform, widely supported and used, just like VB in the commercial software world, so BASIC can be a real living language.
The more I read these posts the more I'm wondering if a simple C++ namespace framework that could be used by multiple Basic parsers would be a better solution than trying to build compatible Basics.
It would be important to have a universal BASIC, but it is equally important to have different 'flavors' as well. There might be a way that both of these may be possible.
A new standard could be created stating the rules of BASIC. These rules would inlcude all of the statements in BASIC. These would then be programed into a 'core module'. This project would be in an open forum so that people could make suggestions to the updating and improvement of the module.
Programers and developers could then take this core module and use it when writing their own BASIC interpreters/compilers. However, they could still be able to define their sintax to their personal preference. They would create a 'front end' the the standard core BASIC module that would translate, if necessary, their own functions, into the standard BASIC form.
Thier could also be another version that would just use the standard core module without any modifictions. This would then be the 'official/standard' language for BASIC.
Sounds just like my own idea!
First of all we all should define set of "standard" statements and functions and their syntax as well.
Implementation of "core" basic is something mmm... mystical becouse there are basics which compile to object code and others to bytecode and some are plain interpreters. But i see no problems in implementing a pair of good .so libs that will implement BASIC's functions and some other things like support for symbol table operations, hashes and etc.
I will be happy to take part in this new project. does it has sourceforge location/url?
I would to be a part of such a project, but I think that it would be crucial to get as many viewpoints as possible. This way, the standard for this new BASIC language would be the oppinions of many instead of a few. If there is enough interest in this, a project site could be started on Sourceforge. Let me know what u think.
> language would be the oppinions of many
> instead of a few. If there is enough interest
> in this, a project site could be started on
> Sourceforge. Let me know what u think.
I hate to sound like a newbie, but: Me too ;-)