Rethinking Runtime Type Test Operator ?

[DavePearce]

Currently, the following program fails to compile:

type in_rec is {(int|null) f}
type ib_rec is {(int|bool) f}
type rec is in_rec | ib_rec

function write(rec x, int n) -> (rec r):
    //
    if x is in_rec:
        x.f = n
    else:
        x.f = n
    //
    return x

The reason for this is that, in the false branch, the type for x is {bool f}.

QUESTION: is that what we want?

[DavePearce]

IDEA: perhaps clarify the type test operator as a true selector? That is, given a union type, the purpose of the test is to select at most one term (and possibly only a partial one at that). This would allow the above to compile (which is perhaps more intuitive), and cause the following to fail:

type in_rec is {(int|null) f}
type ib_rec is {(int|bool) f}
type rec is in_rec | ib_rec

function write(rec x, int n) -> (rec r):
    //
    if x is {int f}:
        x.f = n
    else:
        x.f = n
    //
    return x

The reason for this is that it would be ambiguous as to whether in_rec or ib_rec was being selected.

[DavePearce]

Need an RFC. Things to think about:

• Types like pos|neg
• Recursive types
• Would this would mean no more SemanticType? No, not necessarily as e.g. x is {int f} where x is {int|null f} would still be allowed.
• Could allow e.g. x is T|S for multiple selection? Then x is T where T is an atom is always for single selection.

[DavePearce]

Migrated to https://github.com/Whiley/RFCs/issues/36