So none of you want an exponent operator then, right?
Printable View
So none of you want an exponent operator then, right?
I'm pathetic. I even made a spell check app that runs from the system tray that uses RD's MS Word spell checker module and I don't even use it. All it requires is 1 click or even just a hover. I suck. :thumb: :DQuote:
Originally Posted by chemicalNova
I think so. You might want to hear what penagate has to say and I don't think chem has said anything 1 way or the other yet.Quote:
Originally Posted by Jacob Roman
Can we start nailing down a rough list of rules to follow as we go?
Aims:
C++ makes programming more enjoyable for serious programmers.
C++ is a general-purpose programming language that
- is a better C
- supports data abstraction
- supports object-oriented programming
General rules:
C++'s evolution must be driven by real problems.
Don't get involved in a sterile quest for perfection.
C++ must be useful now.
Every feature must have a reasonably obvious implementation.
Always provide a transition path.
C++ is a language, not a complete system.
Provide comprehensive support for each supported style.
Don't try to force people.
Design support rules:
Support sound design notions.
Provide facilities for program organization.
Say what you mean.
All features must be affordable.
It is more important to allow a useful feature than to prevent every misuse.
Support composition of software from separately developed parts.
Language-technical rules:
No implicit violations of the static type system.
Provide as good support for user-defined types as for built-in types.
Locality is good.
Avoid order dependencies.
If in doubt, pick the variant of a feature that is easiest to teach.
Syntax matters (often in perverse ways).
Low-level programming support rules:
Use traditional (dumb) linkers.
No gratuitous incompatibilities with C.
Leave no room for a lower-level language below C++ (except assembler).
What you don't use, you don't pay for (zero-overhead rule).
If in doubt, provide means for manual control.
I think you have even more work ahead of you if you make tons of processor specific optimizations. Obviously that would be the fastest, but you really should save a lot of that for the end because if you put to much of a load on yourself now, you might feel like giving up and then nothing will come of all this work.
Ok let's do it. I will go one step at a time though since I don't wanna spend an hour finishing up a post.
Aims:
To make LightFusion easy to program, easy to learn, easy to make standard windows applications, and have easy to read syntax without lacking in the speed of execution.
LightFusion will support Object Oriented programming, as well as standard programming.
LightFusion will make programming enjoyable for everyone who uses it.
LightFusion will have features many other languages were lacking in.
LightFusion will combine the popular syntax from languages such as Visual Basic, C++, and Assembly, plus some originality.
It's late at night here in Florida, so that's all I can think of for now.
Agreement from me (I thought of saying yes or no, but then, confusing occured). No exponent operator.Quote:
Originally Posted by Jacob Roman
Perhaps that could be changed to:Quote:
Originally Posted by Jacob Roman
"LightFusion will combine the popular features of languages such as Visual Basic (and) C++ (, and Assembly)" :bigyello:
The brackets are for whatever you guys have decided on. I still think some of the syntax would be better with some Pascal influence :D
chem
Can you link us to a list of Pascal syntax rules? I know nothing about it.
Have you tried MSDN?
No. I was hoping chem would have a good link because he has suggested Pascal syntax a few times.Quote:
Originally Posted by Jacob Roman
Here is the .chm (Compiled Help Machanism) that I have made so far. Look at the entry called Template and tell me what you think. I made it look a lot like MSDN. Can you guys think of anything else I should add?
EDIT: .CHM attachment removed because newer versions are available
Pascal is basically Delphi. Theres Windows Pascal stuff, but for Windoez, apparently its recommended to use Delphi.
http://www.marcocantu.com/epascal/English/ch02code.htm
Thats just a slight tutorial on comments, variable declaration, and such with Pascal.
I don't mean convert your entire syntax to look like Pascal/Delphi, I mearly suggested parts of the syntax might make it interesting taken from them :D
chem
The !! stuff makes it hard to understand. They mean anything? Or just a side-effect of the compiler you used to make it? :eek:
chem
Personally I reckon stick with operators for single opcodes only, like I posted before. That way you know exactly what your operators compile to. Leave the rest for functions. So no exponent operator.
I disagree with this quote from the C++ guidelines.
C++'s very failure to focus on preventing misuse has led to the thousands of security problems that OS's and software face today. Buffer overruns anyone? In this day and age security should take precedence over powerful features. And if you can combine the two, then all the better.Quote:
It is more important to allow a useful feature than to prevent every misuse.
I forgot to mention that you can right-click and click view-source.Quote:
Originally Posted by chemicalNova
Anything in [!!Blah] format means you need to replace that with its actual value. Do you have a better format I can use?
Other than that does it look good? Font-size, positions, are there enough fields?
What do you think of it Jake? Penagate?
I really like the idea of operators for single opcodes only which just gave me the idea of a new rule for LF (I don't know what category it would fall under:Quote:
Originally Posted by penagate
The syntax and overall feel of the language should make it easy to know what the compiler is doing
I think this is an awesome rule because it allows our users to make fast programs with our (hopefully) fast language.
GCC is the GNU Compiler Collection, which consists of GCC, the GNU C Compiler, G++, the GNU C++ compiler, GCJ, the GNU Compiler for Java, GF77, the GNU compiler for Fortran 77, and a few others. Originally developed for UNIX-like system, it is THE compiler for all things Linux, but has also been ported to Win32, where it's available as part of either the Cygwin or MinGW packages.
I disagree with you. A language should offer safe facilities, but should not force you to use them. Doing so limits the range of application, because you can no longer use the language for applications where you cannot afford the security overhead, like stuff for embedded devices, or device drivers that have to respond really fast.Quote:
I disagree with this quote from the C++ guidelines.
In C++, you can always use vector::at instead of [] if there's any chance for a buffer overflow.
Of course, but my point is, it is so easy to cause an overrun in the first place it's not funny. Microsoft themselves program in C++ and look at the state of their software. Seemingly every bug that crops up allows "hackers to gain control of your PC" etc. etc. Plus, what is the security overhead. Two extra instructions? I don't think that's a stretch compared to what you could lose by not providing that security.Quote:
Originally Posted by CornedBee
A branch, which is a serious slowdown.Quote:
Two extra instructions? I don't think that's a stretch compared to what you could lose by not providing that security.
And the necessity of keeping the array dimension with the array, which complicates layout and can consume unnecessary memory. We're talking embedded devices here.
And quite frankly, I'm just not ready to blame a language for the incompetence of the programmer. Buffer overflows are the result of lazyness, nothing else.
The simplest, most intuitive, and natural thing to do, in C/C++, is to use an array as an array, not a method of addressing memory. Until you know what is going on under the hood you don't think about buffer overruns; after all, in the context of an array, it doesn't make any sense! It's only once you know that an array is implemented as a start pointer and a fixed offset per element, with boundary checking needing extra code, that you see why you can overflow it at all.
Thinking about it a bit more I don't think simple arrays should be provided as a feature of the language at all. If you want one you can implement it yourself, so you know what's going on and understand what you have to do to make it safe, or have the freedom to code it as unsafe but more efficient. Done properly, this wouldn't incur any overhead over providing it as a language feature, as it could be compiled as if it were part of the language, and some safe (and unsafe) implementations should be included in the standard library.
Wrong. You cannot portably implement stack-based arrays without the built-in arrays in C++.
Sure not in C++ but if you provide the facility to stack allocate variables in a language then you can design your own array implementation.
I know I'm butting in a little . . .
I know the devil's in the details . . . .
But start from the real basics: ie: sequence,selection, and iteration once you've nailed those - you have a programming language
All three of those,together, semantically describe all programming languages.
Once you've worked out the syntax, and the machine representation of those you can then work on context, and extending the language to cover the expert domain in which you are targetting the thing to.
My last hint is that you only have a limited number of registers on which to optimise: I would really look into the graph colouring theories . . .
(Sorry for butting in . . . )
This thread has got to be a joke.
If its not I bet none of you can walk and chew gum at the same time.
Believe me, it is no joke, Glen. I'm even ordering a book that tells you how to make your own language and compiler for Windows using C++.
Penagate, are you honestly suggesting to not have arrays as part of LF? Once again, my knowledge is lacking when it comes to arrays beyond the simple stuff (a pointer the start of the array and each element is n bits long), but to force the user to redesign array implimentation each time is crazy in my opinion.
Maybe you could talk me into it if I understood it a little better, but not having arrays seems a little too extereme to me (unless I misunderstood you).
I decided to start writing down ideas for LF that I have while at school because I always forget them. Here is my idea for the day.
IDEA: I notice a lot of VB6 threads are about parsing. Maybe we could add some functionality to LF that helps with the basics of parsing, such as replacing a section the string with something else without an InStr, Mid and then joining everything back together in the right spots with Right() and Left().
You misunderstood. We were arguing range-checked arrays vs unchecked arrays. I argued that the built-in array should be unchecked since that's faster, and writing a range-checked wrapper is trivial. He argued that the built-in array should be range-checked since it's safer, and that the language should provide additional facilities for stack allocation so that it would be possible to write a fast, unchecked implementation.Quote:
Originally Posted by eyeRmonkey
IDEA: Add an option to automatically apply XP themes to any program (not sure if this is already an option in VB.NET).
Okay, I think I get it now. Thanks.Quote:
Originally Posted by CornedBee
I think it might be possible to both. Obviously one of our goals is speed so we want to leave unsafe arrays as an option that is supported by the language and the compiler.
Safe arrays might be good too (as a separte way of doing things and have its own syntax/declaration).
Jake, feel free to let out any ideas you have been throwing around in your head. Post them here and I can document them because I am starting separate .docs for the following categories:
- IDE
- Syntax (we can combine ours at some point)
- Compiler
- General
- Misc
(Am I forgetting any)?
Also, has anyone had time to check out the .chm I posted?
My book came in!!!!!!! w00t!!!! :bigyello: I got it with me right now. And it does teach you the correct method to making your own programming language and compiler, step by step!
Read the intro and foreword. :)
One important question: What ASM compiler does it want you to use?
I see you added the logo to the first page. I haven't seen that before. If you want to print the page, it will show up.
You need a startup page, which is linked to the HOME button. Right now it is the first item.
Also, noticed that the authors were left out.
Nice start, though.
Thanks dglienna. :) I know I need all that, I was asking mostly about the position/size of the window and the format of the "Library Syntax" template. Is everything on that template that needs to be for it to be useful?
I have, template looks great :p. I just looked at PHP manual, a nice addition they have is "See Also", it lists the syntax that are similar or related to that single syntax. Also you should have under the sample what it would output (if any).Quote:
Originally Posted by eyeRmonkey
Prehaps the library the syntax is included in?
For Borland C++, they suggest Borland Turbo Assembler, and for Visual C++, they suggest Microsoft's Quick Assembler. But since ASM can already be done in C++, we can use that instead. It just needs something to use the 8086 assembly language, which is the x86 instruction set.Quote:
Originally Posted by eyeRmonkey
Okay, my main point on this subject is we need to use an ASM compiler that we can re-distribute from the beggining. I think the is very cirical. We can't redistrubure C++ so I say we use a GNU compiler. Its easy to say that the instruction set is the same, but I know there will be problems when porting it to a free compiler if we wait until the end. So I say we use a free (re-distributable) compiler from the beggining? Do you agree?Quote:
Originally Posted by Jacob Roman
IDEA: Make the IDE clean and simple like firefox
IDEA: Same goes for the options dialog box
IDEA: Make many many options. Anything that someone might want to change, lets make it optional. But also keep the options dialog form very clean and easy to understand.
Jake (this goes out to Penagate and chem too), I want to mention a point that I hope you remember as we go along with things. Please post everything you do, and often. We might need a file host to hold everything (I have no idea where), but I would like to see progress often and not just for my sake, but for the sake of this being documented and the open-source part of it and so that I can learn from stuff (and hopefully others can too).
Example: I don't want to find out Penagate has mad 50 library functions and not posted the code or what they are about or got our opinions. I think we should hash each one out 1 by 1 and go back and review them later for extra optimizations.
I will do my best to post all the work I do and I hope you guys will do the same.
Thanks for the reply, I sometimes feel like no one reads my replys.Quote:
Originally Posted by k1ll3rdr4g0n
The See Also thing is actually an ActiveX control. I think I will do that after a while, but it isn't all that simple and I have to do it (because I have the program) where as anyone can use that HTML template if they make a function.
I also want to add links in all the topics form 1 topic to another. But I think that is a job for the very end.
Having a section for output is a great idea. Thanks. :thumb:
If you really mean that then the joke is on you. It takes about one semester (when I was at university) to write a C compiler.Quote:
Originally Posted by GlenW
It's not that hard, really.
Thank you GlenW for your constructive input.
eyeRmonkey, I am not going to write very many library functions at all until we sort out some more aspects of the language. I've already made the assumpition we will use wide strings and there were some other things that I can't remember right now. I'll check out your .chm file in a moment.
Jacob, I thought your compiler was going to be an assembler also? wouldn't be very hard at all (just a bit of work adding all the instruction sets).
have you all seen this yet? http://www.vbforums.com/showthread.p...35#post2167435
although not in english, you may find this useful
TIP: design the compiler to consist of a back end and a front end, which communicate some abstract language representation. The front end parses the source, the back end generates the assembly. This is the way every other compiler works, and it lets you, for example, relatively easily port the thing to other platforms, or simply to a different assembler. It also allows you to write, should you ever want such a thing, a late-code-generating linker, which is the requirement for global program optimizations such as what the newer versions of VC++ do.
I wonder if chem is gonna get a compiler book as well. Would be nice to have two books that will help lead us in the right direction.
Funny you should say that JR. Yesterday I ordered an ASM book and then a few hours later MrPolite recommended an ASM book ... the same one! How spooky is that?
Does your compiler book give you all the different EXE formats? There are about 6 different kinds if memory serves me.
I could try Jacob, but since I don't work (being 16 and all), I'm not too sure.
Maybe order one off the internet for cheap.
chem
I'd like to order a compiler book too but I don't have time to read it and stuff. I barely have time to learn ASM and do the library functions.
Penagate, can you explain the difference between wide strings and BSTR? I never got around to reading the link you posted. Maybe I'll do that now. I think our choice on strings will be very important, especially when it comes to making the string libraries.
BSTR is just a special form of a wide string, one that stores the length in the word before the start AND is 0-terminated.
The string libraries should work on everything out of mere principle.
What are the advantages/dis-advantages of each?
Right now it seems that there are only two in the book I got. Interpreted and Compiled. But it helps a lot in scanning, parsing, and many other things. It's mostly code rather than theory, and they are using C++ to compile Pascal files as an example throughout the book, and can be changed into any language you want, even the ones you invented. I may need to go to the library or a book store and see what else I can find.Quote:
Originally Posted by wossname
So are you saying the book doesn't have everything we need?
Things I am currently working on:
Finding a good program to make help files in. The one by microsoft is complicated and there are other free ones out there.
Some editors let you edit text in a RTB editor and it produces the HTML and compiles it all for you (WYSIWG editor). I think I might go that direction to avoid the HTML/CSS hassle, but I don't know if the programs I am looking at allow stylesheets (which would save more time in the long run.
No, but it has a lot to get us started. And it has become a big help for me so far. The book was made back in '96, but should suffice for now until we need to add certain things.Quote:
Originally Posted by eyeRmonkey
EXE formats, as in a.out, coff, DOS, DOS-COM, PE/Win32, PE/OS2, elf and others - most OSs have their own, although elf is quite omnipresent in the Unix world lately.
Interpreted vs compiled is something entirely different.
Ok I've done quite a bit of reading so far, and decided to skim through the book. I think the compiler only compiles to .obj files. But I see nothing on having the .obj files converting into an exe. I may have to buy another book to see how it's made into a win32 or DOS exe. At least the book is gonna help me a great deal on everything else.
After I finish documenting as much as I can I want to put the focus back on the lists that CornedBee brought up.
You use a linker to make an exe out of .obj files.
That is the standard build process.
Source - [Compiler] - > (Multiple) OBJ files - [Linker] - > Single EXE/DLL/etc. file.
There are a wide variety of linkers around. Don't feel that you have to create one yourself. You could use the one that comes with VB6, or VC++.
Or the one that comes with the free MS toolkit.
does gcc include a linker?
It would have to. I haven't used it before, but doesn't it result in EXE's? If so, the linker is there..
chem