I like that idea calc!  Although I think the ! and ? are both confusing since they mean other things.  Perhaps some other symbol?  Although, yeah, that would be quite a monster to implement... and not entirely clear when to use each one for a beginner.  Also, this would be difficult to logically chain conditions together with and and or, or what to do when more code follows the statement.

I've finally figured out how to easily and intuitively allow stack usage for Axe programs that's so easy, even beginners can do it  

Its so simple, I don't know why I didn't think about it before.  The syntax will simply be "keep(EXP1,EXP2)".  All it does is evaluate expression2 and then return expression1.  You might be like "Wait, what?  That seems so pointless, why can't I just do EXP2:EXP1 then?  Isn't that the same thing?"  The answer is no.

Consider this:
A->B:B->A
In that example, first, A is stored to B and then B is stored back to A again.  Not useful at all.
But now consider this:
keep(B,A->B)->A
What happens now?  You might think that since keep returns the first expression B and then stores it to A that its still the same piece of code. But no!  Keep evaluates B first and then keeps that value until the end of the keep.  So even though B changed value during the 2nd argument, the original B is returned and stored into A.  In other words, this is how you perform an exchange with only 2 variables, and its 4 bytes smaller than using an extra one too!

So where is the original value of B stored then?  That's what the stack is, but you don't need to know that.  All you need to know is that keep is magical and super efficient for this kind of thing.

EDIT: OOOOH, I just realized you can also make recursive function calls with this! 
:Lbl FUN
:keep(r1,keep(r2,FUN(r1,r2)->r3)->r2)->r1
:Return r3

Theoretically, it could be abused, but it wouldn't be any more optimized than a regular if statement, just more cluttered and less readable.  I added the ? and ?? as operators specifically to avoid chains of if/while statements like If A:If B:If C:something:End:End:End should just be if A?B?C:something:End.  I don't want to allow intentionally misleading code as legal syntax when there is already a better way to represent it.

Code: [Select]

A?Pt-On(X,Y,Pic1)Is supposed to throw an error?  It seems like every time I try to do a Pt-blarg() it errors

Yeah that should error.  That's like saying "A and Pt-On()" which doesn't make any sense since Pt-On() doesn't return a value.  In general, you can only use Axe commands that start with lowercase letters inline.  Uppercase commands have to start from a new line.

Whaaaaaaaaat!  It was just working!  I swear!  One sec.

Eh... I'd rather keep string parsing simple for now, so no multi character tokens.

EDIT: That was it Runer, I just found it lol.  That's what I get for coding so fast 

That makes so much sense now, lol!  I can't believe you were able to get that from disassembly, awesome job!

Those other 2 are not bugs though:

Tokens that are more than 1 character are clipped to create their character counterparts.  For example, the token "det(" just turns into "d" to make it consistent since these are character strings, not token strings.  Also, this is the same routine used for individual character reading in single quotes so it wouldn't make sense there either.

The 'var' token is not a 1-to-1 mapping to a character in a searchable string form.  There is an extra zero that has to be added.  It is handled separately in the string parsing routine instead, just like the string, matrix, and custom list tokens.

Horizontal should only be unnoticeably faster... regular multiplication was the only routine that received a significant speedup, but only when you don't use ** or *^ anywhere in the code.

I've fixed the A429992 error now, I'll upload the patch soon.  I just need to find a couple other easy things to add to make the update have some kind of new features.  For that other problem, could you post some source code that caused the error (if it was indeed the compiler's fault)?

Thank you SO much!  I can now narrow down the problem.

Axe apps still need to be signed to transfer to another calculator, but at least it won't delete itself.

EDIT: HAHA!  I found it!  Turns out the problem was that TI's "DelVarArc" bcall re-locks flash again whenever it deletes from flash.  My flash unlocking routine was above it, so all I had to do was move it down after that call.  Has anyone gotten the random 'r' error yet with 1.0.4?