I think you could display it pretty intuitively with one-symbol things. Like, if you have xorSprite(, it shows up as xorSprite(->,#,#) meaning pointer, number, number. $ could be string.

Oh, that would be a nice way to do it, thanks!
I also have to figure out where to display it as the user enters stuff, but maybe I can just do it the way the TI-89 does it and just display the arguments in the catalog.

As for updates, I now have the code for actually displaying the code in the editor almost done. I have to program in the exception for handling sprites and I have to program in some dummy tokens, but then it should display properly.

I have a few other things that will distract me, so an actual screenshot might not be around for a while.

One of my other worries is how well this will work with something like Tokens since the editor also doubles as a compiler and does a lot of heavy-duty stuff in the background. I was thinking I would have to make a converter on calc to convert the file to the proper syntax.

Hmm, so you're not just storing the raw tokens? I've been planning on adding some sort of translation layer plugin support to support stuff like BBC BASIC, so that might be the right way to do that. Though a way to save the raw syntax is probably advantageous as well.

Yes, that is mostly right. Most of the tokens used translate directly to a single byte. For example, xorSprite() is represented by a byte, RefreshLCD, ClrDraw, and others. However, numbers are stored like this:
1 byte ID for the type of number (signed,unsigned,FP,8-bit,16-bit,24-bit,32-bit,arbitrary size, et cetera)
n bytes for the pre-computed value

So for example, an 8-bit unsigned integer would be 01xx in hexadecimal, but it would appear as just a decimal number in the editor.

In each program, there is an LUT for the pointers to the local variables and another LUT for their names. Variables are 3-byte tokens at the moment, but I have not finalised it so I might move it down to multiple sets of 2-byte tokens. Anyways, it is currently 1E followed by a 2-byte ID. That ID is directly used to access the LUT (the names LUT while editing, the data LUT while parsing). Whenever a variable is edited or code is inserted, the LUTs get updated with the correct pointers. So essentially, these are tokens that are not fixed with a name but are defined by the source.

As well, some tokens are only there for the editor and get completely ignored by the parser. Also, 'labels' are really just the names of subroutines which are included in the variable LUTs.

This is a bit convoluted :/

This isn't as awesome as I had hoped it to be. I took a break from the editor and started work on the parser. This has proved useful since it gave me a better idea for how I should parse code and this is vital for figuring out how I should store the syntax for commands when in the editor. Anyways, all I did was insert the parser into the existing Grammer 2 app (I had to remove unneeded code to make room) and I leached off the routines already present. Hopefully this is causing the code to be slow (because it is not optimised for the Grammer 3 parser), because from this screenshot, we see that Grammer 3 code is only a little faster than Grammer 2 code (about 20% faster):


Hopefully I can make it a bunch faster and I also found something that I need to fix in Grammer 2. I used 'rr b' instead of 'srl b' directly before using a djnz loop and in half of the cases, this caused an excess of over 2000 wasted cycles (for comparison, it should have been at most 114 cycles).