3 ms·

> But why? It seems like having a `Digit` type, and having a `NatNum` type that's `List<Digit>`. BigInt types are in fact more or less List<Digit>, normal inte

> But why? It seems like having a `Digit` type, and having a `NatNum` type that's `List<Digit>`. BigInt types are in fact more or less List<Digit>, normal integer types just aren't implemented like that for performance reasons. A char is the primitive type that makes up a string if chained together. It's more or less a practical naming convention, just like we can call a tuple of floats a vector. Maybe you could get by without chars, but then String would be the only type in your language that doesn't consist of any scalar element but always has an arbitrary length in every situation.

reikonomusha 6y ago
Arguably strings these days don’t really have scalar elements, not at least in the way we think. One “character” might be several distinct code points, and character access might not be a linear time operation.
- alpaca128 6y ago
  It still makes sense to expose those codepoint sequences as individual symbols for the sake of the programmer's sanity. In most cases we don't really need to care if it's a single latin letter or a combination of bytes that make up a weird emoji, we just want a simple way to iterate over what a human reader would call a single character.
  - chrisseaton 6y ago
    > we just want a simple way to iterate over what a human reader would call a single character But that's almost never what a language is giving you with their 'characters'.
Dylan16807 6y ago
> BigInt types are in fact more or less List<Digit>, normal integer types just aren't implemented like that for performance reasons. Right. Because you only use BigInts, you don't use isolated BigInt digits. > but then String would be the only type in your language that doesn't consist of any scalar element but always has an arbitrary length in every situation. Sure, why not? Every type has something special about it. Integers have overflow, floats have precision, infinities, and NaN, and booleans don't map cleanly to bytes. There's enough different ways to iterate over a string; you don't need a canonical way to decompose them, which is basically what a char type is. I wouldn't go as far as "mistake", but it's definitely fine to go without it. > A char is the primitive type that makes up a string if chained together. It's more or less a practical naming convention, just like we can call a tuple of floats a vector. For chars more complex than a byte, there are multiple practical conventions and it's hard to pick one. For char=byte there's a very natural convention, and an array of bytes reflects what's actually in memory, but char=byte is something that should be avoided. So it's either "none of these stand out" or "don't do this". So you might as well keep the language slightly simpler and not have a char type.

reikonomusha 6y ago

Arguably strings these days don’t really have scalar elements, not at least in the way we think. One “character” might be several distinct code points, and character access might not be a linear time operation.

alpaca128 6y ago
It still makes sense to expose those codepoint sequences as individual symbols for the sake of the programmer's sanity. In most cases we don't really need to care if it's a single latin letter or a combination of bytes that make up a weird emoji, we just want a simple way to iterate over what a human reader would call a single character.
- chrisseaton 6y ago
  > we just want a simple way to iterate over what a human reader would call a single character But that's almost never what a language is giving you with their 'characters'.

Dylan16807 6y ago

> BigInt types are in fact more or less List<Digit>, normal integer types just aren't implemented like that for performance reasons. Right. Because you only use BigInts, you don't use isolated BigInt digits. > but then String would be the only type in your language that doesn't consist of any scalar element but always has an arbitrary length in every situation. Sure, why not? Every type has something special about it. Integers have overflow, floats have precision, infinities, and NaN, and booleans don't map cleanly to bytes. There's enough different ways to iterate over a string; you don't need a canonical way to decompose them, which is basically what a char type is. I wouldn't go as far as "mistake", but it's definitely fine to go without it. > A char is the primitive type that makes up a string if chained together. It's more or less a practical naming convention, just like we can call a tuple of floats a vector. For chars more complex than a byte, there are multiple practical conventions and it's hard to pick one. For char=byte there's a very natural convention, and an array of bytes reflects what's actually in memory, but char=byte is something that should be avoided. So it's either "none of these stand out" or "don't do this". So you might as well keep the language slightly simpler and not have a char type.