Improve type system and type inference rules

Question

Improve type system and type inference rules

k-sareen opened this issue 2 years ago · comments

As discussed here: #120 (comment), the type system and inference rules should be updated to allow less verbose pattern matching for developer UX.

Ben L. Titzer · Answer 1 · Fri Feb 17 2023 22:03:51 GMT+0800 (China Standard Time)

Can you write a seman testcase that should pass and add to test/fail?

Kunal Sareen · Answer 2 · Mon Feb 20 2023 12:45:58 GMT+0800 (China Standard Time)

I've been reading the type checking code in vst/Verifier.v3 and I don't understand why the ve.expr has to be null, i.e. why the match case has to be the unqualified type (see these lines).

Kunal Sareen · Answer 3 · Mon Feb 20 2023 12:59:22 GMT+0800 (China Standard Time)

For the error generated by test/fail/adt_type_infer03.v3 (in PR), I think the TypeSystem.isPromotable() should return true because, well A<u4>.C and A<u8>.C are the exact same type. Unless is there some internal representation issue? Even then it should just be equal, no?

EDIT: Or well, more precisely the TypeSystem.isSubtype() for variants needs updating.

Ben L. Titzer · Answer 4 · Tue Feb 21 2023 23:09:17 GMT+0800 (China Standard Time)

This is a subtle thing that needs to be explained better. Integer types like u4 and u8 are not related by subtyping but by promotion. That is because they could be represented differently. E.g. on a 32-bit machine a u32 will be represented by one word and u64 two words. Subtyping is only for values whose representation doesn't change when assigning a value from a subtype to a supertype location (i.e. the assignment is always pass-through, nop).