LightFusion™

Quote:

---

Originally Posted by Jacob Roman

I did it for you. So far I didn't see anything to restrict us from doing so.

---

I said I already did that, not that I needed you to. But thanks anyways. :)

Maybe we can redistribute it ... and I quote:

Quote:

---

Originally Posted by EULA

11.SOFTWARE TRANSFER. The initial user of the Software may make a one-time permanent transfer of this EULA and Software to another end user, provided the initial user retains no copies of the Software. This transfer must include all of the Software (including all component parts, the media and printed materials, any upgrades to this EULA, and, if applicable, the Certificate of Authenticity). The transfer may not be an indirect transfer, such as a consignment. Prior to the transfer, the end user receiving the Software must agree to all the EULA terms.

---

You can't. The toolkit is not re-distributable.

Well that clears that up. Can you quote what part that makes you say that cornedbee (although I'm sure you are right)?

According to that, it is redistributable, cornedbee. There was nothing in there that restricted us from doing so, and it says we are allowed to redistrubute it.

Nowhere does it say we can redistribute it (except kind of in that quote I posted). The only thing it says you can redistribute is the code listed in REDIS.txt (which says you can't redistribute any code).

So its still undecided.

Quote:

---

The initial user of the Software may make a one-time permanent transfer of this EULA and Software to another end user, provided the initial user retains no copies of the Software.

---

I believe this is quite explicit. The only way you're allowed to give any part of the toolkit to someone else is if you are giving it completely away, not leaving anything for you. It's like when you re-sell a book. You're not allowed to make a copy first.

Yeah. I was going to bring that up. I was thinking about it while I was out and about earlier today and that was the part that stuck out in my mind. I agree.

I think we should translate LF into MASM because it allows the most ease of use. The macros are awesome from what I have seen so far.

What's the point of outputting inline ASM wrapped in C++? Why not just output C++? Then we are effectively building a C++ macro language. A proper compiler will either output ASM or object files. What's it gonna be?

Quote:

---

Originally Posted by penagate

What's the point of outputting inline ASM wrapped in C++? Why not just output C++? Then we are effectively building a C++ macro language. A proper compiler will either output ASM or object files. What's it gonna be?

---

Well it's just an idea, penagate, incase we cannot get a decent compiler going on our own. The point is, is that when we have code to convert LF code to C++ (with some of it outputing inline ASM), the compiler and linker for C++ files can do the work for us, thus making it easy to make win32 and dos exes. And C++'s inline asm supports SSE and SSE2 instructions, so we can have lighting speed executed code going. Not all of it is gonna output asm, such as the win32 stuff. Mainly the math fuctions and operators, posibly more.

Quote:

---

Originally Posted by Jacob Roman

Well it's just an idea, penagate, incase we cannot get a decent compiler going on our own. The point is, is that when we have code to convert LF code to C++ (with some of it outputing inline ASM), the compiler and linker for C++ files can do the work for us, thus making it easy to make win32 and dos exes. And C++'s inline asm supports SSE and SSE2 instructions, so we can have lighting speed executed code going. Not all of it is gonna output asm, such as the win32 stuff. Mainly the math fuctions and operators, posibly more.

---

(see bolded part of quote) Jake, how do you intend on finding a compiler and linker for C++ that we can redistribute?

You need to seriously consider using MASM or some other ASM to output LF into.

I have a few points to bring up Jake:

1) I don't think you should try to make the IDE and compiler by yourself. I know you want to have control over this project (or at least that is the feeling I am getting from you), but you need to let us help you and work as a team. If you do both of those parts then that doesn't leave the rest of us much to do until much later on. I think it would be better if (chem/penagate) and I do the IDE in VB6. That also lets you focus totally on the compiler and make it as fast as possible. I think you are spreading youself too thin by trying to do both.

2) We need to make a decision about how we are going to pre-compile/compile LightFusion. I think the C++/ASM idea is out the window because we have no way to impliment it unless you want to force the user to DL the toolkit, but then all future versions of LF will be dependent on the toolkit and I'm not sure I like that. My vote goes to MASM. Whatever decision we make, we need to make it soon, because I want to read a tutorial that is geared towards that ASM. I know the instruction set is always the same, but the rest is always different.


Also, please skim over the last page and this page and reply to some of the stuff I have brought up that you missed. I would appriciate it. Thanks.

:)

May I add that I think it's a bad idea to write an IDE now at all? You should focus on designing the language and writing a compiler for it. You can write the code in some other editor for now. The compiler should be called from the command line.

Adding to what CornedBee said,

I think this project has a sort of "VB" air to it. I don't actually like the sortof-integrated IDE/compiler model at all. They should be totally independent components.

It could be a 2-step or 3-step compilation process:

2 step: Compiler -> Linker
3 step: Compiler -> Assembler -> Linker

Up to you guys. 3 step is easier I'd say.

That sounds good to me. But at the moment Jake is doing most of the work and hasn't been able to reply to this thread much the last couple days, so I don't know what to say.

I agree that we should skip the IDE step for now, but we can't force Jake to stop working on it if he wants to. But even if he is working on it then they should still be totally separate components.


PS - Does anyone know if its possible to write a custom control in VB and use it in C++?

Yes it is. You use it like any other ActiveX control. That is, you hate MS for ever inventing the technology ;)

Oh brother.... COM in C++.... :sick:

COM? Whats that?

Is it possible to use/reference a .OCX (ActiveX control) in C++?

COM is the basis of ActiveX.

So is the answer yes? Are you saying that you can use COM in C++ to access a .OCX?

And yes. But pretty much you have to do what VB does for you.

What do you mean?

All the behind-the-scenes COM object referencing, instanciation, code etc.

What do you need it for?

That means that using ActiveX control requires lots of code from you in C++. VB already has that code.

Desiging the IDE is pretty much cake, so I don't see why I shouldn't be working on it with everything else. I'll upload the source code to it soon (possibly this week) and allow others to work on it. At the same time, I've been designing the syntax. But since I have a difficult time getting on the computer cause of family and all using it, I've been writing it in a notepad with a pencil. I will share it with everyone as soon as I have the time to get on and type all my notes from the notepad into the computer.

And I don't wanna worry about writing a compiler/linker just yet until I successfully designed the syntax, and have written a decent scanner/parser. Lets focus on one thing at a time here, as a team. ;)

Quote:

---

Originally Posted by eyeRmonkey

Jake, does you book bypass the ASM translation part in a sense? I mean does it each you to parse the languge you make and output directly to obj files which are fed into a linker?

---

The scanning and parsing is all done in C++. The compiling is a blend of C++ and asm in the book I got.

Quote:

---

Originally Posted by eyeRmonkey

Here is what we have so far as "The Rules":

Aims:
* LightFusion will be easy to learn and make standard windows applications without lacking in speed of execution.
* LightFusion will make programming enjoyable for anyone who uses it.
* LightFusion will combine the popular features of languages such as Visual Basic and C++ and add features that seem to be lacking from those languages.

General Rules:
* Always make what the compiler is doing obvious to the programmer (through the syntax, documentation, features, etc) without confusing things too much.
* Don't force the programmer.
* Every feature must have a reasonably obvious implementation.

Design Support Rules:
* Support composition of software from separately developed parts.
* Support common programmer styles.
* Support program organization and readability.

Language/Technical Rules:
* Use features/syntax from other languages unless there is a good reason not to.
* When in doubt, pick a solution that is easiest to teach and displays what the compiler is doing.


What do you think should changed/added/removed?


My 2 cents:

I think this rule "Always make what the compiler is doing obvious to the programmer (through the syntax, documentation, features, etc) without confusing things too much." is the most important (and not just because I thought of it).

The reason I say that is because no matter how much work we put into making a good compiler and no matter how much we optimize things, a huge ammount of the burden of speed is on the programmer. I think that if we do our best to let the programmer know what is fastest for each situation then LightFusion programs will be turn out faster on average.

I think this needs to be done through the syntax and the naming of library functions mainly. If we just do it through documentation and features (such as allowing the programmer to edit the ASM before it is sent to the assembler) then those things can be ignored. But if we play our cards right, then the user will HAVE to know what is faster BECAUSE they know the language. Here is a (poor) example of what I mean:

Code:

---

Fast1LineIf a = 1 : Call MySub()
SlowMultiLineIf b = 10 {
    c = a * b
    Call MySub1(c)
}

---

This is obviously a horrible example, but I can't think of a better way to illustrate my point because I have never seen this done in a programming language before. My might sacrafice some use-ablity in the process, but it might be worth it.

This may, on the other hand, be a bad idea. Because all our users may not be interested in speed and it may make the language harder to use/read. We could just offer features (like editing the ASM) for the users who WANT fast apps.

What do you guys think?

---

I think the one line If statement function (IIF(), not the other one line if) should use the same asm code as a real one line if statement.

Ideas:

Variables:

- Select heap, stack, or register (if possible) allocation when declaring variables.

- Directive sets stack size and allocation defaults

- No String type. String should be a class.

- Types should include (at least):

Code:

---

char
short, ushort
word (32/64 bits)
long, ulong
dword, long64, ulong64
float (single)
double

---

- Should be support for creating your own types.


Structs:

- Allow shorthand declaration syntax

Code:

---

struct RECT { long Left, Top, Right, Bottom }

---

- Allow methods and operators in structs

- Structs have implicit (assumed but undefined) constructors, e.g.

Code:

---

RECT rc = new RECT(10, 4, 5, 8);
// instantiates a new RECT structure with left=10, top=4, right=5, bottom=8

---

Procedures

- Instantiation of procedures

Code:

---

void SomeProc(long arg1, arg2)
{
    // do something
}

SomeProc myProcInstance = new SomeProc();

// I had a good use for this earlier, but I forgot :(

---

- Dynamic code modification

- [Conditional] redirection without an extra call

- Built in support for thunks


Syntax ideas:
(Thought of most of these ages ago)

- Conditional expression validation

Code:

---

(assignment expression) = (test expression)
// e.g.
(x = 5) = (y = 9);

---

- Multiple specification

Code:

---

a, b, c, d = 5;

if (a, b, c, d = 10) {
    a, b = 5;
    c, d = 7;
}

---

- Combined assignment and testing:

Code:

---

if (a -> b = 5) { ... }

// instead of
b = a;
if (b = 5) { ... }

---

- Interface specification when accessing methods with multiple implementations

Code:

---

Bear MyBear = new Bear();
// Bear has 2 implementations of Sleep(),
// one from interface IAnimal and one from IMammal:
MyBear(IAnimal).Sleep();
MyBear(IMammal).Sleep();
// two different results

---

Code example:

Code:

---

word fastcall Exponent(register num, register exp)
{
    switch (exp) {
        case 0:
            return 1;
        case 1:
            return num;
        case else:
            for (register i=exp-1; i==1; --i) {
                Exponent *= exp;
            }
    }
}

---

Very nice, penagate. I had some of that written down already, but you pretty much had some things that I didn't. I'll add that to the current syntax I got. When I get it all typed in a Word doc, I'll upload it and share it with the team, and we can debate or make suggestions on how it should be then.

Quote:

---

Originally Posted by penagate

- Combined assignment and testing:

Code:

---

if (a -> b = 5) { ... }

// instead of
b = a;
if (b = 5) { ... }

---

---

Hey, thats nice.

chem

Quote:

---

- Dynamic code modification

---

You do realize that this effectively means including the compiler in each program that uses this feature, right?

Awesome ideas penagate.

Jake, since I have nothing to do at the moment I was thinking of making a custom control in VB6 that you could plug into the the IDE. The control would be an RTB that allows easy syntax coloring and has added events (like for returning what word was right-clicked/double-clicked).

It won't be tailored directly to LF, but it will have all the features we need (that way I can submit it to the code-bank when I am done.

Jake, the only question I have for you is will you use it?

Create it, and lets see what it's all about. I'm curious to see this control myself. Be sure it's got a Treeview with the [+] and [-] to open and close code sections of sub routines like VB.NET has. That would be awesome.

Also, be sure to add this, if possible. This is just an idea, but I would like user created subs/functions be colored whenever typed and used as a link so when a person clicks on it, it will jump right where the sub/function has been created. That way there people don't have to waste time searching for the sub/function, and makes it user friendly.

Quote:

---

Originally Posted by Jacob Roman

Create it, and lets see what it's all about. I'm curious to see this control myself. Be sure it's got a Treeview with the [+] and [-] to open and close code sections of sub routines like VB.NET has. That would be awesome.

---

That is on the list of To Do's, but I can't do that until I figure out a way of letting the user (of the control - IE: You) define what starts and ends a code block. I want this to be a general purpose control unless I have no other way of doing things.

Quote:

---

Originally Posted by Jacob Roman

Also, be sure to add this, if possible. This is just an idea, but I would like user created subs/functions be colored whenever typed and used as a link so when a person clicks on it, it will jump right where the sub/function has been created. That way there people don't have to waste time searching for the sub/function, and makes it user friendly.

---

That won't be part of the control it's self, but there will be events and methods that let you do that very easily.

I want to code an event that will return the word that was right-clicked/double-clicked on. Then you you could use a method that I suppy with it to move to the proper line easily.

Quote:

---

Originally Posted by CornedBee

You do realize that this effectively means including the compiler in each program that uses this feature, right?

---

An unfortunately good point that I hadn't thought of.

Collapsable blocks would just be { and } ;)

And #region ... #endregion if you want to add that too.

{ and } wouldn't work if I wanted to make it general purpose (VB does things differently), but I have decided to tailor it to LF specifically. I am actually not going to start from scratch.

JA provided me with a custom control called CodeSense that I plan to extend for use with lightfusion. It already has most of the features we need, but I can add the few that are sitll missing.

Check out Notepad++. It's free and I use it all the time as a Notepad replacement (and for a lot of coding). It has customisable lists for folder open and folder close keywords. If you want to make the control truly adaptable then I suggest go that route ;)

Niggle which I just noticed now since I'm not on my own computer: The braces { } and brackets ( ) look very similiar in Courier New. I never noticed that before since I have all my fixed-width fonts set to Lucida Console, which I vastly prefer. Just something to consider for those making the IDE :)

I noticed it to about 8 pages back what I was suggesting using them for instring variables.

Pfft. You're blind pena :p Sifn't be able to tell the difference :)

I've always had Courier New for every type of programming I've done, even for those that default to something else (like FixedSys for MASM). Perhaps the ability to change fonts and the colour each keyword is highlighted is in order :)

chem