Design decision for ADT support

[Jack-Works]

Algebraic data type, it is implemented in many languages in different names like "enum variants" (Rust), "Data Constructor" (Haskell) or "tagged union" (TypeScript).

This proposal is inspired by the Rust style, which added the tagged union into the enum itself.

The general idea of ADT support is: after defining a plain enum, we allow to also derive a constructor object for this enum that can contain data.

Here is an example (just for idea explaining, not the exact syntax/semantics).

enum Message of symbol with MessageCreator {
    Quit,
    Move { x, y },
    Write(message),
    ChangeColor(red, green, blue),
}

const msg = MessageCreator.Quit()
const msg2 = MessageCreator.Move({ x: 0, y: 1 })
const msg3 = MessageCreator.Write("")
const msg4 = MessageCreator.ChangeColor(255, 255, 255)

msg.type === Message.Quit // it's a symbol
Object.hasOwn(msg, "data") // false

msg2.type === Message.Move
msg2.x === 0
msg2.y === 1

msg3.type === Message.Write
msg3.data === ""

msg4.type === Message.ChangeColor
Array.isArray(msg4.data) && msg4.data.join(',') === "255,255,255"

How does it integrates with pattern matching proposal:

const M = MessageCreator
match (msg) {
    M.Quit: { process.exit() };
    M.Move({ x, y }): { entity.move(x, y) };
    M.Write(message): { console.log(message) };
    M.ChangeColor(r, g, b): { todo() };
}

How does it integrate with TypeScript:

enum Message<T> of symbol with MessageCreator {
    Quit,
    Move { x: number, y: number },
    Write(message: string),
    ChangeColor(red: number, green: number, blue: number),
    Generics(data: T)
}

Q&A

Why do we need a constructor object MessageCreator for that?

Because the enum value itself is a plain primitive value that cannot be called. In a language like Rust, they don't have this problem because their ADT enum members are used as a function, and can only be destructed by pattern matching or if let.

Why does pattern matching integration match by the MessageCreator instead of Message?

Pattern matching proposal requires the "custom matcher" to have a Symbol.customMatcher property. It's also not possible to put a symbol on the primitive value. The only place I can put it is in the constructor object.

Design decisions

To be decided

• Should we allow configuring the "key" and "value" ("type" and "data" in the case above)? How?

[Pokute]

I feel like this needs a lot of refinement and even then might be difficult to make it feel ergonomic while providing commonly expected features.

The biggest problem I have is that there's practically a nerfed function definition for the constructors. It feels like people will try to have default function arguments for the constructed functions. They would also be trying to have custom implementations for the constructor functions. My question then becomes: why wouldn't they be allowed? And if they are allowed, I don't see much point in having a different syntax for their definition.

Extending MessageCreator with additional constructors for existing enum elements, while possible, feels weird to do outside the declaration, will require different syntax and could be difficult to type in TypeScript.

What I'm most worried about is that coders might compromise their flexibility and end up writing more code elsewhere in order to have all constructors fit that narrow mold.

For most people writing action creators for stuff like Redux, it's common that we have a ton of boilerplate functions of form ({ x, y, z }) => ({ type: 'coord3d', x, y, z }); and (text) => ({ type: 'message', text };. I feel that having a concise way to define these kinds of functions has a broader market than just enums and should be a separate proposal instead. A flawed example: ({x, y, z}) => ({ type: 'coord3d', ... }).

[Jack-Works]

Yes. The ADT part is very hard to figure out how to design correctly. The current syntax is just a propose, and we shall future figure out the design constraints before starting the real design.

[guybedford]

My suggestion would be to restrict the ADT design to just functional forms Write(message) as opposed to the object forms Move { x, y }, since you can always type that as Move(pos) where pos is an object that has type { x, y }. Pattern matching should still work just as well I expect with roughly the same syntax anyway?

I would possibly even restrict the ADT case to singular values as well - Write(message) being ok, but ChangeColor(red, green, blue) being removed. Again, because you can represent the same either via an object ChangeColor(color) where color is { red, green, blue } or a tuple-like array where color is [red, green, blue]. The simplification of a singular value in ADT cases would reduce the complexity for helper functions and specification scenarios.

Apart from that, the overall functional design makes sense to me. @Jack-Works what can be done to progress the design in the proposal further?

[Jack-Works]

My suggestion would be to restrict the ADT design to just functional forms Write(message) as opposed to the object forms Move { x, y }, since you can always type that as Move(pos) where pos is an object that has type { x, y }. Pattern matching should still work just as well I expect with roughly the same syntax anyway?

Yes, if pattern matching does not have Message.Move { x, y }, we should not have it in the enum (otherwise it blocks the possibility to add it in the future).

I would possibly even restrict the ADT case to singular values as well - Write(message) being ok, but ChangeColor(red, green, blue) being removed.

That looks too limited, are you preserving the multiple parameters syntax for other features?

what can be done to progress the design in the proposal further?

I think the first step is to clarify the problem statement of what this proposal solves, then the second step is to figure out the design constraint (more dynamic or static?).

[rbuckton]

In the pattern matching proposal we have discussed removing object extractors (i.e., Message.Move{ x, y }), and only supporting array extractors (i.e., Option.Some(value)). However, for ADT enums to work with shared structs, they must themselves be either shareable, or at least trivially copiable. That means that object-like ADT enums might not be easy to use if you only support function-like forms when you want to express something more complex.

enum Message { Move(vector) }
sharedObject.message = Message.Move({ x: 1, y: 2 }); // throws, object not shared

As a result, I've been considering an ADT enum syntax that only leverages the functional form, but allows for object binding patterns as well:

enum Message<T> {
    Quit,
    Move({ x, y }),
    Write(message),
    ChangeColor(red, green, blue),
}

Here, Message.Move can take any object with x and y properties, but will implicitly copy them to own properties on the result:

const msg = Message.Move({ x: 1, y: 2 });
msg instanceof Message.Move; // true
msg.x; // 1
msg.y; // 2

Yet still allow the extractor syntax that matches the declaration:

// extractors
const Message.Move({ x, y }) = msg;

// pattern matching
match (msg) {
  Message.Move({ let x, let y }): ...;
  Message.ChangeColor(let r, let g, let b): ...;
  Message.Quit: ...;
}

[Jack-Works]

However, for ADT enums to work with shared structs, they must themselves be either shareable, or at least trivially copiable. That means that object-like ADT enums might not be easy to use if you only support function-like forms when you want to express something more complex.

In the struct proposal, there is a prefix shared, it's also possible to add it in the enum.

shared enum Message<T> {
    Quit,
    Move({ x, y }),
    Write(message),
    ChangeColor(red, green, blue),
}
const x = Message.Move({ x: 1, y: 2 })
// copy the object and create a shared object.