3-bytes tokens are really a PITA to work with, and you won't be able to use the token hook with them.

Or maybe ... Let's have an example : say that the first token (which should be a 2-bytes one because rarely used) of a pack is det(. You would apply a token hook on det( to make it look like (for example, with a 3D renderer pack) "3Drender_". Then you could apply a token hook on other tokens which will be the actual commands. So for example the command det(Boxplot which is the first command of the command pack, would look like 3Drender_tri( with a token hook and F005 as hex (since det( is the prefix of all of the commands of the first command pack).

So with all of this, we can define the structure of a command pack :.dw prefixToken
.dw command1token
; define everything related to a command
.dw command2token
...
.dw $4242 ; magic number which ends the command definition
; token hook
Something you can do with it is dynamically assignating the F0 to FF token to the corresponding prefix. It would allow the use of multiple command packs without any problem.

What do you think of it ?

i'm keep forgetting if Grammer had a and/or/xor logic for recalling picture.

Yes, RecallPic has those abilities, currently and that will definitely be still around for Grammer 3. I might have separate tokens like xorSprite(), though.

EDIT: @Sorunome: Grammer 3 has a variable type for sprites, so definitely. Also, I like the idea of having static pointers and about the logic, I should do that for sure. Maybe I will have bitand, bitor, and bitxor instead. Currently, you no longer need to use + or *, as long as your tests produce a 1 or 0. For example, this works as you would expect it:
If A=3: and B=7
You just need a colon between tests.

It is kind of like a newline, but not really. You can use a colon in conditions for If, While, and Repeat, among other things. A colon just separates chunks of math.

I am not familiar with Java or the terms "structured variables" and "objects with methods." However, maybe this will answer your question:

In Grammer 3, there will be a few variable types such as:
Sprites - These get stored at the end of the file and have a size automatically associated with them. This means that the sprite command will work like this: Sprite(ptr,Y,X,Buffer)
Strings - These will have two forms, ASCII or Tokens.
Arrays - There will be a few forms such as fixed size arrays or the more flexible variable arrays (each element can be any variable type, including strings, numbers, sprites, or other arrays)
Integers - There will be signed, unsigned, and different sizes. Currently it only has 8-bit and 16-bit unsigned.
Fixed Point -  These will be used for extra precision and will allow you to store numbers such as 2.3125

The actual details are really cool and I started working on the program editor earlier today. For example, the attached image (I made it in paint; it is not real) shows how sprites will be in-line and you will be able to directly edit them. But the really cool part is that the two sprites are the same sprite. Editing one automatically edits the other and any other instances of the sprite in the program. Here is how it works:

There will be local and global variables. Local variables will have a bunch of data stored about them within the program such as their name and the actual data. Local variables include labels, too. Each variable will have a 2-byte ID. When the editor reads the bytes, it will display the name of the variable if it has one. If it does not have a name, the contents of the variable are shown instead. In the editor, if you have highlighted the variable name/data, you will be able to edit the variable data (the program editor will know which var to edit based on the ID). So this means you can edit the name of the variable and all instances in the program will be changed automatically since it is only referred to by an ID. This also means if you use the same string multiple times, changing it in one place changes it everywhere else (as an example).

When running the program, if it is already in RAM, it will just be run directly. If the program is in archive, only the essential data will be copied to RAM. I am still trying to figure out what counts as 'Essential', though. Obviously the variable/label names wouldn't need to be copied since that is just for the editor. But as long as everything else is static data, I might be able to have Grammer keep the whole program in archive.

Oh, also, subroutines are a type of variable. For example, "Repeat " won't be a real command. Internally, it will just be stored as:
Lbl Repeat
     Call Subroutine
     If <condition>
          Goto Repeat
But in the editor, it will look like a Repeat loop.

I think automatically changing the variable names is dangerous--it's super helpful to do that, but sometimes I just want to change the name one time, and not the rest. There should be a way to refactor it, but doing it automatically could lead to frustration.

Wow, displaying the sprites inline in the editor looks awesome

Wow, the editor is EXACTLY as I dreamt it to be ! The sprites, the edition of variables' names... !!! 

I am glad you like the look ^_^ I am about to start coding some more, so hopefully I can make it work the way I envision it!

For the Repeat command, it could be an bad point though, because the speed would decrease doing so.

It would actually still be fast since this is how Repeat loops are typically handled anyways. I am doing it this way because it will help to prevent stack overflow issues. Math might change, too, by the way. I am still working out how I want to efficiently handle math. I will probably attempt Order of Operations so you can do something like 3+6*(a+b⁴) like you would in BASIC.

I hope we'll be able to "compile" a program in order to delete variables' names so that the program has a smaller size.

This is an excellent idea and I was thinking about doing that. The way it is currently set up, it is very easy to separate the names from the program which could save a bunch of memory. As well, a few other tokens can be removed to save a byte here and there (and the source will still be able to be edited).

And maybe could you do a 1-page application which doesn't have the editor but that can run Grammer programs ? Because 2 pages are a lot for persons who just want to run the programs...

I was thinking about this and I at first thought I might be able to make one app for the editor, and one app to run the program. However, I was going to add a lot more commands to Grammer 3, so the parser would still need 2-pages Then you would have a 2-page app for running Grammer programs and a 1-page app for editing them. Instead, I will try to make it just 1 app that is 2-pages.

I assume that bigger sprites will be given a name in order not to take all the screen's place. :p

If the sprite is too big, I will have it display maybe a 16x16 portion and if the user wants to use edit it, a special editor will open.

I hope that the text "Program : TEST" will be removed to have one more code line.

That is a good idea. I will probably still stick menu options on the bottom row, though For example, 5 options for F1~F5:
[Char][Set ][Calc][Copy][Exit]
Char will let you access the character set (so the ASCII)
Set will allow you to load an external command set. So if anybody makes a Physics package, for example, you can load the Physics commands and view the token set for that.
Calc Will open up a calculator window so that you can run a simple computation like 3*47+6(7* and paste the result into your program.
Copy Will be for copy/paste stuff.

Grammer 3 promises to be a really really good app. Thank's !

I hope I actually finish it! I have been planning for over two years now, so hopefully you will get a chance to finally use it!