Union isSubtype doesn't work as expected about sinap-types HOT 3 OPEN

This is actually expected. The issue with validateEdge is something we need to solve, but to simplify sinap-IDE I chose that:

A ≮ A | B

This is because a union is a distinct Value

if type(a) == A | B
then either:
    type(a.Value) == A
    type(a.Value) == B

It is true that

A | B < A | B | C

These choices are not inline with TypeScript, but they are consistent with ML

from sinap-types.

Note that this isn't the only place this causes a problem. It is also the reason that you need to manually specify return types on getters for computed properties. The best solution might be to force the IDE to deal with unions all the time (which would mean there was no special Value class for them). This would allow us to have A < A | B. This is similar to the way that the IDE has to deal with CustomObjects. @RighteousRaichu, remember the issue we dealt with for Nodes as inputs in the REPL, can you add some information?

from sinap-types.

I don't think that this makes very much sense. If we want to go for full discriminitive unions, then we should do that. Right now we are using the worst features of both types of unions.

If it were a true discriminitive union, then isSubtype should fail unless it is wrapped correctly in the appropriate type constructor.

enum Example {
  A(int),
  B(string)
}

match (x) {
  A(ref y) => y+1,
  B(ref y) => y.len()
}

In the above example Rust pseudocode, you must explicit wrap and unwrap things according to the type constructor.

However, if we take an approach similar to Rust, you would not be able to do many things that seem like they should be possible in TypeScript.

In conclusion, it is my opinion that we either make our Unions like TypeScript or provide both a discriminative union mirroring the Rust example as well as a non-discriminitive union for TypeScript code. The former is easier to do, but the latter would be more useful generally.

from sinap-types.