0 Members and 1 Guest are viewing this topic.
You never use 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*...
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.
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 "\".
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 ?
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.
We could still find tricks like doubling the ! token means to include it once in the string.
Quote from: Hayleia on August 20, 2014, 11:47:43 pmMaybe 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 amQuote from: Hayleia on August 20, 2014, 11:47:43 pmMaybe 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.
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).
Quote from: Zemmargorp on August 21, 2014, 11:59:54 amAlso, 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.
Renaming StoreGDB to StoreLCD is definitely a good idea, and it's so easy to do that I just did it.
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.
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.
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.
LD H, $00LD A, LAND $3CLD L, A
Quote from: Runer112 on August 21, 2014, 03:28:57 pmAlthough 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.
Quote from: Runer112 on August 21, 2014, 03:28:57 pmAPD 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 ?
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, $00LD A, LAND $3CLD L, A
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 !
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).
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.
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.
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?
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.
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.
Like Fullrr?
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.
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.