Re: [RFC SPEC] Primitive data types and arrays

[ricardo_kagawa@disroot.org]

> A olang array is just like a C array, no need to translation. Although it

Are you sure about this? I mean, as a contiguous, properly sized chunk
of memory with indexed access, it looks fine. But in C, an array
variable is a pointer to that chunk of memory, and therefore pointer
arithmetics would be required to match C arrays.

I'm not sure I'd like to deal with pointers. But it's not like I can't,
it's just that I know it opens a nasty can of worms that I'm not sure
you'd want to deal with as a language designer.

> > I loved it.  Out of curiosity, we are going to have _boolean_ and _char_
> > I believe.  Shouldn't they also be included on these primitive spec?
> 
> I like it! We could discuss in the near feature if they are or not just
> type alias for u8. But I also agree they must be built-in without the
> need of any include.

I like the idea of treating `boolean` and `char` as primitives, but do
be careful about what they mean.

Obviously, `boolean` can be either `true` or `false`, but what should
that mean? If `boolean` is mapped to `u8`, then zero and non-zero?

But the real question is what would `char` be? If the language should
support Unicode properly, then `char` would represent a _code unit_
rather than a "character", which could be considered a misnomer. Since
Unicode uses variable-length characters, a Unicode character might be
difficult to represent as just `char`.

If no Unicode support is planned, then `char` as `u8` is good enough to
represent characters in 7-bit ASCII encoding.

> > Perhaps _char_ SHOULD have support to escaped chars like \r (carried
> > return), \n (line feed)...  Whenever you create the patch, don't forget it.
> 
> Sure! I will cover this. Thanks!

If you have plans to support Unicode, then I'd also suggest to include
hexadecimal and Unicode escapes, like `\x20` and `\uffef`.

> > > I am wondering if we should also define _void_ as a primitive.
> > 
> > I think so. Do you like the name *void*? I don't like that much by I
> > can't think in any alternative.
> 
> Let's go with _void_.  We are on very early development stage,
> everything can change anytime.  And _void_ is kind of very well known
> keyword.

Note that in most languages where there is a `void` type, the `void`
type is not actually valid in variable declarations. They are valid only
in funtion return types. In C, they are also valid as pointer types
(that is, `void* x;` is valid), but IIRC, not as variable types
(`void x;` is not valid).

In the current version of the spec, it would be included in
<return-type>, rather than <type>, to allow it only as a function
return type.

Also, there are three other types that might be interesting, if I may
suggest: `never` (from TypeScript [1]), `unit` (from functional-like
languages [2]) and `null` (from ECMAScript specs [3]).

[1]: https://www.typescriptlang.org/docs/handbook/2/functions.html#never
[2]: https://en.wikipedia.org/wiki/Unit_type
[3]: https://tc39.es/ecma262/multipage/overview.html#sec-null-value

- `never` would not be that useful without an exception system.
- `unit` and `null` would not make much sense at the same time, so it is
  either one or the other.
- `null` would also be more interesting with union types (TypeScript),
  to define nullable types as the union of a non-nullable type and the
  `null` type. (C has union types, but they are not related to this.)
- I don't really know why an empty tuple would be interesting as the
  value for the `unit` type, but several languages use this convention.
  In ECMAScript specs, there is a `null` type that uses the `null`
  value as its unit value.