But wait, that's a bad Idea, because Axe's L1 is SaveSScreen, a set of 768 bytes that the OS dumps the screen into on an APD, and Axe's variables are located at the very end of L1.

Well, it also depends, if you do #alloc() and you don't even use L1 (I personally never really touch it) then you're fine

Speaking of For( loops, I don't know if this has already been asked, but why isn't a 4 parameter allowed?  Even if it's just a constant increment or decrement, that would be really helpful

The main reason is that the increment code has already been written by the 2nd argument so it would be hard to make that happen on the 4th argument.  I would have to do some really weird and difficult out of order parsing for that to work, and I don't want to make it the 2nd argument because that would be extremely confusing.

Also, I will probably be adding a new loop structure which unlike "Repeat" is literally a "Repeat".  The syntax is a one argument for loop For(Times):Code:End where it just does the loop however many times without using extra variables and is highly optimized (more so than Runer-style loops).  The only thing blocking me right now is those AWFUL "Goto" statements.  I now see why so many languages ban them, they make it really difficult to optimize since you can't use the stack in any loop that has a goto, otherwise you get memory leaks.  I am therefore banning the Goto instruction inside this new loop structure and possibly for-loops if it leads to an optimization there.  I mean you shouldn't be abusing gotos that way anyway so I'm hoping there won't be any compatibility issues with this.

And just to let developers know, I already added code to allow Axioms to hijack existing routines so they can call or jump into any routine at any entry point.  Beware when using this on native Axe commands though as some of them could change from version to version as new optimizations are found.  Speaking of which I've already found a few major optimizations with all sprite and pixel commands that should shed quite a few bytes off of programs, especially larger ones.

If no Goto, then can we please have EndIf in For loops? And this new thingy, whatever it is?

That's already been around since I first added the EndIf, you can always use them in for loops

Orly?I have a super important feature request:
Continued Axe improvement after 1.0.0 is released.

Oh, speaking of Subroutines, a way to end the program from within a subroutine.

I have a whole slew of compiler-side feature requests involving static pointers, constants, and labels (which I will henceforth collectively refer to as defines). I figure since Axe is nearing 1.0.0, compiler-side feature additions would be a decent priority. I will order them in what I believe would approximately be increasing difficulty to implement, which also happens to be increasing awesomeness.

---

EDIT: I just want to mention that I don't really need any of these features, so don't feel like you have to add all or even any of them. Although out of all of them, I would probably most like the third one.

---

First, could the parsing of defines be modified to accept lowercase letters?


Second, could static pointers and constants not require the first token to be a GDB, Pic, or Str token? I see this as being most easily implemented by allowing define references to be prefixed with an easily accessible token like i, which would dictate that what follows is a define and not a variable. Some sample code of old and new static pointers coexisting:
"appvTILEMAP"→iAPV
"Not enough RAM!"→Str0E

!If GetCalc(iAPV,4096)→M
  Disp Str0E
  getKeyʳ
  Return
End


Third, in addition to user-defined constants, could there be user-defined variables? I realize this can sort of be emulated with code like {GDB0}^r, but that wouldn't qualify for variable optimizations and would be a pain to type every time you wanted to use it. The easiest way I see this being done is by chaining it with the above suggestion. You would define them as a constant but would reference them with a prefix like var (the u token) or ?. It would even have built-in de-referencing! Some sample code:
"appvTILEMAP"→iAPV
"Not enough RAM!"→Str0E
L₂→iMAP

!If GetCalc(iAPV,4096)→varMAP
  Disp Str0E
  getKeyʳ
  Return
End


Fourth, could unused tokens be turned into defines? When the initialization statement is reached, the token would be checked to confirm that it's not already a command or a define. It would then be added to the list of defines with the first "name" byte being an identifier that it is a token, something like 0. Then, when a reference to the token is reached and it does not match any commands, check the define array. I can also imagine an extension to this that would allow r modifiers to be tagged onto the token, setting flag bits in the first "name" byte. Instead of checking that the first "name" byte is 0 during parsing, you would check that the high six bits are 0.


Finally, this feature request would probably require some overhauling of the parser, but it would be incredible: using an extra RAM page while compiling on calculators that have one. With this, you could lift the static pointer and nested conditional limits to near-unreachable levels. You could even increase the maximum length of static pointers to a much more comfortable length like 8 characters and still have more than 10 times the number of available pointers than there are currently.

Alright, I'll answer all of those

1. Yes, that would be be easy.  I remember trying to do this before though and I think there was some problem with it but I don't remember what it was so I'll try it again.  Right now, each symbol is 3 bytes and I'm already using that to store 4 characters via 6-bit compression.  With 26 uppercase, 26 lowercase, 10 digits, theta, and null, that exactly fills up the 64 allowed combinations.  So if there's some other character there I'm forgetting, that may have been the reason, but I guess I could scrap a letter or 2, however confusing that may be...

2. That would be easy, but I'm not sure about that token choice, that would be weird since its currently used in the newline.  I could instead use the pi token since I don't think my previous idea of using it for stack is going to work.

3. Also easy.  I just don't want to encourage them to be used too much though or you'll start to get out of symbols errors.  But I'll definitely implement this if I do the above.

4. I don't think so, there is no single table of all the tokens Axe uses, and when you include multiple Axioms, it would get even trickier.  Also, there's just too many places in the code where a token needs to be instantly recognized as variable, constant, or special character.

5. Love the idea, but I would hate to see someone not be able to compile others' source code just because they don't have an extra ram page.  I guess I can put that up for a poll maybe.  There was point where I was thinking of using extra ROM pages, which both calcs have, since the data is write-once anyway and I already have routines to unlock flash.  I'm pretty sure the 83/84s keep an entire sector open for nothing but temporary swap use, which I could clear and use myself.  That might be better, but I'll have to do more research to make sure its possible.

All these are reverse compatible with the current Axe version though so I could add them any time.  My highest priority right now is fixing things that are not going to be reverse compatible since I want to stop changing those after 1.0.0.