yeah, rand is good. i forgot about that. i'm think rand 0-1, randint # specified - # specified, randmatrix every value is between two specified numbers and randlist, same thing as randmatrix but for a list. and i know there were suggestions for other data types, so hopefully find a way to get random data types too. sorting would also be good.

I think that it should support multiple key presses (lack of this is one of the things I hate the most about TI basic).

I agree with program4. I find it weird that lowercases are disabled by default and that you need to install a language APP and turn your calc in a different language to access them...

/\i like(although i dont really see the purpose of word storage other than os calculations...)
a menu sounds nice, too(all number dealings are floating point by default for nubs, but can be set to the others to increase calculation speed)

alright so i've been thinking a lot about the data types involved in this, and i think there shouldn't be too many as to confuse the casual programmer, but enough so an advanced programmer can save a lot of memory. thus, here are my suggestions for data types dealing with numbers only, excluding strings or data structures (lists/matrices/arrays) for now:

-Byte holds values -128 to 127, integers only
-2Byte holds values -32768  to 32767, integers only.
-4Byte Word holds values... really big. like -2 billion to 2 billion.
-16.16 fixed point values  -32768.32768 to 32767.32767
-the unsigned versions of the above numbers
-The OS Float, however the OS stores floating point, that's this data type. no unsigned version.

also, maybe have a menu where you can turn on and off advanced features, such as specifying what data type a variable should be. suggestions? also, adding in the array functions, multiple keypresses and foreign characters suggestions to the first post.

If I am catching you right then you also mean that when a user defines a variable and that variable is a number then the user also has to define what kind of type the number is? e.g.

Byte 1->aVar
Int 123->aOtherV
etc..

If so then I would make this optional in the following sense: If a user defines a variable that contains a number but he/she does not defines the number-variable's type then a floating point is assumed. So:

102->myVar

would be presumed to be a float which, logically, takes up more space then a int. A more advanced programmer therefore would do this:

Int 102->myVar.

Ther is one problem with this, mainly that the very word 'Int' itself takes up space. So maybe it'sbetter to do prefixes (I think we already discussed that but I am not sure...) I suggest these prefixes.

" --string
i --int
r --real
m --matrix
l --list
f -- float
o --bit (based on the 'switch' term... b for bit and f for flag are already used as 'byte' and 'float')
b --byte :=8bits
d --double byte :=16bits
w -- word :=32 bits

example
"FooBar->myvar
l0,1,2,3,4->myVar
Disp "I Say : myvar : myVar[1]

In the above example are tow more things:

1. myvar and myVar, shall we make a distinction between the tow? inother words should variables be case sensitive?
2. the ":" (without quotes) sign which would combine several variables and strings into one Disp command. (I originally wanted to use the "&" token but I thought that would be uneasy to access if we were to use a keypad similar to TI's)

Just say what you think about this...

edit in my example code it is seemingly impossible to include the ":" token in a string, this exmaple below however does so:
Disp "M says : ": : "Hello

which combines the strings "M says", ":" and "Hello".
maybe "&" is better after all...

/\i like(although i dont really see the purpose of word storage other than os calculations...)
a menu sounds nice, too(all number dealings are floating point by default for nubs, but can be set to the others to increase calculation speed)

I don't think floating point should be the default. It's too slow. Perhaps a fixed decimal point would be a better default, since it's faster to compute and slightly more accurate.

Sorry to mix up hard and software here but, floating point math should not be that hard if we go for a propellor based design, it has full hardware 32 bit math support and can do float calculations in just one out of eight cores....

So really Floats is more hardware related if speed is an issue...

I figured a third option, eZ80 with a propellor as gpu? I mean, gpu's today are so great because they use stream processors, with a prop that is possible too...