OT Basic

[Xeda112358]

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):

Code: Select All | Copy To Clipboard

1	"Hello "&"World"&char(33

[program4]

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.

[Xeda112358]

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

[Deep Thought]

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 All | Copy To Clipboard

1

/"

and the / symbol means you type

Code: Select All | Copy To Clipboard

1

//

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

Code: Select All | Copy To Clipboard

1

/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

[graphmastur]

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 All | Copy To Clipboard

1

/"

and the / symbol means you type

Code: Select All | Copy To Clipboard

1

//

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

Code: Select All | Copy To Clipboard

1

/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.

[program4]

Oh oops, it looks like I forgot my Java. 

[AngelFish]

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.

[Xeda112358]

I agree and I also think that to keep data smaller, the program should undergo a "tokenization" process like with the TI-89. This way, data can be converted directly to bytes that the parser can work with.

[graphmastur]

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.

[Deep Thought]

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.

I don't like the idea of having numbers be treated fundamentally as hex. It's bad for UI to say that the 62 in char(62) is hex, while the 62 in floor(62) is decimal.

[graphmastur]

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

[Deep Thought]

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?

[graphmastur]

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.

[Ashbad]

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.

Also, I suggest an optinional approach of OOP -- like C++.

[Deep Thought]

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.