• Features Wishlist 5 1
Currently:  

Author Topic: Features Wishlist  (Read 606994 times)

0 Members and 3 Guests are viewing this topic.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3375 on: August 20, 2014, 04:16:20 pm »
The ! idea crossed my mind as well, and would also be a contender for an escape character. But the issue I have with it is that I'd ideally want it whatever token is chosen to be used for other escape sequences as well; being able to use it to include special characters in string data comes to mind. But I'd imagine that it isn't uncommon for ! to be found in string data, and the semantic change would instantly break some or all strings that used it.
« Last Edit: August 20, 2014, 04:18:09 pm by Runer112 »

Offline Hayleia

  • Programming Absol
  • Coder Of Tomorrow
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3367
  • Rating: +393/-7
    • View Profile
Re: Features Wishlist
« Reply #3376 on: August 20, 2014, 11:47:43 pm »
You never use Disp ?  :o
Nope, I most often use Text and sometimes use Output, but never Disp.

Yes, n is more logical for a newline, but would i be more logical for a token not to be interpreted by the parser ? And people are used to i to insert a new line, to introduce a new line, to *lack of ideas*...  ;D
Well I thought that "n" for newline and "i" or "!" to escape was good, not because newline starts with an "n" but because "n" looks like "\n" and "i" and "!" look like "\".

The ! idea crossed my mind as well, and would also be a contender for an escape character. But the issue I have with it is that I'd ideally want it whatever token is chosen to be used for other escape sequences as well; being able to use it to include special characters in string data comes to mind. But I'd imagine that it isn't uncommon for ! to be found in string data, and the semantic change would instantly break some or all strings that used it.
Maybe then you can use one of the tokens that we can find in the "Caractères" menu (available when we use a translating app) ? like the "¿" or the "¡" (not an "i", a reversed "!") for example ?
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

click here to know where you got your last +1s

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Features Wishlist
« Reply #3377 on: August 21, 2014, 12:12:36 am »
I totally forgot that Disp existed in  Axe. I only ever used the home screen about twice in Axe and it was to display score. Other than that I tried to keep everything graphical (otherwise it kinda defeats the point of using Axe instead of TI-BASIC).

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3378 on: August 21, 2014, 07:46:46 am »
Well I thought that "n" for newline and "i" or "!" to escape was good, not because newline starts with an "n" but because "n" looks like "\n" and "i" and "!" look like "\".
I slept on it, and now thinks that I could be good to replace progressively the i token by n for newlines. By the way, here's another idea of feature : i could be used before a token to return the key's index the token is on. We could write "!If K-i5" instead of "!If K-27" and having to learn all the key's indexes. Additionally, "ir5" would return the key's index of the getKeyr function.

The ! idea crossed my mind as well, and would also be a contender for an escape character. But the issue I have with it is that I'd ideally want it whatever token is chosen to be used for other escape sequences as well; being able to use it to include special characters in string data comes to mind. But I'd imagine that it isn't uncommon for ! to be found in string data, and the semantic change would instantly break some or all strings that used it.
Yes, but... there aren't so many solutions, are there ?
We could still find tricks like doubling the ! token means to include it once in the string.


Maybe then you can use one of the tokens that we can find in the "Caractères" menu (available when we use a translating app) ? like the "¿" or the "¡" (not an "i", a reversed "!") for example ?
I don't think this is a good idea : to use these tokens, people would have to install a translating app, 16kb lost, and tokens translated, which is not very convenient for English people. Otherwise, Axe could automatically add this menu in the catalog, which would be a great thing.
I'm french, that's the reason why my English can be a bit approximate.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3379 on: August 21, 2014, 11:33:20 am »
By the way, here's another idea of feature : i could be used before a token to return the key's index the token is on. We could write "!If K-i5" instead of "!If K-27" and having to learn all the key's indexes. Additionally, "ir5" would return the key's index of the getKeyr function.

Considering that almost half of the keys don't correspond to actual tokens and couldn't be looked up in this fashion, it doesn't really seem worth doing this to me.

We could still find tricks like doubling the ! token means to include it once in the string.

The issue isn't providing a new way for the ! character to be used in strings. The issue is that this will break backwards compatibility because some or all programs that use ! in string data will fail to compile correctly, and backwards compatibility has always been a big goal.


Maybe then you can use one of the tokens that we can find in the "Caractères" menu (available when we use a translating app) ? like the "¿" or the "¡" (not an "i", a reversed "!") for example ?
I don't think this is a good idea : to use these tokens, people would have to install a translating app, 16kb lost, and tokens translated, which is not very convenient for English people. Otherwise, Axe could automatically add this menu in the catalog, which would be a great thing.

I agree that any tokens used by Axe should be enter-able without external tools. Maybe it's time for a catalog hook, though... But making sure it works with localization apps might be tricky. Now that I think about it, the current token hook probably doesn't play nice with localization apps. I should look into that.

Offline Hayleia

  • Programming Absol
  • Coder Of Tomorrow
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3367
  • Rating: +393/-7
    • View Profile
Re: Features Wishlist
« Reply #3380 on: August 21, 2014, 11:48:20 am »

Maybe then you can use one of the tokens that we can find in the "Caractères" menu (available when we use a translating app) ? like the "¿" or the "¡" (not an "i", a reversed "!") for example ?
I don't think this is a good idea : to use these tokens, people would have to install a translating app, 16kb lost, and tokens translated, which is not very convenient for English people. Otherwise, Axe could automatically add this menu in the catalog, which would be a great thing.
I agree that any tokens used by Axe should be enter-able without external tools. Maybe it's time for a catalog hook, though... But making sure it works with localization apps might be tricky. Now that I think about it, the current token hook probably doesn't play nice with localization apps. I should look into that.
No need to install a translating app. Just temporarily install one on Wabbitemu for example, create a program with all "special tokens", send that program to your calc and then you just have to recall that program and erase useless tokens ;)
Of course, the catalog hook is a better idea, but with the stupid solution I proposed, the release with the Catalog hook can come after the release supporting "special tokens".
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

click here to know where you got your last +1s

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3381 on: August 21, 2014, 11:59:54 am »
Considering that almost half of the keys don't correspond to actual tokens and couldn't be looked up in this fashion, it doesn't really seem worth doing this to me.
Well, if we take the letters as the key's token, approximately one third of the keys won't be covered... yes, it's still too much. Or maybe use i followed by a number, which is the keycode in TI-Basic ? because they're easy to remember, and it'll help people who programmed in TI-Basic to get into Axe.

Some other ideas : rename the RecallGDB and StoreGDB tokens RecallLCD and StoreLCD, and parse them as "L6:Asm(EF7B4C)" and "L3:Asm(EF7B4C)". They would respectively copy the LCD in the main buffer and in the back-buffer, which has many applications and I'm pretty sure it isn't currently possible in pure Axe.

Also, equivalents of the assembly push and pop instructions could be useful (maybe use the nPr and nCr tokens). Using the APD could be great. Also, Axe Parser could parse "min(A,B,C)" like "min(A,B):min(,C)" instead of generating the "WRONG # OF ARGS" error (same for other functions like this one).

EDIT : "Asm(EF7B4C)" is "BCALL(_SaveDisp)" in assembly, and destroys all registers. "save" and "load" could be nice names for push and pop. Additionally, the execution of the APD could be enabled and disabled during the code, so why not using two tokens, a bit like #ExprOn and #EprOff. And allowing three arguments for min( obviously means allowing as many args as needed by the user  :P
« Last Edit: August 21, 2014, 12:45:35 pm by Zemmargorp »
I'm french, that's the reason why my English can be a bit approximate.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3382 on: August 21, 2014, 03:28:57 pm »
Well, if we take the letters as the key's token, approximately one third of the keys won't be covered... yes, it's still too much. Or maybe use i followed by a number, which is the keycode in TI-Basic ? because they're easy to remember, and it'll help people who programmed in TI-Basic to get into Axe.

The assembly key codes follow a pattern that's easy enough to learn, so I don't think this is really necessary. If I did eventually add key equates, I'd probably do it in a much more traditional fashion where the equates are normal constants like any user-defined constant.

Some other ideas : rename the RecallGDB and StoreGDB tokens RecallLCD and StoreLCD, and parse them as "L6:Asm(EF7B4C)" and "L3:Asm(EF7B4C)". They would respectively copy the LCD in the main buffer and in the back-buffer, which has many applications and I'm pretty sure it isn't currently possible in pure Axe.

Renaming StoreGDB to StoreLCD is definitely a good idea, and it's so easy to do that I just did it. But instead of using RecallGDB, I think it would make more sense to adopt the syntax used by other screen/buffer commands, like ClrDraw and DrawInv, which is to add an r to operate with the back buffer (L3) or to add parentheses to operate with an arbitrary buffer.

Also, equivalents of the assembly push and pop instructions could be useful (maybe use the nPr and nCr tokens).

This already exists in a functional basis as Select(A,B). Although having the ability to do this across multiple lines seems appealing for optimization purposes, providing fully manual stack access would be a language design disaster. Every language I can think of doesn't provide this functionality for this reason. Ideally, the compiler will eventually be smart enough itself to make the kind of optimizations that tempt this design.

Using the APD could be great.

APD control is a nice idea. AxesOn/AxesOff sort of works due to starting with "A" but otherwise don't really sound right. I also sort of like PwrReg/PwrRegr due to actually meaning something about power. If I were to add this, I'd probably also want to add the ability to instantly power the calculator off, so I'd need to think about some way to represent that as well.

Also, Axe Parser could parse "min(A,B,C)" like "min(A,B):min(,C)" instead of generating the "WRONG # OF ARGS" error (same for other functions like this one).

I was just about to say that this is easily doable... and then I remembered that the signed minimum and maximum commands, min(A,B)r and max(A,B)r, exist. That instantly makes it much harder, because the compiler wouldn't know if normal or signed comparisons are needed until after it has compiled all but the final comparison. This means that I'd either need to create some kind of lookahead capability or create special varargs versions of the commands. Although both sound tricky to implement, the second sounds less tricky and might be manageable. But since the ability to chain these commands already exists and this would only be syntactical sugar, I'm probably not assigning this too high of a priority.
« Last Edit: August 21, 2014, 03:31:00 pm by Runer112 »

Offline Hayleia

  • Programming Absol
  • Coder Of Tomorrow
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3367
  • Rating: +393/-7
    • View Profile
Re: Features Wishlist
« Reply #3383 on: August 22, 2014, 01:47:27 am »
Also, equivalents of the assembly push and pop instructions could be useful (maybe use the nPr and nCr tokens).

This already exists in a functional basis as Select(A,B). Although having the ability to do this across multiple lines seems appealing for optimization purposes, providing fully manual stack access would be a language design disaster. Every language I can think of doesn't provide this functionality for this reason. Ideally, the compiler will eventually be smart enough itself to make the kind of optimizations that tempt this design.
The problem with Select(EXPR1,EXPR2) is that we can't put commands such as Copy (for example) in EXPR2, which I often wanted to do in my programs (I don't care much about EXPR1, I always put nothing here). We can work around it with a sub that leads to the Copy but it is kind of a waste. Plus, I don't see why refreining people from using commands directly if they can use anyway it by just wasting 4 bytes.
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

click here to know where you got your last +1s

Offline Vsod99

  • LV3 Member (Next: 100)
  • ***
  • Posts: 70
  • Rating: +1/-1
    • View Profile
Re: Features Wishlist
« Reply #3384 on: August 22, 2014, 02:05:03 am »
An "active topics" section would be nice, especially when looking for no specific subthread in particular.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Features Wishlist
« Reply #3385 on: August 22, 2014, 07:13:37 am »
Erm that isn't really the place to ask for that. You would need to ask at http://ourl.ca/request and http://www.omnimaga.org/site-feedback-and-questions/ for suggestions. But we already have an active topic feature on the forums anyway: http://www.omnimaga.org/recent

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3386 on: August 22, 2014, 09:23:26 am »
Renaming StoreGDB to StoreLCD is definitely a good idea, and it's so easy to do that I just did it.
Great ! Now we need to find a use to RecallLCDGDB  :P

Although having the ability to do this across multiple lines seems appealing for optimization purposes, providing fully manual stack access would be a language design disaster. Ideally, the compiler will eventually be smart enough itself to make the kind of optimizations that tempt this design.
Yes, it's a dangerous command, but advanced developers would then be able to optimize their codes where the compiler isn't smart enough...  :/ But this level of optimization isn't probably needed when using Axe.

APD control is a nice idea. AxesOn/AxesOff sort of works due to starting with "A" but otherwise don't really sound right. I also sort of like PwrReg/PwrRegr due to actually meaning something about power. If I were to add this, I'd probably also want to add the ability to instantly power the calculator off, so I'd need to think about some way to represent that as well.
Yes, but then there's the problem of removing the copy of the program (or at least removing its reference inside the VAT, if it's pointed to in the VAT). And there's also another problem : the APD uses the RAM area L1, doesn't it ?

I was just about to say that this is easily doable... and then I remembered that the signed minimum and maximum commands, min(A,B)r and max(A,B)r, exist. That instantly makes it much harder, because the compiler wouldn't know if normal or signed comparisons are needed until after it has compiled all but the final comparison.
Ah, I see ! Neither did I think of it.

Something else : would it be easy (I don't think so, but I still want to write the idea) to add instructions a bit like #ExprOn and #ExprOff, called #1byte and #2bytes, who force Axe Parser to use A instead of HL for calculations ? Because sometimes only 1 byte is needed, for example and E3C becomes (instead of AND $3C) :
Code: [Select]
LD    H, $00
LD    A, L
AND   $3C
LD    L, A


EDIT : I wrote "use A instead of HL", which means that accessing memory with the curvy brackets {} won't be possible, exceptions being if there's something like {...+GDB0}, where "..." is necessarily a one byte value. Also, it would still be possible to use the variables.
« Last Edit: August 22, 2014, 09:53:20 am by Zemmargorp »
I'm french, that's the reason why my English can be a bit approximate.

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3387 on: August 23, 2014, 10:03:18 am »
Some other ideas :

The token Clear Entries (found in the MEMORY menu) could remove temporary variables (I think that the result of input is stored in a temporary variables, isn't it ?). Also, ClrAllLists could be used to initalise the free RAM areas, from L1 to L6.  (See the BCALLs CleanAll and BufClr.)

I found two different ideas of use for Then : either it could be used to say that the following tokens of the same line should be interpreted only if debugging (by debugging I mean compiling with Zoom), or it could be used to optimize conditional jumps. In this last case, the Then should be used right after a If condition, and should be followed by a Goto instruction : this is roughly the equivalent of ReturnIf, but for jumps. There are some optimizations in assembly to do when Ifs are used to jump only.

What else... Adding a token (something like FullString) to ignore the split-screen modes, a token to generate custom error messages (I can't rememer the BCALL's name), why not using a token like Param which returns the calculator's type (TI-83+, 83+ SE, 84+, ...), another to check the battery level... I think I haven't forgotten anything  ;D  !

By the way, if one day floating numbers are added to Axe, the tokens associated with the variables could be the matrix tokens (from [A] to [J], that is to say 10 variables, and 90 bytes required).
I'm french, that's the reason why my English can be a bit approximate.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3388 on: August 23, 2014, 11:52:14 am »
Although having the ability to do this across multiple lines seems appealing for optimization purposes, providing fully manual stack access would be a language design disaster. Ideally, the compiler will eventually be smart enough itself to make the kind of optimizations that tempt this design.
Yes, it's a dangerous command, but advanced developers would then be able to optimize their codes where the compiler isn't smart enough...  :/ But this level of optimization isn't probably needed when using Axe.
If you're advanced enough of a developer that you want manual stack control, inline assembly provides that capability.

APD control is a nice idea. AxesOn/AxesOff sort of works due to starting with "A" but otherwise don't really sound right. I also sort of like PwrReg/PwrRegr due to actually meaning something about power. If I were to add this, I'd probably also want to add the ability to instantly power the calculator off, so I'd need to think about some way to represent that as well.
Yes, but then there's the problem of removing the copy of the program (or at least removing its reference inside the VAT, if it's pointed to in the VAT). And there's also another problem : the APD uses the RAM area L1, doesn't it ?

As far as I can tell, you don't need to do anything special for APD to work properly besides enabling it and having the OS interrupt running. I imagine the hardest part of using APD successfully would be making sure other commands used while it's running don't turn it off, whether by disabling interrupts or actually turning off the APD running flag. And yes, APD does write the contents of the screen to L1 when turning the calculator off. I'm pretty sure that's unavoidable.

Something else : would it be easy (I don't think so, but I still want to write the idea) to add instructions a bit like #ExprOn and #ExprOff, called #1byte and #2bytes, who force Axe Parser to use A instead of HL for calculations ? Because sometimes only 1 byte is needed, for example and E3C becomes (instead of AND $3C) :
Code: [Select]
LD    H, $00
LD    A, L
AND   $3C
LD    L, A

The current iteration of Axe is entirely built around HL doing everything, so no, this wouldn't be very feasible to add right now. It's been suggested at least once before and is on a to-do list, but is waiting for for the theoretical Axe 2.0 with support for actual data types to break the shackles of everything being a 16-bit int.

The token Clear Entries (found in the MEMORY menu) could remove temporary variables (I think that the result of input is stored in a temporary variables, isn't it ?). Also, ClrAllLists could be used to initalise the free RAM areas, from L1 to L6.  (See the BCALLs CleanAll and BufClr.)

Being able to remove all temporary variables is of course very easy to implement because it's just B_CALL(_CleanAll). But to be cautious of feature overload, may I ask in what context you imagine an Axe programmer would use this command? Temporary variables should be cleaned up by the OS when execution of your program starts and ends, so I can't think of any reason a program would want to mass delete its temporary variables... except for a shell program that's cleaning up after executing another program, but since vanilla Axe lacks the ability to do many things a shell programs needs already, this doesn't seem like a good enough reason to add it.

As for initializing all free RAM areas (to zeroes, I'm assuming): why? I can't imagine a case where this would be necessary. I can only think of a few use cases in which you'd need to initialize any single RAM area to zeroes, and I can't imagine them being needed so severely as to use all six free RAM locations. Even if you did need this, you can clear them manually using a few ClrDraw's and Fill()'s, which is basically all a native command would be doing anyways.

I found two different ideas of use for Then : either it could be used to say that the following tokens of the same line should be interpreted only if debugging (by debugging I mean compiling with Zoom), or it could be used to optimize conditional jumps. In this last case, the Then should be used right after a If condition, and should be followed by a Goto instruction : this is roughly the equivalent of ReturnIf, but for jumps. There are some optimizations in assembly to do when Ifs are used to jump only.

Programmers can already use preprocessor conditionals with custom constants to change what code is compiled by simply changing a constant. This can be used in place of knowing the optimization level (which generally doesn't seem like a good idea anyways, as the system for how programs are compiled/optimized is always subject to change).

Optimizing if statements that simply perform jumps has been looked into before, but the compiler currently lacks lookahead parsing and a strong peephole optimizer. If either of these is added (which isn't too likely to happen soon because I'm still quite unfamiliar with how the compiler works), then this optimization will surely be added as well.

What else... Adding a token (something like FullString) to ignore the split-screen modes...

Like Fullrr?

... a token to generate custom error messages (I can't rememer the BCALL's name), why not using a token like Param which returns the calculator's type (TI-83+, 83+ SE, 84+, ...), another to check the battery level... I think I haven't forgotten anything  ;D  !

These all sound very shell-y, which Axe does not aim to natively provide features for. There would be too many features that would need to be added to allow for this very specific type of program to be made in vanilla Axe.

By the way, if one day floating numbers are added to Axe, the tokens associated with the variables could be the matrix tokens (from [A] to [J], that is to say 10 variables, and 90 bytes required).

Like 8-bit ints, floating point data types would be added in the theoretical Axe 2.0. You could then name your floating point variables whatever you wanted, like basically every other language.
« Last Edit: August 23, 2014, 11:57:40 am by Runer112 »

Offline Zemmargorp

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 115
  • Rating: +7/-2
  • Either programming or thinking of it.
    • View Profile
Re: Features Wishlist
« Reply #3389 on: August 23, 2014, 12:52:55 pm »
As far as I can tell, you don't need to do anything special for APD to work properly besides enabling it and having the OS interrupt running. I imagine the hardest part of using APD successfully would be making sure other commands used while it's running don't turn it off, whether by disabling interrupts or actually turning off the APD running flag. And yes, APD does write the contents of the screen to L1 when turning the calculator off. I'm pretty sure that's unavoidable.
So if I want to use it I just need to use the OS's BCALLs EnabledAPD and DisableAPD ? Good to know. As L1 is 768 bytes long, I believe the APD uses it to store a copy of the LCD ? Like StoreLCD(L1) does ? Hmm... it'd be great to find a way to exchange L1 and L6 just before and after the APD runs.


The current iteration of Axe is entirely built around HL doing everything, so no, this wouldn't be very feasible to add right now. It's been suggested at least once before and is on a to-do list, but is waiting for for the theoretical Axe 2.0 with support for actual data types to break the shackles of everything being a 16-bit int.

I'm afraid to imagine how hard it'll be...


Being able to remove all temporary variables is of course very easy to implement because it's just B_CALL(_CleanAll). But to be cautious of feature overload, may I ask in what context you imagine an Axe programmer would use this command?
If the temporary variables are removed before and after the program's execution, then there's no problem.


As for initializing all free RAM areas (to zeroes, I'm assuming): why? I can't imagine a case where this would be necessary. I can only think of a few use cases in which you'd need to initialize any single RAM area to zeroes, and I can't imagine them being needed so severely as to use all six free RAM locations.
I don't know why it'd be needed, but it may be used one day, as it's not completely useless. I had this idea when I saw the token ClrAllLists, as sometimes clearing RAM areas to zeroes is needed, and sometimes programs use several RAM areas.


Optimizing if statements that simply perform jumps has been looked into before, but the compiler currently lacks lookahead parsing and a strong peephole optimizer. If either of these is added (which isn't too likely to happen soon because I'm still quite unfamiliar with how the compiler works), then this optimization will surely be added as well.
In short, achieving adding a lookahead ability would improve the parser a lot  :P


Like Fullrr?
Exaclty ! Sorry, I didn't know it already existed... *Looking for it...* Oh, but it's quite recent !


These all sound very shell-y, which Axe does not aim to natively provide features for. There would be too many features that would need to be added to allow for this very specific type of program to be made in vanilla Axe.
It's a pity...


Like 8-bit ints, floating point data types would be added in the theoretical Axe 2.0. You could then name your floating point variables whatever you wanted, like basically every other language.
Ah... Nevertheless, for code readability, differentiation of types in the variable's name would be better.
I'm french, that's the reason why my English can be a bit approximate.