Self-compilable BASICs (again)
Brought to you by:
leka,
scriptbasic
Menu
▾
▴
The old thread is just that, old, and I figured a fresh thread would be good.
Basicaly, I feel that BASIC should be self-compilable, as it stands now we can do a lot in BASIC, but there's not really an advanced BASIC compilier written IN BASIC.
The only argument against it that I feel has merit is bootstrapping (which came first, the chicken or the egg?) but even that can be bypassed now. Write a BASIC compilier in BASIC, compile it with one of the existing compiliers, and there you have it.
This would infact allow for an OS that is fully BASIC (one of the major points to an OS is that it should be capable of recompiling itself entirely, including kernel and compilier.)
Certainly the practical usefulness of such an OS could be questionable, but it would be a valuble learning tool, as BASIC can be a very easy language to pick up, and anyone could dive into the OS and make changes easily.
Of course there also is the "cool" factor of running an OS made entirely in BASIC :).
> Basicaly, I feel that BASIC should be self-
> compilable, as it stands now we can do a lot in
> BASIC, but there's not really an advanced BASIC
> compilier written IN BASIC.
XBasic is written in XBasic. But a future version of it will probably be written in C, mainly because of the availability of advanced compiler tools like lex/yacc and a portable 'code generator' (gcc backend).
>This would infact allow for an OS that is fully BASIC (one of the major points to an OS is that it should be capable of recompiling itself entirely, including kernel and compilier.)
Wow! A Commodore 64 or Apple II all over again! I actually like this idea...almost.
>Certainly the practical usefulness of such an OS could be questionable, but it would be a valuble learning tool, as BASIC can be a very easy language to pick up, and anyone could dive into the OS and make changes easily.
>Of course there also is the "cool" factor of running an OS made entirely in BASIC :).
The problem with this idea is to make a Basic that if the language gets to complicated it won't be easy to use any more.
I DO agree with opinion that pure, and good BASIC compiler HAVE TO BE self-comilable! :)
> Basicaly, I feel that BASIC should be
> self-compilable,
To me this is the most significant difference between a "real" language and something which is considered a "toy" language and not a serious means for serious problem solving.
> as it stands now we can do a lot in BASIC,
> but there's not really an advanced BASIC
> compilier written IN BASIC. The only
> argument against it that I feel has merit
> is bootstrapping (which came first, the
> chicken or the egg?)
You could write a minimal definition of a basic language that you could compile using a compiler written in GWBasic and run using even Microsoft's interpreter on an 8086 if you had to. But the answer is to develop a basic compiler that either generates object files and/or executable files, or which generates assembly language or (if necessary) some other language as output. Once you get to the point of a compiler that can compile itself then you can port the compiler anywhere.
> but even that can be bypassed now. Write a
> BASIC compilier in BASIC, compile it with
> one of the existing compiliers, and there
> you have it.
I suggest one write the minimum necessary to create a compiler and then once it can compile itself then you have a serious tool to work with.
> This would infact allow for an OS that is
> fully BASIC (one of the major points to an
> OS is that it should be capable of recompiling
> itself entirely, including kernel and
> compilier.)
You're preaching to the converted here, as far as I'm concerned. It is a hell of a lot easier to code in a language like Basic, or Pascal, or even Fortran than it is to code in an overly complicated language (or should it be more rightly called a religion) such as C/C++
> Certainly the practical usefulness of such
> an OS could be questionable,
How about an OS in which ordinary mortals - not merely the priveleged few 'guru' class programmers who understand C - and could write new routines for it. Make the system more understandable by 'ordinary' people and you make it possible for more people to be able to offer enhancements and improvements.
> but it would be a valuble learning tool, as
> BASIC can be a very easy language to pick up,
> and anyone could dive into the OS and make
> changes easily.
You took the words right out of my e-mail.
> Of course there also is the "cool" factor of
> running an OS made entirely in BASIC :).
A large part of this existed in RSTS/E which was around 20 years ago. While the limits of the technology did not permit writing the actual base operating system and compilers in anything except assembly language, almsot all of the tools on the system - directory listings, login, account management, etc. were all written in Basic-Plue.
Today we have much larger machines and better understanding of how these systems work. Except for a tiny amount of material requiring assembly (such as task switching or extremely time-critical routines) it is possible to have an OS written using Basic. It may require adding new features but that's been happening for decades.
> How about an OS in which ordinary mortals - not merely the
> priveleged few 'guru' class programmers who
> understand C - and could write new routines for it. Make the
> system more understandable by 'ordinary' people
> and you make it possible for more people to be able to offer
> enhancements and improvements.
I had this same idea of writing a BASIC-based OS a while back, and found that there are a number of issues to contend with:
1. Language scalability. The classic `line number' BASIC, though simple, isn't good for coding large-scale or even medium-scale programs. Unfortunately, if you add stuff to allow BASIC to scale up (e.g. OOP constructs, lexical scoping, etc.), it's not simple anymore. This has implications on the design of the kernel itself, if the kernel's to be written in BASIC.
2. Should the OS be fully persistent (i.e. no explicit file storage)? If yes, then there has to be a way to manage several BASIC programs without resorting to external storage.
3. Audience. Though I have no doubt that the "ordinary mortals" as mentioned exist, there has to be a way to reach them (and SourceForge's probably not it).