I wish that there was more work put into the development of BASIC compilers which are written in the language which they themselves compile. It seems ridiculous to have to write the compiler for a string processing language like BASIC in a language that doesn't really support strings very well (like C and C++).
I would like XBasic more except that it has a distinct problem with being extremely bloated and slow. It has its own GUI system which on Windows doesn't yield properly to other Windows apps and I would presume on Linux it's not running under X. This "feature" makes the language too slow and in some cases too difficult to use. I like the idea of how it works, what I find is the implementation is lacking.
I'd like to see something like BASM286, which was a smaller BASIC compiler, written in BASIC, that generated assembly language which could then be assembled to create an executable program. Or the compiler could generate a binary. Or something else. But I'd like to see better development of leaner, less bloated run-time libraries.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, I agree with You XBasic is slow, NuBASIC team still don't have released reall stuff (files). Have You seen YaBASIC project (i am member of small team that works on it)? I am interested in what You'll say about YaBASIC (www.yabasi.de)... Unfortunatelly, GnomeBASIC is NOT hosted on SourceForge - I intend to talk with their project leader and tell 'em about BASIC foundry on SourceForge.
My opinion is that BASIC SHOULD not be _DEDICATED_ to some environment/gui library (or something else), like GnomeBASIC and KBasic are...
It's would be much better if we have BASIC that can be used for writing both for GNOME and KDE (FLTK, FOX etc.) applications!
Best regards
Dejan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> My opinion is that BASIC SHOULD not be
> _DEDICATED_ to some environment/gui library
> (or something else), like GnomeBASIC and
> KBasic are...
Although for obvious reasons it is tied to the GUI of Windows I like the way Visual Basic supports (to a certain extent) object orientation such as methods, properties and events. This kind of capability (or the base level of same) is what is necessary and should be done by a standard type of BASIC.
The GUI should be supported as a class or library in which you would manipulate various properties and /or methods and if necessary, handle events passed back to your program. This would make the system relatively independent of the GUI system being used.
That too, is another issue at least to the extent of being able to develop versions of basic on Unix boxes is that for GUI support you have to pick either GNOME or KDE (or possibly CDE or Motif) to write for and there really isn't an easy way to develop something that will run on X without developing for every desktop out there. The X market is small enough without further fragmentation, if something isn't done, X will lose over the homogenous environment of Microsoft Windows.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't agree with that it's a bad idea to write (BASIC-)compilers in C. C has the advantage that it has many tools available, like lex, yacc and the gcc-backend (used as a portable code-generator).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I don't agree with that it's a bad idea to
> write (BASIC-)compilers in C. C has the
> advantage that it has many tools available,
> like lex, yacc and the gcc-backend (used as
> a portable code-generator).
If you particularly like working that way, more power to you.
As I see it, BASIC has the power to be self-compliling much as Pascal and C are. (the FreePascal compiler is written in itself and if it were possible to convert it so it would read Basic code it might be a place to look).
Writing a compiler in a different language than the target means you now need to know two different languages; the language used to implement the compiler and the language of the compiler (on top of whatever the compiler generates, which is another issue). If the compiler is written in itself it provides an additional advantage in that you can get extra help in finding bugs because people who write code using the compiler can actually debug it.
Every time you add a layer of abstraction to a system you add another layer of complexity. Having a language is one layer of abstraction. Having the language compiler is another layer of abstraction. Having that compiler in yet another language adds another layer. Now, if there is a bug in a user's code, does he blame the output code, his source, or are there bugs in the compiler. If the code for the compiler is the same as the language it accepts it is easier to spot errors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> As I see it, BASIC has the power to be self-compliling much as Pascal and C are. (the
> FreePascal compiler is written in itself and if it were possible to
> convert it so it would read Basic code it might be a place to look).
I agree. E.g. XBasic proves this.
> Writing a compiler in a different language than the target means you now need to know
> two different languages; the language used to implement the
> compiler and the language of the compiler (on top of whatever the compiler generates,
> which is another issue). If the compiler is written in itself it
> provides an additional advantage in that you can get extra help in finding bugs because
> people who write code using the compiler can actually debug it.
I agree that it has it's advantages. It also has it's disadvantages, like bootstrapping. You can't write the first version of your (new) language compiler in that same language (becaus, obviously, a compiler of that language does not yet exist).
Another point is choosing the right tool for the job. "If the only tool you have is a hammer, everything looks like a nail". You don't e.g. want to write a 'bash' compiler/interpreter in 'bash' (but this doesn't fully apply to BASIC, I agree that BASIC is powerful enough to build a compiler in it).
Note that I like C/C++ and Java better than BASIC, that might partly explain my point of view.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What part of XBasic do you consider slow? And compared to what? It generates (not highly optimized, but not too bad either) assembly-code. Compared to e.g. QuickBASIC (the compiler) it runs in general a lot faster.
I agree that the GUI system is somewhat different, but it has the advantage that a program written on Win32 runs without modification with the same look-and-feel on Linux (under X!). I agree however that in many cases a more 'native' GUI is preferable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> What part of XBasic do you consider slow?
The Graphical User Interface
> And compared to what?
A program not using a GUI or one written for the native one.
The problem I have is that the way XBasic is designed it only has it's own GUI for itself and there is no other choice. Perhaps it has changed since the last time I tried it but I found it buggy, slow and hoggy. Having your own GUI so that it's the same on both Windows and Linux is okay, but not if the program is so slow as to be unusable or that it is so hoggy of machine time that it slows everything else down.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> > What part of XBasic do you consider slow?
> The Graphical User Interface
> > And compared to what?
> A program not using a GUI or one written for the native one.
Ah ok. I fully agree. Having a non-GUI version is already high on my wishlist.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What about a feature with which a Basic Program can link shared libraries on runtime to use any special GUI ? P. ex. a Programm wants to use Qtlib, so it cal link the library and execute any function in this lib. So the standard Basic interpreter/compiler need not support it.
regards M.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have written a self-compilable Basic language. It is called unibase because it also has an internal database as datastructure. But it still is Basic...
Oh, I forgot...
It is also hosted on sourceforge but only recently... The project is called (not surpringly) unibase.
The current version of the language only works on limited systems (I made some assumptions that turned out wrong in the internal datastructures) but very soon the language will work on any system that supports normal ANSI-C.
My intension is to use CGI as the main user-interface... it is platform independent but is has the requirements of an active web-server...
Oh... this language is fast enough... and I hope stable enough for all pratical uses...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On the note of Nubasic about the 2nd or 3rd post.... Its being done by one person.... we just waiting till something gets done.... He(slowbyte) had some source but nothing final.. Garbage Collection and what-not....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why should be Basic compiler able to compile itself?
It just doesn't suits for this. I prefer using generated parsers where it's possible, but I'm not going to rewrite yacc on basic - it's just too boring. Basic is good for other things, not for writing compilers where C rules.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Why should be Basic compiler able to
> compile itself?
A compiler is (or should be) nothing more complicated than a text editing program. A source program is a series of strings stored in a text file and is manipulatable by any program that can handle text files and strings.
As far as BASIC is concerned, the string processing capabilities of anything but the lighest toy BASIC far exceed those of C or C++ therefore BASIC is ideally suited for self-compilation.
> It just doesn't suits for this. I prefer
> using generated parsers where it's possible,
> but I'm not going to rewrite yacc on
> basic - it's just too boring. Basic is
> good for other things, not for writing
> compilers where C rules.
It may have been because BASIC wasn't considered a serious language - and if you read the minimum requirements for ANSI minimal BASIC you would say the same thing - but then again, people used to think Pascal wasn't a serious language.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Why should be Basic compiler able to compile itself?
>It just doesn't suits for this. I prefer using generated parsers where it's possible, but I'm not going to rewrite yacc on basic - it's just too boring. Basic is good for other things, not for writing compilers where C rules.
C syntax uses pointers all over the place and is difficult to use. C++ fixes a lot of things but still has a kludgey syntax: you miss one semicolon or curly brace and you could be searching for weeks trying to find what went wrong!
IMO: In order to be practical any new programming language should kick C in the hind quarters or get out of the way of other programming languages that will. If that means adding rule-based syntax that can kick BISON and YACC in the tail section and FLEX in the gluteus maximus then that's fine with me!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wish that there was more work put into the development of BASIC compilers which are written in the language which they themselves compile. It seems ridiculous to have to write the compiler for a string processing language like BASIC in a language that doesn't really support strings very well (like C and C++).
I would like XBasic more except that it has a distinct problem with being extremely bloated and slow. It has its own GUI system which on Windows doesn't yield properly to other Windows apps and I would presume on Linux it's not running under X. This "feature" makes the language too slow and in some cases too difficult to use. I like the idea of how it works, what I find is the implementation is lacking.
I'd like to see something like BASM286, which was a smaller BASIC compiler, written in BASIC, that generated assembly language which could then be assembled to create an executable program. Or the compiler could generate a binary. Or something else. But I'd like to see better development of leaner, less bloated run-time libraries.
Yeah, I agree with You XBasic is slow, NuBASIC team still don't have released reall stuff (files). Have You seen YaBASIC project (i am member of small team that works on it)? I am interested in what You'll say about YaBASIC (www.yabasi.de)... Unfortunatelly, GnomeBASIC is NOT hosted on SourceForge - I intend to talk with their project leader and tell 'em about BASIC foundry on SourceForge.
My opinion is that BASIC SHOULD not be _DEDICATED_ to some environment/gui library (or something else), like GnomeBASIC and KBasic are...
It's would be much better if we have BASIC that can be used for writing both for GNOME and KDE (FLTK, FOX etc.) applications!
Best regards
Dejan
> My opinion is that BASIC SHOULD not be
> _DEDICATED_ to some environment/gui library
> (or something else), like GnomeBASIC and
> KBasic are...
Although for obvious reasons it is tied to the GUI of Windows I like the way Visual Basic supports (to a certain extent) object orientation such as methods, properties and events. This kind of capability (or the base level of same) is what is necessary and should be done by a standard type of BASIC.
The GUI should be supported as a class or library in which you would manipulate various properties and /or methods and if necessary, handle events passed back to your program. This would make the system relatively independent of the GUI system being used.
That too, is another issue at least to the extent of being able to develop versions of basic on Unix boxes is that for GUI support you have to pick either GNOME or KDE (or possibly CDE or Motif) to write for and there really isn't an easy way to develop something that will run on X without developing for every desktop out there. The X market is small enough without further fragmentation, if something isn't done, X will lose over the homogenous environment of Microsoft Windows.
I don't agree with that it's a bad idea to write (BASIC-)compilers in C. C has the advantage that it has many tools available, like lex, yacc and the gcc-backend (used as a portable code-generator).
> I don't agree with that it's a bad idea to
> write (BASIC-)compilers in C. C has the
> advantage that it has many tools available,
> like lex, yacc and the gcc-backend (used as
> a portable code-generator).
If you particularly like working that way, more power to you.
As I see it, BASIC has the power to be self-compliling much as Pascal and C are. (the FreePascal compiler is written in itself and if it were possible to convert it so it would read Basic code it might be a place to look).
Writing a compiler in a different language than the target means you now need to know two different languages; the language used to implement the compiler and the language of the compiler (on top of whatever the compiler generates, which is another issue). If the compiler is written in itself it provides an additional advantage in that you can get extra help in finding bugs because people who write code using the compiler can actually debug it.
Every time you add a layer of abstraction to a system you add another layer of complexity. Having a language is one layer of abstraction. Having the language compiler is another layer of abstraction. Having that compiler in yet another language adds another layer. Now, if there is a bug in a user's code, does he blame the output code, his source, or are there bugs in the compiler. If the code for the compiler is the same as the language it accepts it is easier to spot errors.
> As I see it, BASIC has the power to be self-compliling much as Pascal and C are. (the
> FreePascal compiler is written in itself and if it were possible to
> convert it so it would read Basic code it might be a place to look).
I agree. E.g. XBasic proves this.
> Writing a compiler in a different language than the target means you now need to know
> two different languages; the language used to implement the
> compiler and the language of the compiler (on top of whatever the compiler generates,
> which is another issue). If the compiler is written in itself it
> provides an additional advantage in that you can get extra help in finding bugs because
> people who write code using the compiler can actually debug it.
I agree that it has it's advantages. It also has it's disadvantages, like bootstrapping. You can't write the first version of your (new) language compiler in that same language (becaus, obviously, a compiler of that language does not yet exist).
Another point is choosing the right tool for the job. "If the only tool you have is a hammer, everything looks like a nail". You don't e.g. want to write a 'bash' compiler/interpreter in 'bash' (but this doesn't fully apply to BASIC, I agree that BASIC is powerful enough to build a compiler in it).
Note that I like C/C++ and Java better than BASIC, that might partly explain my point of view.
I agree with You. Assembly and C is the best choice for development of some interpreter/compiler.
What part of XBasic do you consider slow? And compared to what? It generates (not highly optimized, but not too bad either) assembly-code. Compared to e.g. QuickBASIC (the compiler) it runs in general a lot faster.
I agree that the GUI system is somewhat different, but it has the advantage that a program written on Win32 runs without modification with the same look-and-feel on Linux (under X!). I agree however that in many cases a more 'native' GUI is preferable.
> What part of XBasic do you consider slow?
The Graphical User Interface
> And compared to what?
A program not using a GUI or one written for the native one.
The problem I have is that the way XBasic is designed it only has it's own GUI for itself and there is no other choice. Perhaps it has changed since the last time I tried it but I found it buggy, slow and hoggy. Having your own GUI so that it's the same on both Windows and Linux is okay, but not if the program is so slow as to be unusable or that it is so hoggy of machine time that it slows everything else down.
> > What part of XBasic do you consider slow?
> The Graphical User Interface
> > And compared to what?
> A program not using a GUI or one written for the native one.
Ah ok. I fully agree. Having a non-GUI version is already high on my wishlist.
What about a feature with which a Basic Program can link shared libraries on runtime to use any special GUI ? P. ex. a Programm wants to use Qtlib, so it cal link the library and execute any function in this lib. So the standard Basic interpreter/compiler need not support it.
regards M.
I have written a self-compilable Basic language. It is called unibase because it also has an internal database as datastructure. But it still is Basic...
It's on http://www.unibase.org
To build it I wrote a compiler in C and the next and full version into the first one.
Oh, I forgot...
It is also hosted on sourceforge but only recently... The project is called (not surpringly) unibase.
The current version of the language only works on limited systems (I made some assumptions that turned out wrong in the internal datastructures) but very soon the language will work on any system that supports normal ANSI-C.
My intension is to use CGI as the main user-interface... it is platform independent but is has the requirements of an active web-server...
Oh... this language is fast enough... and I hope stable enough for all pratical uses...
On the note of Nubasic about the 2nd or 3rd post.... Its being done by one person.... we just waiting till something gets done.... He(slowbyte) had some source but nothing final.. Garbage Collection and what-not....
Why should be Basic compiler able to compile itself?
It just doesn't suits for this. I prefer using generated parsers where it's possible, but I'm not going to rewrite yacc on basic - it's just too boring. Basic is good for other things, not for writing compilers where C rules.
> Why should be Basic compiler able to
> compile itself?
A compiler is (or should be) nothing more complicated than a text editing program. A source program is a series of strings stored in a text file and is manipulatable by any program that can handle text files and strings.
As far as BASIC is concerned, the string processing capabilities of anything but the lighest toy BASIC far exceed those of C or C++ therefore BASIC is ideally suited for self-compilation.
> It just doesn't suits for this. I prefer
> using generated parsers where it's possible,
> but I'm not going to rewrite yacc on
> basic - it's just too boring. Basic is
> good for other things, not for writing
> compilers where C rules.
It may have been because BASIC wasn't considered a serious language - and if you read the minimum requirements for ANSI minimal BASIC you would say the same thing - but then again, people used to think Pascal wasn't a serious language.
>Why should be Basic compiler able to compile itself?
>It just doesn't suits for this. I prefer using generated parsers where it's possible, but I'm not going to rewrite yacc on basic - it's just too boring. Basic is good for other things, not for writing compilers where C rules.
C syntax uses pointers all over the place and is difficult to use. C++ fixes a lot of things but still has a kludgey syntax: you miss one semicolon or curly brace and you could be searching for weeks trying to find what went wrong!
IMO: In order to be practical any new programming language should kick C in the hind quarters or get out of the way of other programming languages that will. If that means adding rule-based syntax that can kick BISON and YACC in the tail section and FLEX in the gluteus maximus then that's fine with me!