Yeah, I will need to rewrite the graphics commands, but so long as it can run z80 code, the rest shouldn't be tough to convert.

I am not exactly sure of what you mean, sorry Grammer 2 doesn't compile anything, so I am not sure where that would help out at the moment (but compiling is in the plans for Grammer 3). However, there are tricks for working with labels to make them faster, such as precomputing their location and storing them to point variables. This way, you don't need to constantly look up labels.

Sorry for interrupting the conversation (Soulthym ? Un étudiant français qui fait du Grammer ? Serions-nous deux ? ), but I have an idea...

I saw what you have done with your app 'Tutor' Xeda, and I thought it could be very useful in Grammer.

I explain:
Imagine the user sets a list of keycodes that would be automatically pressed the next time the calculator will be waiting for a signal from the keyboard, we could make:

• pre-recorded answers to Inputs
• cheatcodes in games to control automatically the player/object-to-move
• We could use this to allow the player to make tiny macros in a game, without modifying the source code

In the same way, but much less useful because it can be easily done yet with getkey, create a function that records what key are pressed to make an history.

With this two functions, the user could record a manipulation and re-do it many times automatically.

No matter, maybe I'll be working on that during holydays^^(is it possible to have the grammer source in asm?)
Edit:Maybe it could be implemented in an alternative version of Grammer 3(like Grammer 3 precompiling version)

Thank you a lot!
Edit: I just thought: Why not including plugins( like mimas does for example)?

@persalteas : et moi, je compte peut-être pour du beurre ? Certes, je n'ai absolument rien fait et ne connais ce langage que très partiellement... Mais je soutiens totalement le projet et développerai peut-être des trucs lorsque j'en aurai le temps !

@Xeda:
When we call a label, it needs time to find it. We can put the address in a variable, but it needs memory and a new name for each label. So why not add a new type of label being automatically parsed at the start of the program so that the application doesn't have anymore to parse it each time it is called ? For example, such a label could be declared as :

..LABEL
And when we do "call LABEL" or "Goto LABEL", the address will be stored for all the program execution.

PS : why not include to your .zip persalteas' tutorial ?

Hehe, that is something that I am already working on (I even have had code for almost a 10 months in Grammer for this).

Ans why not do so that this function is enabled for "." and disabled for ".." instead ? Labels which location doesn't have to be stored are rare and are used only when there's lots of SMC.