Printable View
The only hard part I could see with this project is actually figuring out how to convert the parser into a compiler. I was thinking somewhere along the lines of parsing the language into C/C++ then having a C/C++ compiler do the hard work for us. Perhaps we could think of doing that?
We would like to have the same person working on the compiler the whole time, but that might not be a realistic possiblity at this point.
You seem like the perfect person for the job, but do you honestly feel you have the time/energy to put a month or 2 of work into this project? If you have the time, then you will most likely get the position.
As long as you want to help we are glad to have you. Especially with your previous experience with Flex and Bison.
Before we were thinking of parsing into ASM and using an asm compiler (MASM?) to do the work for us (we are trying to make the compile the fasted code possible). Jake thought about parsing into C++, but we need a free C++ compiler (perferablly open source) to use. Free assemblers are easier to come by. What are your thoughts on this?
Well, ASM would be faster, but C++ would be easier. I know of a great free C++ compiler that we can use: MingGW. You might have heard of it. I use it along with the Dev-C++ IDE, and its better than VC++ :D
Anyways, 2 months of work...hmm...I would love to do it but I have school work todo, and I'm not really meant to use my laptop during the week. BUT, this would be a great experince, and definatly a step up form my scripting language: SIMPLE. (ps. I'm working on a language at the moment called ModBAS, a step up from basic towards C/C++).
I would love to try and help in any way possible. Sign me up ;)
-Girvo
MinGW would be perfect as far as I can tell. I don't know a WHOLE lot about it but I can do some research. It is licensed under the GPL right?
What is the Dev-C++ IDE?
I'm in school too so I feel your pain on that note. I also have a girlfriend so that brings my programming time down to near 0, but I still manage to squeeze out some results.
So you think your up for this? You will be starting us on the most important aspects of the compiler so you have a lot of power in your hands. I guess the parser is where we need to start, though.
Translating into C++ is fine because we can inline asm (or can you not do that with MinGW)?
I'll download MinGW and Flex and Bison later today and look around so I can get a feel for what you are working with.
Have you read the whole project thread (or most of it)? I think it would help if you did. You might also want to read the threads that are linked to at the bottom of the first post.
As long as Jake and Penagate don't have any problems with it, then I'm pleased to say Welcome Aboard!
I don't have a problem with it. We need as many team members as we can get anyways to get this project in gear, so we don't risk situations like I'm in. It's gonna take more than one or two people to work on the compiler and linker anyways since it's so difficult to work with.
And I sorta have a girlfriend myself, only I'm not in a relationship. All we ever do is....yeah you know ;)
brag? :DQuote:
Originally Posted by Jacob Roman
On a (more) serious note, why emit C++. C would be easier, and a bit closer to assembly so it would be easier to turn into a full assembly-emitting compiler later down the track.
Not terribly closer, but I see what you mean.Quote:
Originally Posted by penagate
EM: The Dev-C++ IDE is exactly what it says, an IDE. Last time I had a look at it you needed to supply the compiler, which is probably why Girvo is using MinGW with it..
chem
Re MinGW, this is the page you will be interested in.
MinGW is not itself a compiler however. It is merely a library and collection of header files. It includes the GCC compiler, which is of course distributed under the GPL. The MinGW runtime library is, as far as I can tell, freely distributable and modifiable without any licence terms.
Emitting C sounds like a good compromise.Quote:
Originally Posted by penagate
I couldn't find anyplace to download it from that link, just a crap load of documentation that I will never have time to read (even though I really want to at least read some of it) because of the my current homework load.Quote:
Originally Posted by Penagate
I'll search some more for a place to download stuff at.
how hard would it be to convert an OOP language like lightfusion into a non-OOP language like C?
Not very hard. The original C++ compiler, Cfront, emitted C. Still does, in fact.
Why can't I find a place to download the GNU compilers? Yesterday was the 2nd or 3rd time I have looked for a place to download them at, and all I can find is a "List of successful builds". Where can I find a link to directly download them? How about for MinGW?
Hi there.
C would be eisier seing as that C is Flex's default output language. If you would like to see what tools I am using, then check out this site: www.bumblebeesoftware.com and www.bloodshed.net
I am using Parser Generator which pretty much gives you an IDE for Flex and Bison. Pargen uses its own version however, which can output to C,C++, and Java, depending on what you would like.
Bloodshed has the Dev-C++ IDE, which in my opinion is the best there is.
Anyways, if you would like me to buyild a simple parser for LightFusion, one that doesn't do much, but has the bare basics, then I'll get to work on it. If someone could provide me the syntax.
For example, could someone translate what this would look like in LightFusion:
Notice that this is just a simple program. If you could give me the LightFusion syntax for this, I can make a working parser that could make programs like this.Code:#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!\n";
int x=5;
int y=10;
area = x*y;
cout << x << " times " << y << " equals " << area;
if(x<y)
{
cout << "X is smaller!\n";
}
else
{
cout << "Y is smaller!\n"
}
}
-Girvo911
I just had an idea.
Instead of having the error checking built into the parser (very frustrating), what if we had it built into the IDE itself? It would run a scan over the code before it even gets sent to the parser. The parser would include some basic error checking, I can't avoid that. But the IDE could handle all of the more fiddly stuff.
What do ya think?
You can probably only have very limited error checking without performing a lot of the steps needed for compilation.
For example, you need to know the Type of every expression to check for type mismatches. You need to know which variable an identifier refers to if it's inside multiple block statements. You need to know the definition and type of a function to determine if the proper number and types of arguments are being passed to it.
Basically, you need a parse tree to perform any sort of definative error checking.
GNU itself only provides GCC in source form. You can find a list of mirrors here:Quote:
Originally Posted by eyeRmonkey
http://gcc.gnu.org/mirrors.html
Then you have to navigate to the release you want, e.g. for 3.4.4 at the Austrian University of Technology:
ftp://gd.tuwien.ac.at/gnu/gcc/releases/gcc-3.4.4/
Installation instructions are here:
http://gcc.gnu.org/install/
Be warned: installing GCC from source is not trivial.
Probably every Linux distro has GCC packaged somehow, though, making this process a lot easier.
MinGW, now ...
MinGW seems to be just as complicated. There's supposed to be a one-file installation, but it's hard to find it. The instructions are here:
http://www.mingw.org/download.shtml
I believe you need to scroll down to the "Proposed" section and get " MinGW 5.0.0". It seems to be an installer. However, running under Linux right now I can't test this.
You could also get Cygwin, which allows you very easy installation of MinGW. But there's a lot of bloat coming with that.
While it's always nice to have as much error detection in the IDE as possible, it's a very bad idea to remove it from the compiler. That would mean that the compiler depends on the IDE to keep bad code from it, which means it can't run standalone. Which is not good.Quote:
Originally Posted by Girvo911
That's not to mention that this means that either the compiler part is extremely unstable (because every coding error would probably make it crash - and incidently, since the compiler depends on the IDE for checking, it will probably be part of the same process and thus crash that, too!) or programmed extremely defensively, to catch all bad input - so you're validating code correctness anyway, just probably in a way that makes it impossible to provide meaningful error messages.
Net gain: none.
Net loss: stability, meaningful error messages, running standalone.
Girvo, I'm downloading ParGen and Dev-C++ as we speak.Quote:
Originally Posted by Girvo911
Have you read the whole thread? I really think you should. You can skim over it and just focus on parts dealing with syntax, but I think it will give you a better idea of what we are after.
There have been a few attempts recently to convert code from any language to LF, but we aren't totally in agreement about everything. I attached a .zip with all the documentation I have relating to syntax. You can take a look at it.
The only problem with the more recent syntax conversions we have done is that we aren't in agreement about some stuff, but you can work off the basics I suppose.
I was actually hoping I wouldn't have to do a ton of error checking in the IDE. Or at least not until later down the road. As a few people have already said, the parser/compiler probably need to be able to do this, even though it is probably a pain.Quote:
Originally Posted by Girvo911
CornedBee, thanks once again for you input. CornedBee
Jake, if you didn't like that most recent sytnax conversion I did, then you REALLY need to do your own so we can see how you envision the syntax.
I ran across this while downloading a bunch of stuff today: http://sources.redhat.com/gdb/
Its the GNU debugger. We aren't really to the point of using it yet, but I thought I might throw it out there so we all know its available. I might save us some more work.
Okay then. I'll have a PROPER read through. I read like the first 4 pages, then skipped to the last ;)
So you would like the error checking built into the parser? Ok then. That shouldn't be TOO hard.
Do you know what the only problem with this is? I've never written an OOP language before. I'm finding out about it as we speak.
Heres a useful site for you all, if you would like to learn a little bit: http://groups.google.com/group/comp.compilers
Thanks for taking the time to read through the thread. :)
Yes, error checking in the parser would be awesome. What exactly does the parser output? C? Then we can automatically feed that into the GCC (the IDE will be in charge of that ;))?
I really don't think its a problem that you haven't written an OOP language before, none of us have written anything before PLUS you have written other languages before which is awesome.
-----------
Just to let everyone know I updated the first post in this thread to be a little more accurate.
Speaking of which, where did Datacide go to? The website was coming along nicely and he just disappeared. I guess its not a big deal, we can find someone else, and he might turn up again.
Well, yes it does output to C. And I expect that the IDE will be in charge of that ;). Oh and incharge of deleting temporary files that get created.
I have been reading through the thread, and I'm wondering whether it would be better for me to write it from scratch. It would give it more functionalty, but be BLOODY hard to do.
What do you think?
-Girvo
Writing it from scratch, as opposed to...?
Writing it using a compiler compiler. YACC. and Lex, which is a lexical scanner.
I'm not the person to make that decision, but IMO a compiler that uses tools to do the actual compilation, is not a compiler.
It wouldn't use tools. Lex and YACC are tools to create the compiler, not tools the compiler uses.Quote:
Originally Posted by penagate
Girvo, what programs would you use if you made if from scratch? And what programs would you use if you made if it emit C? I didn't know YACC/Bison were meant to make compilers, I thought thet just did more parsing stuff.
What makes you say that it would be better to do it from scratch? Other than functionality and the obvious increase in overall control. Do you think your up for it?Quote:
Originally Posted by Girvo911
Could you write a small pro/con list so we can seriously consider wether its worth it or not?
We really need to get the syntax nailed down more so we can start giving Girvo a better idea of what he will be parsing. I guess we really should have started on that earlier, but I thought it would be a while before Jake was ready to do anything to that effect, but now that Girvo is on stuff, we are flying along.
Does anyone have any better ideas for nailing down syntax? Or should we just continue posting project in other languages and converting them?
I'm working on making the project files and I though I would get your guys' opinons on an issue I am having:
Should I have all source code (MDI child) windows load when a project loads (and make specified ones not visible based on what ones were open last time)
OR
Should I have each window load and unload when it is closed/opened?
The first makes slower loading, but easier switching between windows. The second allows faster loading of the project and a little more lag time each time a window is opened and doesn't use as much memory by having a bunch of invisible windows loaded.
Definitely the second.
Sounds good. :)
I have gotten a ton of work done today on the IDE. I need to work on way to save properties and such. I found a cool one on some website where you just pass the actual property value and it saves it using some Interface stuff that I don't understand at all. The only problem with that is the license doesn't let you redistribute it in code format (which is what I have to do since the project is open source.
You can find it here: http://www.mvps.org/emorcillo/en/code/vb6/index.shtml. Scroll about half way down to "How to implement a custom PropertyBag" and "Implementing a dynamic Properties collection in class". The class is the one I was reffering to above (not the property bag).
Any ideas?
LEX and YACC help me build the compiler. Every compiler uses some sort of Lexical scanner to parse the code into readble tokens, which are then sent onto the actuall parser which defines grammer (YACC). I only then have to write a small part of that stuff.Quote:
Originally Posted by penagate
PROS:Quote:
Originally Posted by eyermonkey
-More flexablility
-More control over what the compiler actually does
-More tutorials for me to read up on ;)
CONS:
-A LOT more time consuming
-More work for me
-I've had no experince creating one from scratch, only ever using LEX and YACC
-Girvo
OH! and one more PRO:
-It would be eisier to implement libraries, as I am not sure how to do it using lex and yacc.
I might end up writing library functionality into the main.cpp, which is what brings the lex and yacc together for end compilation. That way, we might even be able to use the standard C libraries!
ANd to answer your question, yes Lex and Yacc, (or in my case: Alex and AYACC) are meant fro parsing. HOWEVER, after I have compiled the Lex and Yacc files into A .h and a .c file, I can then(with a bit of code changing) write a MAIN.C(pp). This file incorparates both the Lex.c(.h) and the Yacc.c(.h) and calls their included functions to begin parsing. Then once parsing is done, it loads the parsed language into another compiler, (Mingw perhaps..) which outpust the .exe.
The Main.c(pp) is where I write some of the more advanced functionality, which becomes pretty easy, as I just have to deal with the end result, i.e. the outputted C code.
-Girvo
You don't. You don't use lex and yacc to implement libraries. You only write the compiler with them. You use the language to implement libraries, and perhaps some foreign-language-connectivity (e.g. JNI in Java, Managed C++ in .Net) for the low-level stuff.Quote:
-It would be eisier to implement libraries, as I am not sure how to do it using lex and yacc.
Ah. I thought as much. Ok then, ignore that statment.
Okay, a few more questions come to mind then:
* What tools will you use to write the compiler if you do make it?
* Do you want to make that kind of a time comitment to this project? (because we are more than willing to have you for as long as you want to stay :))
* Would you be writing a modified C(++) compiler that works off of the parser or would it be closer to a LF compiler with not as much parsing involved?
* Do you think we will have even a chance at making a compiler better than MinGW/Cygwin/whatever? Because if not then I think there would be a huge speed lose in compiled LF programs. CornedBee, I'd like your thoughts as well, do you think its possible to write a more efficient compiler than MinGW, considering we don't really know what we are doing (except for Grivo)?
We still need to get some syntax nailed down. Girvo can only do so much until then. I would really like to see some more syntax converstions happen. I also don't want to be the only one converting them. You guys have way better ideas for the syntax than I do. CornedBee, I don't know if you want to take the time, but I think if you did a syntax conversion you would have some awesome stuff to contribute.
Syntax needs to be our main focus so we can assist Girvo in the parsing stuff.
It is certainly possible to write a better compiler than GCC. GCC is known to be rather slow in running, and to produce not the best output code, both in terms of size and speed. VC++ outperforms it in all three, under some circumstances by orders of magnitude. (A particularly complex C++ program that took 2 or 3 minutes to compile in VC++ took 30 minutes in GCC.)
On the other hand, GCC does have years of work, many people with lots of experience, and even the expert knowledge of AMD themselves behind it. In addition to that, while GCC doesn't produces the best code for i386, it still supports no less than 31 CPU architectures - and that's just the official back-ends.
So if you ask me whether it's possible in general, then yes, it is. Microsoft have done it. But if you ask me whether you can do it, consider, as eyeRmonkey said, that you run around like chickens with their heads cut off (OK, cruel analogy), then no, I don't think it's possible. To continue my analogy, even a blind chicken will find a corn eventually, but one without head can't pick it up.
And no, I have no wish to work out the syntax. That's because I don't give a damn about the syntax. If I were to design a language (and I'm playing with the though every now and then), I'd go a wholly different route. There would be no talk of parsers until after months of thinking and discussing.
And I'd look for a better place to do so than this forum.
Okay, yes I would like to put in the time commitment to help build this.
However, to even BEGIN to write the parser(/compiler) I would need the syntax/keywords. Without that I can't do anything.
If you were to ask me whether you could write your own C(++) compiler then no. Not without a LoT of experince in either ASM of Binary, or both! As no one here has any clue when it comes to writing compilers, I'd give that a no.
You see, even I am a rookie when it comes to writing parsers/compilers. I have only ever writen 1 language that worked. I would suggest that everyone involved in this project should join up to some newsgroups (comp.compilers for example) and look around for tutorials. Once everyone realises how difficult what you are asking to do is, then perhaps we could set more realistic goals.
-Girvo
CornedBee, that was a harsh way of stating things, but mostly true. You said yourself that this is a good learning experience, so theres no need to be so rude about us being unorganized.
Girvo911, I know you need syntax. That is what I am trying to work on. It is to very obvious that we should have ironed this out before doing anything else. We can't continue in any area until we have the syntax practically finalized.
Here is how I see things going from here on out now that we have you on board Girvo:
- Spend the next month or so nailing down syntax
- Get suggestions from many people on how they think the syntax should work
- Take our lead from many programming languages and combine the best features (which has been our goal all along).
- Possibly take a begginers VB tutorial and convert all code in it to LF
- Possibly find a list of all VB/C++ syntax rules and convert them 1 by 1 to LF
- Don't just make this a C++ clone. Research other langues (haskell, delphi, whatever) and use cool ideas from those and think up our own.
- After we have the syntax 99% finalized. Girvo can start working on the parser.
- We will target GCC for compilation
- Eventually we will put the parser, GCC, the IDE (and a seperate debugger?) into one nice clean package.
Girvo, I would really like to have you around to help us decide on the syntax, but if you just want to work on the parser (when we get there) thats fine.
I mistakenly thought that the syntax part of things would just "happen" as things progressed, but that is obviously not the case. As I've said all along, this is a learning experience. We take things as they come and try to plan for what we can.
I'd really appriciate all the input I can get on how we should decide on syntax. I think the most ideal situation would be to find a site like www.w3schools.com, but for VB/C++/haskell. That would give us a good tutorial and a good reference list of all commands and their usage. We could then take that and convert it to LightFusion in a systematic way. If anyone knows of anything like that please let us know.
For now I think I will get a list of VB keywords and write a bunch of small code samples using each keyword then convert that to LF. If someone could do the same in C++ or ANY other language that would be awesome.
Then we can move into converting library function syntax.
Does this sound like a good plan? Does anyone have any suggestions?
Could everyone please respond to all the questions I asked in this post instead of just the last one which seems to happen a lot?
I will gladly help with the syntax!
I do hope you all take up on my suggestion about learning compiler programming. Apart from being interesting, it would be very helpful for everyone (besides, its not that hard ;)).
-Girvo
While looking for tutorials that we could convert I think I ran across something better. Not only is it an awesome place to store your code snippets, but it have over 250 VB code snippets that we could convert to LightFusion. You can find it here:
http://www.garybeene.com/gbware/gbcodelib.htm
I'm going to start posting snippets and how I envision their translation. I still want other people to make suggestions and/or post their own conversion if they see it differently at all.
That seems promising.
Do you know much C/C++? Could you try and convert a simple app for me, so I can see what it looks like? Try this for example:
Code:#include <iostream>
using namespace std;
int main()
{
int aThing = 5;
int bThing = 10;
cout << aThing + bThing << "\n";
cout << bThing * aThing;
}
Ok people. I know it sucks that I don't have a computer for myself, not to mention I've been away every weekend to Cocoa Beach, but it's time I reveal some of the LightFusion syntax to you guys. If I have not finish posting, it means my father has kicked me off again. Anyways here we go:
Data Types
The data types in here are self explanitory. You might recognize some of them from the .NET framework such as System.UInt16, System.UInt32, etc.
Int8 - 8 bit signed integer
Int16 - 16 bit signed integer
Int32 - 32 bit signed integer
Int64 - 64 bit signed integer
UInt8 - 8 bit unsigned integer
UInt16 - 16 bit unsigned integer
UInt32 - 32 bit unsigned integer
UInt64 - 64 bit unsigned integer
Flt32 - 32 bit signed Float
Flt64 - 64 bit singed Float
UFlt32 - 32 bit unsigned Float
UFlt64 - 64 bit unsinged Float
Str - String
Char - Character (like C++)
Bool - Boolean
Ptr - Pointer
Variable Declaration
Basic Initialization
Initialization with a valueCode:Int32 MyVariable
Initialization of 1d ArrayCode:Int32 MyVariable = 5
Note that all 1d arrays begin at 0 and end one index less than what was declared. For example, an array with 10 elements like in the example will only go from 0-9.
Initialization of 1d Array with valuesCode:Int32 MyArray(10)
Initialization of 2d ArrayCode:Int32 MyArray(10) = {10, 20, 30, 40, 50, 60, 70, 80, 90, 100)
Code:Int32 MyArray(4)(4)
If Statements
Basic If statement
Notice the If is capitalized, and the if statement is similar to C++, only not needing the () around the expressionCode:If expression
{
//Block of code
}
One line If statement:
Yes one line If statements are supported:
If/ElseCode:If expression {//code goes here}
Similar to C++
Else IfCode:
If expression
{
//Execute block 1
}
Else
{
//Execute block 2
}
.......To be continuedCode:If expression
{
//Execute block 1
}
Else If expression
{
//Execute block 2
}
THere is a problem with your arrays. How is the compiler supposed to distinguish between a function that takes arguments and an array?
It's an integral constant expression for an array, and a type for a function.
I see a different problem. There is no meaningful, standard representation for unsigned floats. Kick them out, nobody needs them.
What the hell is "Ptr"? All pointers will be untyped? That points (if you'll excuse the lame pun) to disaster, if you ask me.
I'm not sure I see the point in having so many different versions of each Int/UInt. I mean sure, it allows you a little more control over how much memory you are using, which is a good thing, but if I was learning programming for the first time I would have no idea which ones to use. Integer and Long make a lot more sense to me. Plus, 32-bit (and soon 64-bit) will be the fastest for the processor to work with.
What about giving them more meaningful names. Then again, I don't like that idea either because that violates another rule to some degree (let the programmer know what the compiler is doing). I guess all the names aren't so bad. I guess I'm just commenting.
You mentioned If being capitalized... That shouldn't matter unless me make a case senseitive language, which I don't think we are going to do. That only works in VB because you have to write your code in VB. If we want people to be able to write code outside of our IDE then we might as well be case-insensitive.
You also said that there would be no ( ) 's around the expression. I totally disagree. I think those increase readability a lot and I think its more than worth the extra typing. I put ()'s around my VB if statements often to make them more readable.
... And back to semicolons. I truly think they need to be in here. I think Girvo has a lot of say in this one because he is going to be doing the parser (for a while at least). I can make the IDE do 95% of the work when it comes to semicolons (and other typing annoyances) so I don't see how it is a problem. It won't be hardly any extra typing. Once again, I want to hear what Girvo has to say on the subject.
PS - I hope you don't think that the syntax you posted is how it will be when the langauge is done (or even a month from now). You said you were "revealing" it to us as though it was final.
I like the datatypes Jake listed, they are nicely consistent.
edit: except for Str
I believe someone mentioned postfix increment operators previously. Will there be a defined behaviour for prefix/postfix increment/decrement operators, or will it be postfix only?
e.g.
Code:int32 b = 5;
a = ++b;
// a == 6, b == 6
// -------------------------
int32 b = 5;
a = b++;
// a == 5, b ==6
Worth viewing the thread for. LOL.Quote:
Originally Posted by penagate
chem
Definitely postfix and prefix as far as I am concerned. I loved being able to use them when declaring arrays in JavaScript:Quote:
Originally Posted by penagate
It allows for easy rearranging or inserting of array elements.Code:MyArray[++a] = "Hello"
MyArray[++a] = "Wonderful"
MyArray[++a] = "World"
I'm not sure what you mean. Probably because I don't understand pointers extremely well, but I get the general idea. What do you mean untyped?Quote:
Originally Posted by Penagate
Wouldn't unsigned floats allow more decimal accuracy/higher digit accuracy? Or am I missing something in the concept of how floats are stored?Quote:
Originally Posted by CornedBee
Whats wrong with Str? You think String is better?Quote:
Originally Posted by grilkip
Well if VB's compiler can do it, so can LightFusion's. ;)Quote:
Originally Posted by Girvo911
I like Str cause it's easy to type and goes with the 3 letter abreviations such as Int, Flt, Ptr, etc. It stays consistant.Quote:
Originally Posted by eyeRmonkey
You're missing that probably no FPU in existence supports unsigned floating point values, thus the single bit you gain in precision/range comes at great expense in performance, because you have to emulate the FPU.Quote:
Originally Posted by eyeRmonkey
Thanks. That is what I meant when I asked "Or am I missing something in the concept of how floats are stored?"Quote:
Originally Posted by CornedBee
Jake, will you have the rest of you syntax ideas ready? I really hope it won't take long.
What do you guys think about using () with If statements? Does it increase readablity for you guys or not?
I (am a C++ freak ;)) belive that ()'s with ifs make a lot of sense, and also contribute to human readability. I think that this language shouldn't be like other languages, and should be relativly easy for a non-programmer to read.
Also, the point of having 8/16 bit Int's is what? Really, no one uses anything like that nowdays, and is just adding to complexity. Also, I think that the arrays should use a different sort of brakcet, maby []'s, so it is easy to distinguish, for the reader as well as the parser.
-Girvo
I agree Girvo. Arrays sould be [].
I also agree about 8 and 16 bit integers. Unless someone (CornedBee?) can make a good argument for them being included. 32 bit is useful now and 64 bit will be useful when 64bit processors come out and for larger numbers. I like having signed and unsigned though.
I intend on having something similar to the Object Browser in VB, but for the LF IDE. It will have info on all the variable types on syntax keywords and stuff (instead of opening the help file). The reason I mention that is because I can never remember the max and min for signed and unsigned integers (-32,000ish to 32,000ish for 16 bit or something like that?). The object browser (in LF) will make things really easy to work with, except I'd like to name it something else.
PS - Nice signature quote. ;)
1) Binary structure layout. Many file formats use 8-bit or 16-bit integers in their formats to preserve space. If you have such data types in the language, you can make data structures that directly map to these formats. On the other hand, padding and endian issues have made such code non-portable by default, which could make this a non-issue, if you want to insist in people reading this stuff byte by byte (as I do anyway).
2) Binary compatibility to other languages. What about that WinAPI struct? Should it be usable from within LF? Then you better have those datatypes available. Just think of all the trouble the lack of support for unsigned types has caused VB when trying to use the WinAPI. Now take this trouble and multiply it by a thousand. We're talking about "impossible" instead of "extremely bothersome" here.
3) Space. Believe it or not, when you want sixty thousand addressable small numbers, there IS a difference between that array taking up 60k or 240k. Especially in caches: 60k will fit into the L1 data cache of some CPUs (many have only 32k), 240k will not. And that means a L2 cache access (could be up to 10 times slower) or even a main memory access (another power of ten).
4) Constraints. It's just incredibly useful to know that my byte type will never store any value larger than 255, and that I'm guaranteed not to have data loss when I write it to a single byte in a file, and that when I create the mask FLAGALL & ~FLAGWHEE & ~FLAGFOO (where FLAGALL is defined as -1) and apply this to my variable and test the result, I won't get false trues because the 22nd bit was set.
I think I could come up with one or two more.