Add support for ADT enums

[rbuckton]

This adds a rough description of ADT enum support.

[rbuckton]

cc: @rwaldron, @Jack-Works

[Jack-Works]

I wonder how this dynamic dispatch approach (delegate to Enum.ADT[@@toEnum]) works with TypeScript.

[rbuckton]

It may not matter too much for native enum due to differences in how we handle enum vs. const enum. For something like enum Color of Number { red, green, blue }, default members would be TypeFlags.EnumLiteral | TypeFlags.Number.

I'm currently iterating on the ADT enum approach. I'm considering the possibility of having the of mapper only apply to Scalar members that don't use ADT enum syntax, and having ADT enum members (that use {} or ()) always produce an ADT enum member factory. Essentially, that would mean that of would only apply to uninitialized scalar values.

[Jack-Works]

little skeptical about {} syntax but () syntax is good to me.

[rbuckton]

I'd really like to be able to leverage this for the following scenario:

enum Node of Enum.ADT {
  Identifier{ escapedText, pos, end },
  StringLiteral{ text, pos, end },
  NumericLiteral{ text, pos, end },
  BigIntLiteral{ text, pos, end },
  ...
  BinaryExpression{ left, operator, right, pos, end },
  PropertyAccessExpression{ expression, name, pos, end },
  ElementAccessExpression{ expression, argumentExpression, pos, end },
  ...
}

[Jack-Works]

I'd like to reduce the number of new well-known symbols. Is it possible to merge them into one?

@@enum: { format?, parse?, construct?, from? }

[rbuckton]

Maybe parse and format, but not the others:

• @@toEnum goes on the mapper passed to of such as Number, String, etc.
• @@formatEnum and @@parseEnum go on the constructor produced by the enum declaration_.
• @@propertyConstruct goes on an ADT enum tagged record member.

Those are three wholly different placements. @@formatEnum and @@parseEnum provide a way to access the underlying enum data used to relate a key to a value and vice versa, and are symbols rather than internal slots so that existing enum-like constructs can be adapted to work with Enum and can be produced by a transpiler.

[Jack-Works]

why not pass them as array/object directly?

[rbuckton]

This is the declaration, not instance construction. There's no "object" to pass, only the property names or parameter list.

[Jack-Works]

do we need R&T here?

[rbuckton]

I think so, yes. I'm of the opinion that ADT enum should have the same requirements as records and tuples as to the kinds of values they can hold. One reason is data portability between realms, along with the potential for a future shared enum that could tie into shared struct and multi-threaded JS. I'd also like to have Option.Some(1) === Option.Some(1) hold.

[ljharb]

What I don't see here is a clear explainer for what an ADT enum is (beyond just the initialism expansion), and why it's important to have that feature in the language.

[rbuckton]

What I don't see here is a clear explainer for what an ADT enum is (beyond just the initialism expansion), and why it's important to have that feature in the language.

That is forthcoming, this is still fairly early.

[heaths]

If only derived from Number, how might these strictly compare to other number types, or would they only explicitly compare to themselves? I suppose the latter makes more sense anyway.

[heaths]

Is mixing of auto-incremented values and explicit allowed as in some languages e.g., C#? In that case, should this proposal be explicit in how that will work e.g., auto-increments from the previous auto or explicit value?