It is very important you read all of this before you vote.  This is a crucial part to the future of Axe Parser.

The original concept behind going through the trouble of renaming some of the Tokens is that I am very quickly running out of intuitive TI-BASIC tokens to use for more complicated Axe Commands.  I've often resorted to using the ^r or sometimes even the double ^rr but that's not going to cut it soon.  In this last version, I was all out of sprite tokens, so I used what was left in the drawing menu: Tangent().  The name has no meaning to the intended function and may force one to read the documentation before figuring out what it might be used for.

This is okay though.  I realize that a lot of TI-BASIC programmers are used to their tokens and they know where they are on all the menus lightning fast.  If you hear the word "Str1" you might immediately think "[VARS][7][1]" as I usually do.  But if you hear "Bitmap()" you have no idea where it might be.  The catalog isn't in alphabetical order either so that doesn't help much (maybe I can change that with hooks in the future but I'm unsure).  So there is a concern that you have to learn new shortcuts.

There are many many new commands still to come.  For my example, I will mention the commands for reading from archive.  There would need to be an openfile and a readbyte command.  It is entirely possible that I just use maybe log() to open the files and prod() to read a byte, there is no problem with that.  But I imagine the code is much more readable with Open() and ReadByte() for instance.  This is not an isolated case, there are more than 20 other commands I can think of that don't have any meaningful tokens.

One other advantage of renaming some tokens is that often in BASIC, commands such as int() have totally different uses in Axe.   This can ease any potential misuse since the new names imply that the interpretation of the commands have changed.  While tokens that have the same name will be interpreted as working the same way in both Axe and BASIC.

So, if I start using the new token names, then that raises the new issue of documentation.  Sure, it may be possible to document both in the commands list, and maybe even the user's guide, but not having a single standard can get very confusing when reading other people's source code, writing your own tutorials or routines, and even regular conversations like asking for help and fixing code.

I could still offer the option of using the old tokens but just have them minimally documented (like a simple table that tells you the equivalences between tokens).  That way, it encourages the new standard among the forums and when documenting the code.

If I have the tokens be completely "Mandatory" then I can hook the program editor so that the tokens are automatically enabled when editing Axe programs and then automatically disabled when you quit to the home screen or edit a regular TI-BASIC program.  There could be an option to toggle this behavior in the parser even if the old names names are documented or undocumented.

The last thing I'm going to throw out there: These are only name changes.  The actual position in the menus for each token does not change and all past and future source code is totally compatible since the tokes themselves are still the same, only the physical letters displayed on the calculator are affected.

Please ask more questions if you want clarification on something or want to bring up another point.  You can change your vote at any time.

Yes, except the commands list and stuff would be all the new token names and there might just be one additional chart for conversions.  But all other example code and documentation would be with the new tokens.

As best as I can yes.  Its going to be confusing to write documentation through if I have to make extra columns or I would just have to clarify which token naming set the doc is using.  The thing to keep in mind with this option though is that many people are going to be using either the new names or the old ones so as long as you're okay with knowing that you may receive the help in either of the 2 spellings and know how to convert them.

Source code written with one token spelling set is obviously readable with the other don't forget so that part makes no difference.

As best as I can yes.  Its going to be confusing to write documentation through if I have to make extra columns or I would just have to clarify which token naming set the doc is using.  The thing to keep in mind with this option though is that many people are going to be using either the new names or the old ones so as long as you're okay with knowing that you may receive the help in either of the 2 spellings and know how to convert them.

Source code written with one token spelling set is obviously readable with the other don't forget so that part makes no difference.

Ah ok. Well before making an offer that I am thinking I need to get something straight. All the new tokens are doing is just changing the name of the previous token, correct? Like if you write something in Axe the "old" way and then toggle the new tokens on the program will act and work exactly the same but the source just displays the new tokens.

Might be an idea, but make Alpha+Vars a menu instead of a trigger?

You know, like Omnicalc. If you press prgm twice you get a special omnicalc menu with all their tokens.
Maybe you should make such a menu under Alpha+Vars, would defenitely increase the ease on finding those tokens

Actually I think that [ALPHA][VARS] should remain the trigger but, like you said, pressing [PRGM] twice (while triggered) will bring up a catalog for the new tokens (instead of reordering the previous one to be alphabetical).

I personally don't like the idea, because Axe has been using


Otherwise, in worst case scenarios, you could maybe change only, and I really say only tokens that were not used in previous versions of Axe (such as Tangent) and use the exact same starting letter so it's sorted properly in the Catalog (assuming Tangent() is for large sprites, Tallsprite() or TallTile() could maybe do). Conj(), Repeat and the like should remain named as they are, IMHO. Also, think about people who are gonna give help to newbies, they will tell people to use Conj() but newbies will not see Conj() listed in the command list or will need to search more.

I personally would leave things as they were, otherwise. Think also about the users who are used a lot to TI-BASIC tokens and may forget to switch back (altough maybe a check could be done to detect if a PRGM is Axe or BASIC), I wish them good luck debugging their large BASIC game until they find out. Also some people has trouble getting used to new stuff when they were used to something else. (like me)

Had Axe been using such token change since the very beginning, I would have been fine, but now most people got used to the current names.

Leaving things as they were would also prevent potential issues with future TI-OSes and third-party APPS releases for short periods of time before Axe is updated.

Remember what happened to TI-BASIC games that uses inverted text (white fonts on black background), Omnicalc features, xLIB as a whole and Door CS betas when OS 2.53MP came out. Notice how Ndless only runs on OS 1.1 on the TI-Nspires. Remember how Illusiat 6 will not run correctly on OS 1.15 or later (due to the OS ASCII map having been changed). Sadly, we are dealing with Texas Instruments here. We never know what kind of OS they will throw at us in a year or two. I also remember third-party apps conflicting between each others as well. Example: Français APP with old versions of Omnicalc.

The actual doc is easy to do.  I can very easily "add another column".  But at the same time, I want to make things as simple as possible.  2 separate pdfs in the same zip file seems like its separating the Axe community in half and also there are probably only 1 or 2 commands in there that need changing at all.  Its not MY documentation that I'm concerned about becasue I have complete control over that.  Its how others will document their code and their tutorials, etc.  Should they really have to make 2 versions to appeal to 2 crowds is the question.

Not all the new tokens I'm keeping by the way.  "Repeat" I realize is best left alone since it functions very similarly to BASIC.  Others like "sign{" would likely be kept.

Ah ok, gotcha.

Speaking for myself here, but once the Axe tokens become more widely spread and such I will be taking the time to just go through and change things for both versions so everyone can read it and all. I would say that the TI tokens would be easier in general for documenting though since the Axe tokens are not widely known and such. Plus, once you type something in with the TI tokens then just toggle the Axe tokens on you can then see the new tokens to help understand if you previously didn't (and really vise-versa too but ya).

What would be a really cool little utility for a computer would be so that when you transfer Axe source to the computer you can run it through a program that will display the original program as it is (with TI tokens) and then a little window separator that just simply changes the tokens to the Axe ones. That way it'd be really easy for people to just post both sets of code and such. I have no clue if that makes sense but ya.

@Magic Banana
If [PRGM] or [VARS] didn't work, [STAT] could be used.