Consider adding union types as an alternative or replacement for sum types

[dlurton]

A current limitation of PIG sum types is that variants are restricted to tagged values, i.e. product and record types. This simplifies a few things related to the generated (de)serializers and builders but also limits certain opportunities I'll describe in a moment. Consider the following sum type:

(sum expr
    (lit value::ion)
    (binary op::operator expr expr)
    (call func::expr (* args 0))
)

It is currently impossible to create a restrict an expr to just a subset, i.e. the following would not be possible because binary is a variant, not a type that can be referenced directly:

(product binary_pair first::binary second::binary)
                            ^ error        ^ error

PIG is no help here; one would have to use expr instead of binary and then somehow enforce that binary_pair was never instantiated with anything other than the binary variant at run-time. This is somewhat unfortunate. It would be highly useful if PIG had a union type that could be any one of a number of other types.

The following type domain uses the proposed union types:

(product lit value::ion)
(product binary op::operator expr expr)
(product call func::expr (* args 0))

(union expr lit binary call)    // <-- defines a type that can be a lit, binary or call
(union expr_subset lit binary)  // <-- defines a type that can be a lit or binary

A practical use-case for this might be for restricting the allowed variants in the target::expr element of the assignment type which is used in the SET clause that is part of DML in the partiql_ast:

(product assignment target::expr value::expr)

Given this definition, target can be any expr even though at it is only logical for target to be an id or path. This means that the AST is capable of representing silly expressions such as SET (1 + 2) = 3. (Although PartiQL's parser rejects that, thankfully).

Using union types, target could be constrained only to id and path expressions:

(product id name::symbol ...)
(product path root::expr (* path_element))

(sum expr
    ...
    id
    path)

(union lvalue id path)

(product assignment target::lvalue value::expr)

[dlurton]

I believe this would also be a way to implement the feature being described in #58.