OK, I've been playing with this on the work codebase. I have some observations.

The Question of ?. and OverloadedLabels

foo.bar doing nullable field projection actually works really great. I am really not entirely sure why it works so well, compared to foo ?. #bar, which has lots of weird type inference issues. But foo ?. FooBar continues to work great with nullable field projection.

My guess is that the (SymbolToField sym rec typ) => IsLabel sym (EntityField rec typ) instance just doesn't bring enough constraints or power to bear, and the inference falls apart. So foo ?. #bar form becomes pretty much useless from a type inference perspsective. This is... unfortunate.

So, should ?. be changed? If so, to use Nullable or NullableFieldProjection?

How many other functions should do this?

subSelect :: SqlQuery (SqlExpr (Value a)) -> SqlExpr (Value (Maybe a)) is a clear possibility, as are all the aggregation functions. But this may cause type inference issues.

just and joinV - to make polymorphic or not?

If we make joinV and just polymorphic, then we can avoid changing a lot more code. But we also risk worse type inference.

I suppose just' and joinV' which retain the old fixed behavior may be a good compromise here.

Should they use Nullable or NullableFieldProjection?

And when? What are the differences? They seem very similar in terms of functionality, but the inference properties are different - how?

Lots of questions.

On ?.

If we make ?. polymorphic, then we introduce type inference problems... but honestly, very few.

Making it return SqlExpr (Value (Maybe (Nullable a))) actually works pretty well. If you write polymorphic code in ?., then you'll have to propagate a constraint. But this is relatively rare in the Mercury codebase.

Weirdly, using the type class causes significant inference problems.

Since both have some Issues, I am going to create an operator ??. which retains the original type behavior, Just In Case.

On just

Even with polymorphic projection, I find that a lot of just uses are complaining about Maybe. With just :: (NullableFieldProjection typ typ') => SqlExpr (Value typ) -> SqlExpr (Value (Maybe typ')) we only really save ourselves from type-errors at just (just (val x)) or just (just foo.bar) uses.

With a type family:

type SqlMaybe a where
    SqlMaybe (Maybe a) = Maybe a
    SqlMaybe a = Maybe a

This should do something similar, but it ends up being really awkward, as just is often used to produce polymorphic values- ie just (val 0) - and this ends up having awful inference properties. Propagating this type family around causes a significant amount of noise, too, so it's probably best to skip that strategy.

Weirdly, just foo.maybeColumn ==. maybeTable.column gives a type error with both monomorphic just and polymorphic just. And the error message is slightly worse with polymorphic just:

    • Couldn't match type: Maybe typ'
                     with: Key ExternalOnboardingData
        arising from a functional dependency between:
          constraint ‘GHC.Records.HasField
                        "id"
                        (SqlExpr (Maybe (Entity ExternalOnboardingData)))
                        (SqlExpr (Value (Key ExternalOnboardingData)))’
            arising from selecting the field ‘id’
          instance ‘GHC.Records.HasField
                      sym (SqlExpr (Maybe (Entity rec))) (SqlExpr (Value (Maybe typ'1)))’
            at <no location info>

compared to -- ah, well, alas. Actually the just foo.bar ==. mfoo.col has the same type error information, because it's coming from the mfoo.col rather than just. So even monomorphic just has some bad error messages. It's just that the polymorphic just doesn't have the errors.

OK, I'm pretty happy with the PR in this state. I've tested this out on Mercury's codebase and it's not a huge change, but it's a very good change.