There will definitely need to be a char() command so that users can have access to all of the ASCII characters and this will allow for something like this to concatenate strings (like on the 89):
"Hello "&"World"&char(33

Well it isn't very difficult in assembly, it just requires writing a byte.

Quote from: program4 on March 16, 2011, 09:06:41 pm

Maybe the ability to add quotation marks to a string would be nice, like using escape code or whatever it's called. Like, the " symbol means you type

Code: [Select]

/" and the / symbol means you type

Code: [Select]

// just like in Java. This would also allow for escape sequences like newline

Code: [Select]

/n

I'd actually suggest a backslash (\) instead. It's what languages like Java use, and using / could get messy when users want the division sign -- which could happen a lot on a calculator

yeah, backslash definitely should be used.

I agree, too. This would also essentially allow digit to string conversion, if say char(62) corresponds to 1 then char(61+x) corresponds to x. But, number to string conversion would still have to be added separately.

I'd recommend going with hex and standard ASCII. That'd mean that char(31) would return "1" and char(62) would return "b." It'd also make things like char(546869732069732066756e) really easy to parse if they were in hex rather than decimal.

Quote from: program4 on March 17, 2011, 09:05:04 pm

I agree, too. This would also essentially allow digit to string conversion, if say char(62) corresponds to 1 then char(61+x) corresponds to x. But, number to string conversion would still have to be added separately.

I'd recommend going with hex and standard ASCII. That'd mean that char(31) would return "1" and char(62) would return "b." It'd also make things like char(546869732069732066756e) really easy to parse if they were in hex rather than decimal.

agreed.  In fact, I like that a lot better.  But I like char(596F752772652072696768742C2074686973206973206C6F616473206F662066756E2E) better.

true.  Maybe a lowercase b/h?  or %/$?

Quote from: graphmastur on March 21, 2011, 12:00:16 pm

true.  Maybe a lowercase b/h?  or %/$?

I think %/$ would be a good idea. They're hardly used in other situations.

Unless we want to make them actual operators?

EDIT: Btw, who's actually working on this?

We don't actually have a physical calc yet, so it's mostly conceptual atm.

I acutally like the idea of using hex for a char() command.  That's actually how most people denote chars.  If you want to make a decimal version, I suggest a Byte() or RShort() command.

People don't like inconsistency though. Plus if we don't make an exception for char( and instead let it take a value the same way as any other command, the OS code for it would be much, much smaller.

EDIT: We can always have a format for hex numbers, as graphmastur said.