Re: [RFC SPEC] Primitive data types and arrays

[Johnny Richard <johnny@johnnyrichard.com>]

On Tue, Apr 16, 2024 at 10:30:03PM -0300, ricardo_kagawa@disroot.org wrote:
> > 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 really would like to know what you see as nasty.  I mean, don't you
want to deal with pointer in general?  Or you want to segregate the
concept of array and pointers?

> > > 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?

That's what exactly what I had in mind.

Which problems you see with this approach?

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

Could you please enlighten me the implications of starting with `char`
as `u8` alias (7-bit ASCII)?  What are the problems we could have if we
don't support Unicode properly?

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

I'm okay of not using void pointers as long as we have a replacement for
it.  I still want to have support to define a raw pointer (untyped).

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

Yeah, I like it.

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

The language wont have exception.

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

I think this approach lead us to design a complex type system.  I
understand the value of this, but the cost is high when you want to
design a simple language.

Regarding `null` I would like to have `null` as an alias to 0 (zero).
And we could also have semantic analyses on it.  In this case `null`
wont be a proper type.