I've made a language! \o/ Introducing Neat

[FeepingCreature]

On Wednesday, 21 September 2022 at 10:53:56 UTC, Quirin Schroll 
wrote:
> On Sunday, 18 September 2022 at 20:28:58 UTC, FeepingCreature 
> wrote:
>> Alright, since I've ran out of critical issues on my TODO, 
>> here's Neat!
>>
>> https://neat-lang.github.io/
>>
>> https://github.com/neat-lang/neat
>
> Can you show a little bit of your sum types? They can be 
> implemented in four ways:
>
> 1. Stupid union (like `union` in C, C++, and D)
> 2. Type union or soft discriminated union (`int+string+int` = 
> `int+string` = `string+int`)
> 3. Indexed union or hard discriminated union (`int+int` ≠ `int`)
>
> For 2., you effectively ask: Which types are in? Order and 
> repetition don’t matter.
> And 3. is effectively an algebraic type with unary constructors 
> that are referred to by index (instead of by name).
>

It's 3, but implicitly convertible with 2. I disambiguate int+int 
cases with zero-sized "identifier types": for instance, `alias 
Point = (:x, int | :y, int)`.

> What is your take on qualifiers? Is `int+const(int)` allowed 
> and/or the same as `int`?
>

I don't have qualifiers at the moment. But I'd probably make it 
"allowed and different from int".

> Do your sum types nest or are they flat? As an example, D’s 
> alias sequences are flat: `AliasSeq!(a, AliasSeq!(b, c), d)` = 
> `AliasSeq!(a, b, c, d)`. A sum type implementation can make 
> `int+(char+string)+double` be `int+char+string+double` or keep 
> the nesting. As alias sequences show, flattening is not that 
> bad and if not desired, can be mitigated using wrappers.
>

They're nested right now. I think that's the correct behavior; 
otherwise, things like aliasing sumtypes are going to lead to odd 
behavior (`alias foo = (int | float)`, now if you stick it in 
another sumtype you need either "subset matching" in `case()`, or 
`.case(foo f: ...)` doesn't work.

> Does it support the empty sum? It would naturally be a bottom 
> type.

You could manually create that type with a macro, but you can't 
declare one in the syntax right now.

> Does a unary sum exist? It would naturally be equivalent to the 
> only type argument.
>

Likewise.

To note, sumtypes started out as a macro before I integrated them 
in the compiler so I could use them in the macro API. So users 
who don't like the way this works can always define their own. :)