Variant vs ListVariant types

user_651174 0
Viewed 90

I am building a type system and have a variant type which can support all the other types. Here is a simple example where an int32, float, and str are allowed:

`variant_scalar`
"hello"
NULL
2
2.7

Additionally, a typed array of variant length is supported, such as:

`int32_arrar`
[1,2]
[1,2,3]
[1]

Now I have a question about the following two variant columns, one which contains only variant-array items and the other which contains types of both scalar and array nature:

`variant_array`
[1,2,"hello"]
["new", [1,2]]
NULL

-------------------------------------

`variant_anything`
1
"hello"
NULL
[1,2,"hello"]

What would be the proper way to handle this in a type system (for example, for a database)? Should there just be one Variant type which supports everything, or should there also be a VariantArray type that supports an array of anything...but it must be an array?

I suppose one reference which might be useful is the Type System used by the M Language: https://docs.microsoft.com/en-us/powerquery-m/m-spec-types.

type-theory variant types
1 Answers

There are reasons why there are many different type systems.

I'm afraid there is no proper way and your question can not be answered without a deep dive into your needs and restrictions.

The general answer would be: "the more specific your types are - the better (*)".

If you can express in your type system, for example, an array of emails which length is a prime number - then you types system will be useful in more cases, compared to the one that can not express such type...

(*) but it will come with a cost:

  1. such type system can be a nightmare to use.
  2. such type system can be a nightmare to implement.

Wikipedia probably is not the absolute truth, but wraps the topic nicely:

When a programming language evolves a more elaborate type system, it gains a more finely grained rule set than basic type checking, but this comes at a price when the type inferences (and other properties) become undecidable, and when more attention must be paid by the programmer to annotate code or to consider computer-related operations and functioning. It is challenging to find a sufficiently expressive type system that satisfies all programming practices in a type safe manner.

I'd suggest to consider the "evolves" part. Don't try do build an ideal. Build MVP, but in a way that will allow you to improve it later on when you'll figure out your proper way from the practice.

But in your particular example I guess that you'd like to implement Array<T> anyway... and, actually, you say that you do

Additionally, a typed array of variant length is supported

So Array<Variant> shouldn't be a problem. There is no reason to treat T as any but not Variant

user_126103470
Related