I had to do that in Pyoro for the scores.  The main reason was because regular font will not display correctly in the grayscale engine I made, and to make drawing as fast as possible in the least amount of memory, aligned 8x8 sprites are the way to go so I had to make my own number font to fit this size.  It was 7x8 instead of the standard 5x7.

Data is data.  String = Picture = List = Hex.  It also equals executable code, but that part is my job 

You can use strings however you like.  You would probably use decimal numbers or hex code for a tile map, but if its more convenient, then yes you can use a string as well.

Hmm, I was wondering, could Celtic III style program control be added? So like, calling another program, getting a list of programs, creating a program, deleting a program, etc.
Also are you planning in adding string operators? Like sub() inString() and such?

Its too soon to tell.  I'm not sure if I will have commands for program manipulation, but there will definitely be a way to create, save, and load application variables.

String handling is going to be very different since all strings are constant length.  It is very easy to get a substring if it ends at the normal ending, you can just do Disp Str1+A.  For anything else, you can write your own subroutine to copy part of the string to a buffer and then display the buffer instead of the string.  I can probably automate this but I would use a different command instead of sub().  Its still faster than the TI-BASIC sub() command.

Good news!  After a very gruesome debugging session (but not as brutal as I've had before), I've finally finished rewriting the entire symbol table handling.  I think it works now, at least, it hasn't failed me yet and it runs past example programs fine.  Definitely expect the next release on time, but I've got far too much to do before I can start adding sprite support, that will have to wait just a bit longer.

Unfortunately, do to the limitation of the calculator's available RAM, I am pretty much going to have to re-write the entire core of the program.  No one has notice the problem yet because all the example programs are small and don't require a lot of user specified data.  Once you start getting into medium and large sized programs, it will become a very big issue.

I will share the method I am using, the method I am planning on using, and other methods I've thought of to to see if maybe someone has a better idea before I start rewriting it.

THE OLD METHOD
The old method was to do a single pass.  Every time a label or name is encountered, it is added to the symbol table so that at the end of the programs, all the symbols are replaced.  All declared data like strings, pictures, sprites, and lists are added to the end of the program as it is being written and also to the symbol table.  The symbol table can only hold 150 entries and it really can't be expanded beyond that by much so that means you can only have 150 combined:

• Labels
• Name declarations
• Name references

ALTERNATIVE METHOD #1
Store all the data at the beginning of the program, that way once a variable is defined, you know exactly where the data is (since the expansion of the program doesn't push the data down further) so that way you don't need to add name references to the symbol table.  The down side is that now the labels are going to be pushed down as data is added to the top so I need to add all the label references  as well.  Also, a 3 byte increase in program size.  So 150 combined:

• Labels
• Gotos
• Name declarations

ALTERNATIVE METHOD #2
Same as alternative #1 except that the programmer is forced to define all variables at the beginning of the program instead of allowing variables to be defined within the program.  That way, the labels don't get pushed down as the program is being created.  Its kind of a slight inconvenience to the programmer though, and you would almost surely want to define the variables in a separate subprogram so that you don't have to keep scrolling all the way down to edit your code.  150 of:

• Labels
• Name declarations

THE NEW METHOD
2 passes are made.  In the first pass, all name declarations are skipped and name references are left blank so that no data is being added to the end of the program.  That way, only labels are kept track of the first pass.  Then on the second pass, the opposite happens.  All regular code is skipped, since it already was written in the first pass,
but all data is written to the end where it won't ever be pushed further down, so I don't need to keep track of references.  Disadvantage is that compiling will take about 1.5x longer and also I have to rewrite most of the core, but I think these leave a far more reasonable amount of variables:

150:

• Labels

AND 150:

• Name declarations

Don't forget, arrays of sprites count as 1 variable.  So if you have 20 8x8 sprites each representing a number on a grid, you can just store all of them consecutively to Pic1 and then reference them as Pic1, Pic1+8, Pic1+16, etc. or even Pic1+A.  Theoretically you can do this with strings too, but its a little harder since each string is probably a different size and you also have to take the terminating character into account.

By the way, I am considering adding the ternary operator to take the burden off of quick if statements.

The syntax will like this:

statement ?( expression1 , expression2 )

If the statement is true, the expression becomes expression1, if it is false, it becomes expression2.  So for instance:

A<B?(A,B)

Returns the minimum of A and B.  It is equivalent in BASIC like this:

:If A<B
:A
:Else
:B
:End

So quick things like

:If K=15
:A+1->A
:End

can be written like this:

K=15?(A+1->A,)

If you want 5 | 2, then you can do "5 or 2".
If you want 5 || 2, then you can do "5≠0 or 2≠0" since this is basically what a Boolean "or" would do for you anyway.  While I agree it could be made more efficient by a c style Boolean operator where the second argument may be skipped if it does not need to be checked, I don't think its worth it.  You're almost always going to use "or" and "and" when comparing two expressions that already have some type of equality operator.  I think the introduction of 2 different types of "or" will just confuse many programmers and make the coding more complicated since there would have to be some weird way to differentiate the two.

But now that I think about it, maybe I should make the regular "or" "and" "xor" the Boolean versions (like basic) and then add new commands for the bitwise operations.  I'm thinking to use the plot symbols for this.  The little dot will be "and", the little plus sign will be "or" and the little square will be "xor".

Submitting a work in progress should be approved similar to the way files are approved to the archives.  That way, the ticalc.org staff can filter out the files that need filtering before they actually appear on the website.  Ratings and reviews are probably a bad idea, I think that should be the purpose of providing a link to the project.