<div dir="auto">Yes, I think you're getting the gist. Pattern matching with one or two nulls is just an equality test or three. In practice, we'd want a fixed number of evenly spaced nulls, allowing jump table techniques to be used when there are more cases. We'd presumably have a hard limit for the number of nulls a type is allowed to have.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 14, 2020, 10:29 AM Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Ok, I believe get it now,<br></div><div><br></div><div>Let's imagine (to take only the simplest case) that we have a `Nullable# a` type, such that `Nullable# a = (# (##) | a #)`. What would be the kind of `Nullable#`? I imagine that it would be something like `TYPE (BoxedRep Lifted) -> TYPE (BoxedRep Nullable)`.</div><div><br></div><div>Then you would want to abstract the type of arrays/tvars/whatnot from `Type -> Type` to `forall r. TYPE (BoxRep r) -> Type`.</div><div><br></div><div>Is that a correct interpretation of your suggestion?</div><div><br></div><div>If so, my guess would be that all the above is fine, but I suspect (and I'm quite a bit out of my comfort zone here) that there can be considerable difficulties in implementing pattern-matching for such a type.<br></div></div>
</blockquote></div>