And I've once gotten an ERR:BLOCK that was fixed simply by removing the Else between an If statement and an End, even though the block made perfect sense. I can't seem to recreate the bug, though

EDIT: Ok this is weird, i just got my source corrupted again but it cant be the backup feature since its in a subprogram thats getting corrupted, and i even cleared my RAM from just before

Subprograms don't get backed up? Didn't know that...

Oh also, it would be nice if Axe saved whether or not you like lowercase turned on, currently it just lets you swap between what you currently have and the other option.  If i turn on Lowercase letters, clear RAM, and then go to Axe the option has changed back to uppercase.  I think it would be nice if it just automatically saved your option and applied it when you start Axe.

^ Agreed. Right now we have to go under Options > Alpha every time we RAM clear, which for me would be about 12 times a day.

As for the subprograms, they are not actual "sub" programs put part of the original code itself.  Thus you can make block abstractions within your code:

.MainProg
prgmFOREACH
.Do Stuff to element
prgmENDEACH

..ForEach
.Initialization
For(A,0,N)
.Setup

..EndFor
.Clean Up
End
.Destructor

I could check to make sure that the block level count before and after reading a subprogram is the same but then you wouldn't be able to use these abstractions.

Backing up subprograms would be a little awkward to compile.  It would first backup the main program then start compiling and whenever it sees a subprogram, pause compiling to back it up and then resume.  The best solution is to just keep your subprograms in archive and only have the programs you're actually editing in the ram.  But I will see if it is possible to have this as an option.  I can't scan the program looking for subprograms ahead of time because it would have to ignore comments, quotes, characters, absorbed data, etc. which are taken care of during the actual compile.

Also, I've been thinking... to avoid the corrupted ram issue, maybe I should have the main program get backed up at the end instead of the beginning of the compile.  That way in case a bad program corrupts your program, it probably won't be able to finish the compile successfully and therefore will not replace the last backup.  Also, getting any other syntax error will mean you have to go back and fix it so it shouldn't need to waste time archiving.  In other words, if it can't compile, the problem must be fixed before replacing the last working backup.  The only danger is in case Axe crashes the program in ram would be lost, but I don't think I have those problems anymore.  Also you can't use that trick to backup BASIC programs anymore (but you can write a program to do that in Axe )

Also, I've been thinking... to avoid the corrupted ram issue, maybe I should have the main program get backed up at the end instead of the beginning of the compile.  That way in case a bad program corrupts your program, it probably won't be able to finish the compile successfully and therefore will not replace the last backup.  Also, getting any other syntax error will mean you have to go back and fix it so it shouldn't need to waste time archiving.  In other words, if it can't compile, the problem must be fixed before replacing the last working backup.  The only danger is in case Axe crashes the program in ram would be lost, but I don't think I have those problems anymore.  Also you can't use that trick to backup BASIC programs anymore (but you can write a program to do that in Axe )

That might be a better idea. It would save some time when we get errors

I don't know if this has been requested, but 32 bit math would be awesome.

It would. It would also require Quigibo to completely rewrite every math routine and auto-optimization for a 32-bit mode, as well as needing to create ways to interweave it with the normal 16-bit mode, both on the compiled program side and the parser side. It would be a long and difficult undertaking, and although it would be awesome, I think its sheer difficulty makes it a low priority.

An 8-bit mode has been requested too, and even though that would undoubtedly be a good deal simpler and easier to code, that's still the kind of thing Quigibo doesn't imagine implementing until the far future, like Axe 2.0.

Also it probably wouldn't be too bad to write a small 32 bit library for Axe, since we have all the multiplication routines we need, it could even be an axiom!