Yeah, it must be a bug then, I'll look into it.

I am.  But I found I can actually use a bit from one of the registers instead to hold the state of the operation instead of using SMC or even an app flag if I run out of registers.

From what I've compared to with other languages, English is a relatively easy language to learn to speak, but is a hard language when it comes to spelling, proper grammar, ambiguous statements, and other technical details due to how many exceptions there really are.  Even native English speakers who see an unfamiliar word often have trouble trying to guess the proper pronunciation.

But despite this, there are a lot less exceptions when it comes to forming sentences than you might think.  English only has 4 or 5 different verb conjugations for instance while Spanish for instance has over 50 when you include the fact that you need to use a different verb when referring to different groups of people or objects.  Also, English doesn't have masculine or feminine noun conjugations.

Overall, I'd say its on the easier side of the language spectrum.

Interesting... Parentheses et al. can still cause errors if mismatched, though, (e.g. For(X,L3,L3+10:{X-1->X:End, w/new lines instead of just colons, causes an ERROR:BLOCK for me) Maybe you could document what is and isn't valid?

Really?  That should be proper syntax.  What you're telling the parser to do is to store the value X-1 into X and then read the data at that new location and do nothing with it.  If instead, you want the data at the location X-1 to store into X, then you need the closed parenthesis for this case.

If you're ever getting an error from not closing the parenthesis, let me know, becasue that should never happen, axe always adds the parenthesis at the end for you automatically like basic.  So when you type:

:{X-1->X

The parser should automatically put parenthesis at the end to make:

:{X-1->X}

And NOT this:

:{X-1}->X

As you use Axe more often, you find it is very convenient to use the arrow operator inline than it is to use it by itself.  It also optimizes the code size and speed significantly when used properly.  I can't make everything you typed so far just end every time you store, otherwise, you can't do these very efficient optimizations and coding tricks like for example: Fill(X->{L1},99) to fill ram at L1 with 100 copies of X.

Its actually far more lax than BASIC.  Its just the change of some of the operators that might be confusing you.  The store arrow in BASIC used to mean store everything that came before it to a variable.  Now, it means store the current expression stack into a variable so you now have the freedom to use it inline.  And Axe doesn't really care much about using the enter button.  These are the same:

:A->C
:E->D

:A->CE->D

And things like this:

:A+1->A
:If A=10
:End

can reduce to this:

:If A+1->A=10
:End

And another thing most people don't know about.  The answer always carries over to the first argument of the commands.

:X
:Pxl-On(,Y)

Is actually the same as Pxl-On(X,Y) since the last expression was X and carried over.

I had the file renamed in the update, so I think it reset the stats.

It means that in addition to the bytes required for the command, there is also a subroutine that has to be added to the program.  The subroutines are shared though, so if you make 10 divisions by unoptimized constants in your code, and the division routine is 20 bytes (I don't know what it actually is offhand), then the amount of size it would take up would be 10*6 + 20 since every call uses 6 bytes and the subroutine itself is 20.

I've actually already updated that for the next version since I had so many optimizations to add to the list.

Okay, that's good.  I spent hours trying to optimize some of these using all the tricks I know.  That reassures me it was a wild goose chase.