Syntax discussion

[Doc]

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-

[Ionic Wind Support Team]

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

[Doc]

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

Sounds great! ...I can see already that I'm gonna enjoy this. Ready for the alpha release.

-Doc-

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

-Doc-

[Ionic Wind Support Team]

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.

[Steven Picard]

Your choice of syntax is *exactly* what I want.  I just want to get my grubby hands on the Alpha. 

[Doc]

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.

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.

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-

[Ionic Wind Support Team]

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.

[Ionic Wind Support Team]

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.

[Steven Picard]

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?

[Doc]

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

-Doc-

P.S. - I actually read your description of the pointers above... even without going into convulsions. 

[Ionic Wind Support Team]

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.

[GWS]

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:

Code Select Expand


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:

Code Select Expand


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
ÂÃ,  ÂÃ, 

[Ionic Wind Support Team]

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.

[Steven Picard]

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. 

[Steven Picard]

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

[GWS]

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

[Ionic Wind Support Team]

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.

[Ionic Wind Support Team]

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.

[Steven Picard]

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!

[Zen]

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

[Parker]

Why not make one yourself

Code Select Expand

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.

[Zen]

Yeh i could of done. I just it would be a good suggestion to be actually added to the language core.

Lewis

[Steven Picard]

A built-in file class would be nice to ensure it's completely cross-platform.

[Parker]

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.