Additional generic types common in functional languages

[Phyn]

Is your feature request related to a problem? Please describe.

There are several generic types that are quite useful in languages similar to ProtoFlux. These can range in usefulness from simply saving space when moving data around to simplifying data storage and error handling. These would both simplify a lot of Flux, and also would work in conjunction with the collections of #572

Describe the solution you'd like

1. Tuples

   • These types allow bundling of dissimilar types into one value/reference for easier handling and storage.
   • For example, an int4 would become an int*int*int*int.
   • The size isn't commonly restricted, and such limitation would just mean having nested tuples.
   • A node could be provided that would collapse a tuple of all the same type into a collection of that type.

2. Unions

   • These allow a single type to be one of a given list of dissimilar types.
   • They are very close to an enum, and can even be implemented as an extension or replacement.
   • They would require a specialized node for extracting the data within and sending it on the appropriate output.
   • They can be used as a way to return an error into the flow from a given node and handling it in Flux.

3. Type definitions

   • These are quite handy when it comes to the construction of complex types.
   • They would provide a way of constructing a Union type.
   • They could be placed in world like Flux, and used as a shortcut to create a constant, input, or display.
   • If a type within Flux can be tied to a type definition, it could be used as a vehicle for implementing operator overloading and further simplifying a Flux implementation.
   • The only place where you could really use:

4. A placeholder type

   • Used to indicate a generic type that hasn't been defined.
   • Within a type definition, it could be used to create a custom type with a generic type to be filled in once the type is in use.
     • A way of specifying that two or more placeholders within a type definition should be the same type is useful here.
   • This would also be a perfect default type for generic inputs and outputs instead of needing to select a type from the node browser, and the type could normally be inferred from there.
   • Optional: Flux containing this type could refuse to run as it's an indication of incomplete code.

Describe alternatives you've considered

Tuples and Unions can be bodged together using existing types and Flux, but both would provide clear and more readable shortcuts as well as standardizing the implementation. Type definitions and placeholders are simply shortcuts to complex types and would have little to no impact on actual running Flux.

Additional Context

Tuples and Unions are both described by name within the F# language reference and it could be referred to for most of the details already provided. There may be other languages such as Rust that contain additional useful types, but these are what I'm familiar with and could use.

[XDelta]

On 4, we have the 'dummy' type that can be used in several cases, and type overloading works for many nodes if you try to connect another type to an existing input of the node as long a node of the attempted type exists.

[Zandario]

I'd die for Tuples and Unions, though I'd say Dummy follows the other examples as Detla says

[Banane9]

On 4, we have the 'dummy' type that can be used in several cases, and type overloading works for many nodes if you try to connect another type to an existing input of the node as long a node of the attempted type exists.

I just wish operators would just spawn with a default or the dummy type, instead of having to go through the extra step of selecting from the dozens of write nodes - which is ultimately pointless anyways, because it'd change type to conform to the input anyways.

[shadowpanther]

I'd die for Tuples and Unions

Wouldn't this be solved with Collections?

[Phyn]

I just wish operators would just spawn with a default or the dummy type, instead of having to go through the extra step of selecting from the dozens of write nodes - which is ultimately pointless anyways, because it'd change type to conform to the input anyways.

Maybe the dummy type could be put at the top of the type suggestions for now? That would simplify things somewhat.

Wouldn't this be solved with Collections?

A tuple could be considered to be an obscure type of collection, but a union isn't a collection and is different in a way that really only works well when the language implements it directly

[Psychpsyo]

Related: #110 for the placeholder type and #572 for collections (tuples and maybe typedefs)