I like that idea, but not #Define but #def because that fits better, and maybe other symbols that are shorter...

Good point. Maybe for the hijacked BASIC tokens we could use nPr and nCr (#Def and #Undef respectively).

The problem with this is the limited RAM space Axe has when compiling, and it already uses pretty much all of it. It would be a great feature, but it would be difficult to be implemented.

Another reason for Axe to enforce parentheses:

Quote from: OmnomIRC

[16:47:34] <+Hot_Dog> wow, it's still not working
[16:47:51] <+Hot_Dog> even on hardware
[16:48:40] <+Hot_Dog> I just don't know
[16:48:55] <+Runer112> what does the source code look like
[16:48:59] <+Runer112> for your test program
[16:49:19] <+Hot_Dog> .ABC : AsmComp(AXIOM : 9
[16:49:30] <+Runer112> umm
[16:49:35] <+Runer112> add an ending parenthesis maybe?
[16:49:51] <+Hot_Dog> indeed, forgot that
[16:49:56] <+Hot_Dog> that was the problem all alone
[16:49:59] <+Hot_Dog> *along
[16:50:01] <+Runer112> wait
[16:50:03] <+Runer112> did that fix it?
[16:50:07] <+Hot_Dog> yes it did
[16:50:08] <+Runer112> lol
[16:50:20] * +Hot_Dog bangs head against wall again
[16:50:21] <@DThought> And that is why I think Quigibo should enforce it
[16:50:26] <+Runer112> and this is why Axe sorely needs to force parenthesis closing
[16:50:36] <+Runer112> so many bugs caused by open parentheses
[16:50:38] <@DThought> Ninja'd, Runer.

It just adds another thing to remember when debugging sometimes

Yeah, I spent 2 days trying to find a bug that turned out to be just one missing parenthesis at the end

Actually, constant definitions would be very easy to do and are already implemented, kind of.  That's exactly what Str1, Pic1, GDB1 are!  They just hold a constant value that happens to be a ram location.  But I could easily allow the programer to specify other values for these constants and the syntax would be very intuitive:

9001->Str1

This would use symbol space though, so its still limited to ~150 static variables including the regular static pointers.  Bun nonetheless, still generally useful since I don't think that many people actually run out of symbol space. 

EDIT:

Question:
What exactly happens if I leave a parenthesis open?  Obviously, it'll start glitching the program up, but in what ways?  What precisely does it do to the code?

Axe will add the parenthesis for you at the end of the line.  So if you had:

sin(A+cos(B->C

It becomes:

sin(A+cos(B->C))

Instead of what you might be trying to do:

sin(A+cos(B))->C

Quigibo, if you add constant definitions to Axe programming, could you perhaps add it to Axiom programming as well? That's something I always thought would be quite useful. Perhaps add a new command type, AXM_CONST, that has a 2-byte value instead of a routine? And something that would be even more awesome is a type like AXM_VAR, that allows you to define custom variables that are fully compatible with variable auto-optimizations and dereferencing. Again, you'd probably want the routine data to be replaced by a 2-byte value, in this case a pointer to the variable.

EDIT: And while I'm talking about Axiom feature requests, I want to bump my request for support for offset calls.

I'm trying to figure out what the purpose is behind these constants. Wouldn't it just be the same thing as, say, putting in the number?

Yes, but it's easier if you change something.  For instance, let's say you have a piece of code that draws a tilemap to the screen that's 8*12 sprites large.  But what if you wanted to add a HUD to the side of the screen and make it 8*10?  Then you'd have to find all of those 12s in your code and change them to 10s.  Or you could have used the (hopefully) soon to be Axe equivalent of a #define() when you wrote the code in the first place, so all you'd have to do is change the line with the #define() in it from a 12 to a 10 to fix all of those lines of code.

Quote from: Freyaday on May 12, 2011, 09:15:54 pm

I'm trying to figure out what the purpose is behind these constants. Wouldn't it just be the same thing as, say, putting in the number?

Yes, but it's easier if you change something.  For instance, let's say you have a piece of code that draws a tilemap to the screen that's 8*12 sprites large.  But what if you wanted to add a HUD to the side of the screen and make it 8*10?  Then you'd have to find all of those 12s in your code and change them to 10s.  Or you could have used the (hopefully) soon to be Axe equivalent of a #define() when you wrote the code in the first place, so all you'd have to do is change the line with the #define() in it from a 12 to a 10 to fix all of those lines of code.

Question: Why not just pick a random spot in memory near the end of a buffer or pick a variable, store the number, and resolve never to modify it?

By the way, I finished adding the request for constants.  It was only about 10 lines of code extra. 
It works really nicely too!  You can even add, subtract, multiply, and divide constants with each other to make new constants, all with nothing added to the executable code!

I've added so many new features and bug fixes, probably the largest update so far, but I don't know if I'll have time for everything I was planning by tomorrow's release.  Of the most complicated new additions that I have yet to make and am not sure about making yet are: stack operators, alternative referencing syntax, and native register operations.