i like strings! i love the $$$...
though i don't use it much anymore
keep it basic, $ is so basic that it's a bit hard to take out
re. *... currently all pointers are 32 bit long, once 64 bits show up, there may be an issue indeed with pointers...
pointers are a bit wacky, here's how things are now:
a = 5
means var a gets val 5
*a = 5
means var *a gets val 5
*a\BYTE = 5
means 5 is written in memory on the spot where *a points to
i am not going into the strange behaviour and naming scheme of pointers within structs... (this is something that should be changed asap imho)
to do things differently, and perhaps more logical, would break ALL existing code (duh), as the * would no longer be a part of the varname
a = 5
means var a gets val 5
*a = 5
would mean: write a long int (the default type, as no type has been given) to memory at the location where a points to
*a\BYTE = 5
ok, so we write a byte at that spot
would i take that change lightly? no... would i accept it? yes, as it would do the structure of the language quite some good, but lots of old users would be alienated
in a way, a pointer is nothing more but a var, often combined with a peek / poke, in gfabasic there were a few alternative wordings, some suggestions (dunno if they are good ones

)
Byte{ <varname> } = <expression>
Byte{ a } = 5
(the reason they choose the {} characters is that too many users already used arrays with the name 'byte'

of course a simple search and replace would fix this, so i'd take Byte() Word() Long() ULong() UWord() UByte() Quad() and UQuad() any time...)
I personally think this:
BYTE( a ) = 5
is more readable than
POKEB( a , 5 )
actually, i'd love to see fred adopt the above additional commands Byte() Word() etc., for readability as well as future compatibility, and the current pointer syntax could be kept alive without creating incompatibility (we'll accept the confusion

)
oh darn, i ranted again, sorry