You never use Disp ? 

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*... 

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 ?

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, "i^r5" would return the key's index of the getKey^r 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.

Quote from: Zemmargorp on August 21, 2014, 07:46:46 am

Quote from: Hayleia on August 20, 2014, 11:47:43 pm

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".

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 "L₆:Asm(EF7B4C)" and "L₃: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 (L₃) 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/PwrReg^r 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.

An "active topics" section would be nice, especially when looking for no specific subthread in particular.

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 

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/PwrReg^r 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 L₁, 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) :
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.

Quote from: Runer112 on August 21, 2014, 03:28:57 pm

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.

Quote from: Runer112 on August 21, 2014, 03:28:57 pm

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/PwrReg^r 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 L₁, 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 L₁ 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 L₁ to L₆.  (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 Full^rr?

... 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    !

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.