Aurora is still in its infancy, but supports a syntax similar to C with higher level concepts.
Example syntax:
#typedef uint unsigned int;
#typedef pointer uint;
a=100;
while a > 0
{
a--;
}
uint b;
b = 0xffff;
do
{
b++;
}until b=0xffff00ff;
a = rnd(3);
select a
{
case 0:
b=88;
case 1:
b=99;
case 2:
b=111;
}
The design of the IF statement slightly differs from either C or BASIC. THEN has been eliminated and since lines are terminated with the ';' character a single line IF can be split up. For example:
IF (a > 100) b=2 else b=3;
IF (a > 100)
b=2
else
b=3;
The parenthesis are optional and are included for readability. The compiler also accepts:
IF a > 100
b=2
ELSE
b=3;
The important thing to remember when using a single line IF statement is that the semicolon marks the end of the line in Aurora instead of a newline character like in BASIC.
A structured IF statement uses brackets
IF a > 100
{
b=2;
c="cat";
}
ELSE
{
b=3;
c="dog";
}
Looking good. Actually looks pretty cool! ;) I like the semi colon termination
The semicolon is used in a lot of languages. The biggest problem with BASIC like languages is the reliance on the newline character as a line terminator. Which makes it hard to parse, and hard to continue a statement on separate text editor lines.
Aurora supports the same array loading as IBasic did, and the difference is obvious:
int a[20];
a= 1,2,3,4,5,
6,7,8,9,10,
11,12,13,14,15,
16,17,18,19,20;
Yes, that is nice. It is also a better visual marker for us programming challenged types. :)
Feel free to post any suggestions. Things you would like to see in the core language, etc.
I'll put my thinking cap on right now. This will be fun. :)
OK. Got IF working the way I wanted finally. Parsing all of the variations of IF was a pain :o I wanted to be able to combine a single line ELSE with an IF block like you can in C....took a bit of convincing the lexer that '}else{' and '}else statement' were different tokens, along with allowing all of the variations of newlines and such. Anyway this parses now and creates correct assembly code.
a=1;
if a
{
b=2;
if b=2
{
d=6;
}
}
else
{
b=3;
c=5.0;
}
if b
{
x = 1+1;
z = x;
}
else
y=11;
The code font on these forums are a bit small...wonder if I can changer that ?
Cool on the IF statements.
Don't know on the size of the code sections.
Will Aurora have oo you know like classes and objects? Or are we going to be more closely tied to C?
Yes we will have objects. But you won't need to use them and can still program top down if you wish.
Still struggling with one more aspect of the IF statement. Want to allow "else if" constructs without needing to terminate each IF with a closing brace.
Almost working as I can do this now:
if something
{
}
else if somethingelse
...
else if something more
...
Paul.
How about having the else if as elseif?
How will we create windows and things? Will it be similar to IB or will we be using more of a C type syntax for that? i.e.,
void main(args...)
{
...
}
Still thinking about more things too...
Not as complicated as C but you will need a main function. Haven't finalized the syntax of function defintions yet. We can call it whatever we want though. Like 'start'
start(numargs as int, arglist as string[]),int
{
}
We can use libraries of functions for easy creation of windows.
#include "aurorawin.inc"
WINDOW win;
OpenWindow(win,....);
To maintain cross platform code I would need to create a similar library on Linux that glues to GTK (Linux API for dealing with GUI stuff).
But you won't need to be tied down to it, or even use it. On windows you can have an API include file and just use it like C
#include "windows.inc"
HWND mywin;
mywin = CreateWindowEx(...
Your program wouldn't compile on the linux version though. Still many wouldn't care anyway.
Paul.
OK, Finalized my ELSE syntax. Keeping the distinction of a single instruction ELSE while allowing ELSE IF.
For example there are cases where you need to use a 'block' else.
if 1
{
x = 1+1;
z = x;
}
else if 2 {
y=11;
}
else
while (a<12){ y--;a++;}
Will generate an error on the 'while' since it is not a single statement. Informing you to use a 'block' else. Like so:
if 1
{
x = 1+1;
z = x;
}
else if 2 {
y=11;
}
else
{
while (a<12){ y--;a++;}
}
C allows the first form which can be confusing to read. And I am just tired of working on ELSE contexts. ;) Maybe I'll go back to it later.
Paul.
Cool! :)
Getting closer. We can now create subroutines.
declare mysub(unsigned int a),unsigned int;
sub mysub(unsigned int a),unsigned int
{
a +=2;
return a;
}
The older AS keyword works too.
declare mysub(a AS unsigned int),unsigned int;
sub mysub(a AS unsigned int),unsigned int
{
a +=2;
return a;
}
The first form is more common and will aid in converting code from other languages. The second form helps when converting from BASIC languages. The 'declare' statement is only needed while we are developing and for import libraries. Once I have a preparser written it will be optional.
Defining variables has three syntaxes too.
DIM a AS int;
DEF b AS int;
int b;
Look familiar ;)
Yes, looks familiar. :)
Okay, I like where you're going with the language. The funny thing was, before I got on the forum I was thinking "I hope Paul makes a new language that is as safe as BASIC (you know what I mean, a newbie can jump in and not worry about garbage collection, they have dynamic arrays, they can be sloppy, etc.) but I would like it to be easier to see some C or C++ code that I like and easily convert it. I'm not saying I want C+++ or JAVA++, I just want to be able to come across some nice C\C++ code and say "Hey I'd like to convert that over to Aurora, that could be useful" and be able to do that without hitting a brick wall to easily (okay, I just want to be able to lazily convert it over ;D)
I also like the fact that you are making it cross platform (not just Linux) because I can't give up Windows, that's my bread and butter but I still like Linux.
BTW, I like the name Aurora. I hope you keep it. 8)
Yep I'll keep the name. In fact finished desigining a bunch of icons for it last night.
The syntax was designed for easy porting of code from other languages in mind.
Paul.
Sounds good!
I'd like a language that I can whip out a lazy app if I want (like in BASIC) but can use for advanced stuff as well.
What about in-line assembly? If you do have it will you be using NASM or FASM? Too bad there's no cross plaftform assembly language (at least that I know of.)
Did you see my 1k Assembler on the Pyxia forum? I know you'll know right away how I did it but I want to see how quickly the guys over there figure it out.
How difficult would it be to make it work with IBasic Pro command paks?
NASM is cross platform, which is why I use it.
As for the command paks....depends on which one your talking about. They are just static libraries after all.
Paul.
I was primarily thinking about the 3D Pak. ;D
...although, I think the 3D Pak is dead. Tom has shown no interest in it. Well, at least this language will easily work with external DLL's such as Ogre, etc.
Tom is a strange character.
There is a multitude of good 3D engines out there written by people that know a bit more about it than me. I prefer to concentrate on the language for now. I was pushed in a paticular direction with Pro when Idigicon was involved. A direction that ultimately limited what I could do with the core, syntax, IDE, etc. Idigicon was more concerned with their image, and making sure no one badmouthed them online, then they were with the actual products.
I know it's still way too early in the development process, but do you plan on adding your own GUI elements to the language or using an existing cross-platform library (wxWidgets, etc.) ?
...or both?
BTW, I really like the use of the semicolon as a terminating character. It should help make the sntax very clean and easy to read.
Good stuff.
-Doc-
Since the goal is a cross platform language the core will be kept simple, no platform specific commands built in.
Instead external functions sets, through static libraries, will provide the needed interface capabilities. Of course they will be of our own design so for example on Windows you would have a console library, linux a shell library and both would have say a string library for BASIC lke string manipulation.
#include "conlib.inc"
#include "stringlib.inc"
global sub main()
{
int a;
a = readline();
a = mid$(a,1,10);
}
And on linux
#include "shelllib.inc"
#include "stringlib.inc"
global sub main()
{
int a;
a = readline();
a = mid$(a,1,10);
}
On both I plan on having a GUI module. GTK and the Windows API both share enough similarity that a common set of functions can be written for both. Both have the same basic set of control types.
So an Openwindow function on the Windows version will have the same parameters as Openwindow on the Linux version. The differences can be handled using a few #ifdef statements.
#ifdef LINUX
#include "conlib.inc"
#else
#include "shelllib.inc"
#endif
Thats where I see it in my mind right now. Of course unforseen difficulties lie ahead ;)
QuoteSo an Openwindow function on the Windows version will have the same parameters as Openwindow on the Linux version. The differences can be handled using a few #ifdef statements.
#ifdef LINUX
#include "conlib.inc"
#else
#include "shelllib.inc"
#endif
Sounds great! ...I can see already that I'm gonna enjoy this. Ready for the alpha release. ;)
-Doc-
Paul,
I've been studying the syntax displayed in your screenshot and was curious about the use of printf() ...
Will the final implementation be pretty much the same as with C, using control characters and escape sequences as shown, or do you have something else in mind?
That of course brings another set of questions to my feeble brain... just how closely will Aurora follow the C syntax, (generally speaking) and what are the major differences you have planned?
From an end user's perspective, what will make Aurora the language to choose rather than just learning and/or using C/C++ from the get-go? Just being curious here. ;D
-Doc-
Just using printf because there are no other I/O functions to use yet. So it is just convenient for testing purposes. The string escapes are the same as the ones Pro used. Math functions are pretty much identical, etc.
The syntax is related to C but not directly compatible. Things like semicolon terminators, braces { }, etc are found in many non BASIC languages for the general reason that it is easier to write a parser with standardized symbols. Source editors also have an easier time with syntax coloring and folded functions.
The differences are the same that make BASIC appealing to some users. Aurora has built in string handling, array and data management, automatic declaration of functions, automatic type conversion, auto definition of variables based on input, and the list keeps growing.
C has a much stricter syntax, and while it is cross platform to an extent, you really have to jump through hoops to compile the same code base on multiple OS's. Microsoft hasn't made an ANSI complient C compiler in years and the over dependance on MFC code has made the concept of cross platform code non existant.
So the bottom line is I am aiming for the same ease of use as IBasic with a more compatible syntax with the rest of the world. If you have ever done any major work in C you'll notice the differences immediately. C programmers can't do this:
A = "hello" + " there";
if A = "hello there"
{
do something.
}
Which in equivelen C code would look like
char A[12];
strcpy(A, "hello");
strcat(A," there);
if(strcmp(a, "hello there") == 0)
{
do something;
}
C++ programmers have an easier time since there are string classes and templates you can use. In MFC there is the CString class which manages its own memory.
CString str;
str = "hello";
str += " there";
if(str == "hello there")
{
}
Paul.
Your choice of syntax is *exactly* what I want. I just want to get my grubby hands on the Alpha. ;D
Truth is, although I've
tried to learn on more than one occassion, about all I've ever accomplished with C to date is to give myself a headache.
QuoteSo the bottom line is I am aiming for the same ease of use as IBasic with a more compatible syntax with the rest of the world.
From what I *do* know about IBasic and what you were able to accomplish with it... BASIC-like syntax or not, Aurora already sounds like music to my ears.
-Doc-
No worries doc. The hardest part about learning C is comprehending its continual use of indirection, pointers, and very strict type checking. C is very good at what it was designed for and is one of the most long lived languages in existance. A tribute to the original designers.
Aurora won't be as strict and you'll be able to code in the same logical manner you are used to.
Paul.
WARNING: Disccusion of pointers ahead. If you don't like them then don't read ;)
Speaking of logical I just finished the pointer handling syntax of Aurora. Those that used pointers in Pro will appreciate the fact that Aurora allows typed pointers by definition as well as the old Pro way of assignment.
In Pro you had generic pointers, which is still allowed in Aurora
POINTER myptr;
INT b;
myptr = b;
...
*b = 122;
In the above code the pointer doesn't have a 'type' until the address of b is assigned to it. Then it 'points to' and INT type. While convenient for most it was confusing for anyone converting from other languages. The other problem was passing a pointer to a subroutine..
SUB mysub(ptr as POINTER)
*ptr = 122;
...
Would generate an error because at that place in the code the type that 'ptr' pointed to was unknown. In Pro I added the SETTYPE command to alleviate this, or you could use type casting. In Aurora you can use C syntax for pointers now, which removes the need for typecasting or the use of SETTYPE.
SUB mysub(int *ptr)
*ptr = 122;
...
With that out of the way the syntax is almost complete. Now to start writing the console,string and GUI libraries. The console library will be very familiar:
locate(y,x);
cls();
etc.
And the string library will have all of the normal funcitons like mid$, left$, right$.
Paul.
Great! That will definfately make converting code easier.
How will Aurora be for handling ActiveX? If you add OO support it should be much easier, right?
Sounds like you're making good progress, Paul. Do you ever sleep? At this rate it won't be too much longer and maybe we'll have a console version to hammer on... ;D
-Doc-
P.S. - I actually read your description of the pointers above... even without going into convulsions. ;)
Yes I do sleep on occasion ;)
Trying to get as much done by Nov 7th as I can. After that my time will hopefully be split between an outside job and programming.
Paul.
Hi Guys,
A few queries:
1. Could we have a 'single quote' comment (' This is a comment) - I like this simple form ..
2. Would 31 character variable names be adequate, and perhaps easier for Aurora to deal with.
3. What's a 'dstring' ?ÂÃ, Ã‚Ã, Strings are weird.ÂÃ, I seem to remember writing some short strings to file in another language, and getting 255 characters per string written to the file, so I needed something like istring[10] to keep them short. Might it be easier to just have a single 'string'ÂÃ, type - defined as string[n].ÂÃ,Â
4. Any chance of a more flexible 'select' statement?
Maybe:
select value
{
case (1,3,5,7)
numvar = 0;
case (2,4,6)
numvar = 1;
}
The general form being:ÂÃ, Ã‚Ã, case (i,j,k,l, ...)
and for string type:
select strvalue
{
case ("dog","cat")
strvar = "House Pet";
case ("crocodile")
strvar = "Dangerous Pet";
}
The general form being:ÂÃ, Ã‚Ã, case (a$,b$,d$, ....)
It just saves having to write lots of 'case' lines ..
all the best, :)
Graham
ÂÃ, Ã‚Ã,Â
Hi graham,
#1. The ' will have a different purpose. To specify a byte value without needing the ASC function. 'a', 'B' . But I'll think about adding another comment character.
#2. The parser can handle up to 64 now, shorting the limit would have no effect on speed.
#3. It's a Dimensioned STRING (dstring). Same as an ISTRING in another language. You wouldn't have that problem in Aurora as the file I/O functions are programmer controlled now and don't make any assumptions. For example if you wanted to just write 10 characters of a string
write( myfile, str, 10);
Or to write a string up to its length
write( myfile, str, len(str));
#4. Anything is possible. Depends on whether or not the parser can cleanly determined what to do based on the next token. Right now it is an extremely clean syntax.
Paul.
I agree with Graham that #4 would be nice (anything to save typing.)
BTW, I'm already seeing how well it works for future 1k challenges. ;D
Here's a couple ideas of things I'd like to see:
... native regular expressions.
... the web browser object as fully subclassed (the HTML can become the UI which is very nice if you've seen it done.)
Thanks Paul .. looks like you've got things covered as usual ..ÂÃ, :)
One other thought, is the WINDOWS type declaration redundant, since OPENWINDOW() or whatever sets up a window, in effect declares the Window name in it's first parameter. This could be used directly to define the window.
Just looking to save a bit of typing ..
Graham :)
Graham,
There isn't a windows type yet ;)
And the GUI library will be a bit different then the 'other' language. You'll see when I am done. But needless to say I now know what works, and what doesn't.
Paul.
Just to clarify that a bit more....
When I designed my last language I was bound to a specific syntax, and the need to be somewhat compatible with my first one. This required a lot of glue code and compromises I wish I didn't have to make. Aurora can return complex structures from functions directly and will have OOP available as well. So there will not be much need to 'pass' a variable as a parmeter in order to set it.
For example think about the differences in the file function OpenFile.
file = OpenFile(name, attributes);
instead of
OPENFILE( file, name, attributes)
It may seem to be a minor difference in a small function like that. But it allows the auto definition of the variable.
When classes are finished you could have a file class, but if you don't like OOP you're probably not going to be interested.
AFile myfile;
myfile.Open(name,attributes);
while myfile.Read(c, 1)
{
A$+= c;
}
myfile.Close();
In the same manner we can have a window class.
Paul.
Quote from: Ionic Wizard on November 04, 2005, 01:29:56 PM
When classes are finished you could have a file class, but if you don't like OOP you're probably not going to be interested.
AFile myfile;
myfile.Open(name,attributes);
while myfile.Read(c, 1)
{
A$+= c;
}
myfile.Close();
I am really looking forward to this!
I think a file class would be cool actually.
I am really enjoying all this OOP, it keeps your code a lot tidier i think, not so many declarations everywhere.
Lewis
Why not make one yourself ;)
class File
{
unsigned int m_hFile;
// Can't use a constructor since it can't accept arguments.
// But a destructor's fine.
declare _File();
declare Read(int numbytes),pointer;
declare Write(pointer buffer, int numbytes),int;
declare Open(string *filename, unsigned int mode),int;
declare Close();
}
File::Read(int numbytes)
{
pointer ret; ret = 0;
string *pBuffer;
pBuffer = new(byte, numbytes+1);
if(m_hFile) ret = ::READ(m_hFile, pBuffer, numbytes);
return ret;
}
File::Write(pointer buffer, int numbytes)
{
int ret; ret = -1; // there was an error
if (buffer<>0 and m_hFile<>0) ret=::WRITE(m_hFile, buffer, numbytes);
return ret;
}
File::Open(string *filename, unsigned int mode)
{
m_hFile = ::OPENFILE(*(string)filename, mode);
return (m_hFile <> 0);
}
File::Close()
{
if (m_hFile) ::CLOSEFILE(m_hFile);
return;
}
File::_File()
{
Close();
return;
}
By the way, the line m_hFile = ::OPENFILE(*(string)filename, mode); is another one where *(string) is required and * alone doesn't work.
Yeh i could of done. I just it would be a good suggestion to be actually added to the language core.
Lewis
A built-in file class would be nice to ensure it's completely cross-platform.
Mine is cross platform, since it uses Aurora's functions. Only Paul's code changed. If I used the windows API directly though, then I'd have to write a separate one for linux if I wanted it to run there.
I wonder how long it will be before we see some linux stuff (not trying to rush things). Ive never programmed with linux before so being able to do it in a language that i feel comfortable with will be awesome.
Lewis
Yeah, I'm wondering too about the linux API (GTK/Gnome/whatever is used) and how it compares to windows.
Well as i dont know much about linux apart from the web side of things (and still not much) im curious as to how it all works with the different desktop environments. They must all have to be of a certain standard and all have a sort of global GUI API that is the same as all the others in order for Linux apps to work on any Desktop.
Im more interested in making console based applications for linux anyway, maybe ill get pulled into making some GUI stuff but i doubt it, it will mostly be used for my web development.
Lets just wait and see hey!
Lewis
There's xwindows, but there are a lot of different desktop managers that I assume work differently.
Yes i think X Windows is the linux GUI core and then there are the desktop managers like Gnome and KDE which i assume will sort of work like a class. KDE inherits X Windows API etc. Maybe im not too sure. I understand Paul is a bit of a linux Fan and Guru so maybe he knows.
Lewis