I think you should give Grammer a different syntax(keep backwards compatibility, though) Some of it is just so confusing(Y before X?! WTF!?) Another idea is to add "header files" like in higher level languages so that you can have whole bunches of routines for complex stuff already set out for you(like collision checking, for example). Some of these might be dumb because i'm kind of a noob at grammer

Y before X is because in TI-BASIC many commands are that way too. Grammer was made specifically to get TI-83+ BASIC coders used really fast to it.

Yes, precisely, like with the Pixel commands and Text( in TI-BASIC.
And I am not sure I understand header files, but does this sound useful:

I have planned for Grammer 3 to keep the last 16 tokens for an extended command set. In TI-BASIC, there are a handful of two-byte tokens which is basically what this is. The difference, though, is that you can load different command sets into your program. For example, if a command set is made for 3D rendering, called 3DRender, you might do something like:
Ext0 3DRender
I haven't quite gotten down how I want to incorporate this code-wise. I will want to let the user install command sets as either appvars or apps, but I will have to have some format to tell Grammer what arguments each command can take Grammer also has some pretty high-level variable structures like n-dimensional arrays, actual string support, sprites, bit-maps, integer math and there are still a few more types that I am working on like Floating-Point and fixed-point math. The editor is just a real pain, still The format that I currently have, though, makes it easy to jump to sections of code and edit things like sprites in-line

Oh, yes, that might be useful (the header thing). As well, floating point numbers are a different type from integers. Integers also have signed/unsigned, and 8,16,32, and arbitrary sizes.

ben_g: Look up 3 posts.

Extensions for 3D and stuff would be nice, although I wonder what would be the format. Would they be appvars? Because some people might confuse them with the game program files if they're also programs and delete them if they decide to delete the game.

Yeah, that is what I am worried about. Basically, for the extensions, the appvar/app/program would need to contain all of the code for handling certain commands. I am pretty sure that I have gotten a good format for calling the extended commands, the difficulty is in compiling the programs that use extended commands. Actually, this is the same problem for built in commands, too . I could manually create a Grammer 3 program at the moment, but having a compiler would be much less tedious. Basically, for something like the Rect() command, this:
Rect(X,Y,8,8,2)
Needs to be converted to:
20        ;20h = Rectangle command
10 0000 ;10h says it is a 1-byte integer, 0000 is the compiled offset into the integer table
1F        ;ends the argument. Think of this like a comma.
10 0100  ;another 1-byte integer
1F
08
1F
08
1F
02
1E      ;end the command. Basically an ending parentheses
So I know what it is supposed to compile to, it is just that I need to work up the motivation to create the compiler I actually started writing the compiler a few months ago in Grammer 2 code after I added in the new Input command with syntax highlighting.

yes, I am sure it will and that is what the extended commands are (multi-byte tokens, basically). So for example:
F800     ;Command 0 of one of the extended token sets
I was also trying to figure out a good way of allowing the extended sets to have extended tokens just in case, but I don't think I will need to do that (will we really need 3-byte tokens? )