LightFusion™

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.

Quote:

---

Originally Posted by penagate

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.

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.

Quote:

---

Originally Posted by Girvo911

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 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?

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?

Quote:

---

Originally Posted by penagate

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.

---

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 eyermonkey

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?

Could you write a small pro/con list so we can seriously consider wether its worth it or not?

---

PROS:
-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

Quote:

---

-It would be eisier to implement libraries, as I am not sure how to do it using lex and yacc.

---

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.

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

Code:

---

Int32 MyVariable

---

Initialization with a value

Code:

---

Int32 MyVariable = 5

---

Initialization of 1d Array

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.

Code:

---

Int32 MyArray(10)

---

Initialization of 1d Array with values

Code:

---

Int32 MyArray(10) = {10, 20, 30, 40, 50, 60, 70, 80, 90, 100)

---

Initialization of 2d Array

Code:

---

Int32 MyArray(4)(4)

---

If Statements

Basic If statement

Code:

---

If expression
{
//Block of code
}

---

Notice the If is capitalized, and the if statement is similar to C++, only not needing the () around the expression

One line If statement:

Yes one line If statements are supported:

Code:

---

If expression {//code goes here}

---

If/Else

Similar to C++

Code:

---


If expression
{
//Execute block 1
}
Else
{
//Execute block 2
}

---

Else If

Code:

---

If expression
{
//Execute block 1
}
Else If expression
{
//Execute block 2
}

---

.......To be continued

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

---

Quote:

---

Originally Posted by penagate

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.

---

Worth viewing the thread for. LOL.

chem

Quote:

---

Originally Posted by penagate

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

---

---

Definitely postfix and prefix as far as I am concerned. I loved being able to use them when declaring arrays in JavaScript:

Code:

---

MyArray[++a] = "Hello"
MyArray[++a] = "Wonderful"
MyArray[++a] = "World"

---

It allows for easy rearranging or inserting of array elements.

Quote:

---

Originally Posted by Penagate

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 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 CornedBee

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.

---

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 grilkip

I like the datatypes Jake listed, they are nicely consistent.

edit: except for Str

---

Whats wrong with Str? You think String is better?

Quote:

---

Originally Posted by Girvo911

THere is a problem with your arrays. How is the compiler supposed to distinguish between a function that takes arguments and an array?

---

Well if VB's compiler can do it, so can LightFusion's. ;)

Quote:

---

Originally Posted by eyeRmonkey

Whats wrong with Str? You think String is better?

---

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

Or am I missing something in the concept of how floats are stored?

---

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 CornedBee

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.

---

Thanks. That is what I meant when I asked "Or am I missing something in the concept of how floats are stored?"


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.