Linked by Thom Holwerda on Mon 1st Oct 2012 22:55 UTC
General Development "Everyone seems to have a replacement for JavaScript - Google even has two. Now Microsoft has revealed that Anders Hejlsberg has been working on a replacement and it has released a preview of TypeScript. TypeScript is open source - Apache 2.0 license - and a superset of JavaScript. As you would expect from a Hejlsberg language it incorporates type checking, interfaces and lots of syntactic sugar."
Thread beginning with comment 537344
To view parent comment, click here.
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

butters,

"In my view, a weakly-typed language must support implicit type coercion at least to some extent. C is a weakly-typed language which will, for example, happily add an integer to the ascii representation of a character. Python is an example of a strongly-typed language which will complain loudly if you attempt the same. But you'll never find type annotations in Python."


In my opinion, C doesn't have a "character type" (like a pascal CHAR). The 'char' is actually an integer type in C, which in most (all?) implementations happens to be an 8 bit byte. Because C doesn't have a string type either, we've become accustomed to representing strings as array of bytes (char). But that doesn't make the 'vector of chars' nominally equivalent to a 'string', they are different concepts.

If you follow my reasoning, then you wouldn't say C has a construct for "add an integer to the ascii representation of a character". If we renamed C's 'char' type to 'byte', you would have recognised the type for what it is (an integer instead of a character type, which C doesn't have).

Edit: If C did have a character type, I assume it wouldn't support direct arithmetic without a cast. Pascal doesn't support character arithmatic. .net doesn't. Javascript, which unifies characters and strings, doesn't. PHP does it's own thing by re-interpreting the character as a ascii digit.

Edited 2012-10-02 15:20 UTC

Reply Parent Score: 2

TemporalBeing Member since:
2007-08-22

A 'char' and 'unsigned char' are typically 8-bits; however, they are by definition the smallest integral unit on the system - whether it is 1, 7, 8, 15, 64, or 128 bits.

A one point 7 bits was very typical hence ASCII is officially a 7-bit character to integer mapping, while ASCIIZ is an 8-bit mapping, and projects like Qt only rely on the 7-bit mapping.

Today, 8-bit is the norm and we haven't gone above that since having an 8-bit integral type is quite useful. However there is nothing keeping anyone from making a 16/32 bit char/byte computer - which would simply mean that UTF-16/32 would be the standard and ASCII wouldn't be very easily supported as you would have to mask-out a good number of the bits to get the data.

Reply Parent Score: 2

Alfman Member since:
2011-01-28

TemporalBeing,


"A 'char' and 'unsigned char' are typically 8-bits; however, they are by definition the smallest integral unit on the system - whether it is 1, 7, 8, 15, 64, or 128 bits."

Agreed.


But if the smallest integral unit on the system wasn't exactly an 8 bit byte, then we'd start having numerous compatibility issues such as how to implement stdint.h. Lots of code would still work if registers were just padded with more bits, but packed structures would be incompatible, which I believe is why POSIX mandates an 8 bit char.

http://stackoverflow.com/questions/6631491/why-did-posix-mandate-ch...

Of course, this doesn't rule out the existence of micro processors that only support a fixed word size > 8 bits, but they might have trouble parsing 8bit aligned structures which come in over the wire, etc.

Edited 2012-10-02 17:18 UTC

Reply Parent Score: 2