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).