Just did a first look through the changes. Here's a few thoughts:

• The diff is very large right now and contains many changes that are not strictly related to GHC9.2.1 (e.g. a lot of whitespace changes / reformatting)
• On the Html problem: We should report this issue upstream to the GHC GitLab. Maybe it could be fixed by adding a special case for implicit parameters to the constraint? I'd try to avoid making all view type sigs more verbose.

Sorry for the silence here - I'm done moving across the country so I am looking at this again :)

Minimal reproduction of the behavior

I was able to come up with a minimal reproduction for the behavior of the new type checker in GHC 9.2:

type T = (?a :: Int) => IO ()

f :: [String] -> T
f xs = mapM_ g xs

g :: String -> T
g _ = pure ()

This fails:

• Couldn't match type: (?a::Int) => IO ()
                     with: IO b0
      Expected: String -> IO b0
        Actual: String -> T

but, the GHC devs actually knew this program would break. It turns out the transformations going on under the hood to get this to type check before were actually unsound and could change the semantics of the program.

Recommended fix by GHC devs

The recommended fix is to "just" manually eta-expand:

f :: [String] -> T
f xs = mapM_ (\x -> g x) xs

which for reasons beyond me, but also known by the GHC devs, type checks safely and correctly.

I don't think this is a "bug" that should be reported to GHC, since the behavior is exactly what is recorded in the GHC proposal. This mainly breaks IHP programs using forEach, but these can also be manually eta-expanded (and then compile properly)

[hsx| forEach rows renderRow |]  ===> [hsx| forEach rows (\row -> renderRow row)]

Problems with recommended fix

A very unsatisfying "gotcha", needed to remember to eta-expand only calls to forEach rendering Html. I can envision endless beginner questions about this and frustrating experiences for everyone.

Possible solutions?

• Manually eta-expand calls to forEach
• (currently implemented in this branch) Remove implicit constraint from Html, resulting in more verbose, but consistent code. Could also ship this change along with a script to manually update all functions returning Html to add an implicit constraint to the beginning of the type signature.
• Possibly write a type checker plugin? I'm not sure exactly what it would do or how to do it but I'd imagine there's some proof we can give GHC with a plugin to get it to type check our humble Html functions.

Personally, I'd vote for the removal of the constraint from Html. IHP users already understand the need for implicit constraints when writing controller helper functions, and it makes sense that a view that accesses the context needs an implicit constraint for the controller context. I believe this would result in the least amount of cognitive load, and removes a piece of magic in IHP that I think does more harm than good. It wasn't until I was looking into this issue until I understood why we can actually call fromContext in Html views.

thoughts here @mpscholten?

Conclusion

The type checker behavior we relied on before with the Html type synonym could change program semantics and was thus removed from GHC. There are various ways to solve this, each with a sizable set of trade offs. Sad days :(

I'm done moving across the country so I am looking at this again :)

Nice, welcome back! :)

--

I'm not happy with any of these solutions. All of them break existing IHP apps / require a lot of changes when updating.

While this might be expected behaviour in GHC9, IMO we should still file an issue on the GHC GitLab. Maybe there's some other trick we're not aware of. Or alternatively maybe it's possible that GHC automatically eta-expands functions with implicit parameters at the call-site to get back the previous behaviour (the unsound stuff only appears with other type magic, but might not specifically apply to implicit parameters).

If that doesn't lead to anything we can try a TC plugin. If that doesn't work as well, we'll make our implicit parameters explicit as you suggested.

Issue has been created: https://gitlab.haskell.org/ghc/ghc/-/issues/21168

Perfect thanks :)

Very sad news. After a long, hard battle with the type checker and awful circular dependencies I implemented SPJ's idea of wrapping the constraint in a newtype. It doesn't work...

e.g.

newtype Html = Html ((?context :: ControllerContext) => Html5.Html)

autoRefreshMeta :: Html
autoRefreshMeta = case fromFrozenContext @AutoRefreshState of
        AutoRefreshDisabled -> mempty
        AutoRefreshEnabled { sessionId } ->  [hsx|<meta property="ihp-auto-refresh-id" content={tshow sessionId}/>|]

• Unbound implicit parameter (?context::ControllerContext)
        arising from a use of ‘fromFrozenContext’

in order to construct this value, you need a (?context :: ControllerContext).
Without the context explicitly in the type it just doesn't make any sense.
TC plugin doesn't really make sense either (to me at least) -- fromFrozenContext requires we have a ?context, the TC plugin would have to just lie and change the type

I'm convinced now explicit constraints, with an included auto-fix tool for migrating code, are the way (really the only way) to go. It breaks code, but the breakages are very easy to fix and I should be able to make a script that fixes the code for you. thoughts @mpscholten?

Not happy with this. Then we need more options.

Here's another alternative:

In the past we've been thinking about replacing blaze html in HSX with a custom templating backend. We could make this replacement context-aware.

E.g. imagine this hsx code like this

type Html = ControllerContext -> HtmlStr

view :: Html
view = [hsx|hello {myFunc}|]

would generate a haskell expression à la

view = \context ->
    (htmlStr "hello world")
    <>
    (let ?context = context in (toHtml myFunc))

This would also require an ToHtml instance like this to be composable:

instance ToHtml (ControllerContext -> HtmlStr) where
    toHtml htmlWithoutContext = htmlWithoutContext ?context

Is someone working on this custom templating backend? With today's release of HLS supporting 9.2.2, it would be really nice to be able to upgrade to the latest version of GHC and use record dot syntax 🙏

@njaremko Yes, GHC 9 support is coming, maybe even in next release of IHP, As Marc pointed out, we need to make some changes to the HSX generator, so we don't break all the existing IHP apps.

newtype Html = Html ((?context :: ControllerContext) => Html5.Html)

autoRefreshMeta :: Html
autoRefreshMeta = case fromFrozenContext @AutoRefreshState of
        AutoRefreshDisabled -> mempty
        AutoRefreshEnabled { sessionId } ->  [hsx|<meta property="ihp-auto-refresh-id" content={tshow sessionId}/>|]

I think you should instead write...

newtype Html = Html { runHtml :: ((?context :: ControllerContext) => Html5.Html) }

autoRefreshMeta :: Html
autoRefreshMeta = Html $ case fromFrozenContext @AutoRefreshState of
        AutoRefreshDisabled -> runHtml mempty
        AutoRefreshEnabled { sessionId } ->  runHtml [hsx|<meta property="ihp-auto-refresh-id" content={tshow sessionId}/>|]

But another good question is why you don't just have

newtype Html = Html { runHtml :: ControllerContext -> Html5.Html }

That would probably be easier to program with.

ghc-proposals/ghc-proposals#511 If this is accepted we might be able to get by without any breaking code changes!! Just make that new extension a default and things should work just fine :D

re: @mpickering, sorry for the late response. I agree that's probably the better way to design the API, but I don't see a way to migrate the type to use that without breaking all of the existing code for IHP projects. Some breakage in rare circumstances would be fine, especially since we have GHC guiding us, but for this change, it would be in every single view file.

I really hope the proposal is accepted so we can get IHP on the latest GHCs without needing to break so much code! Thank you in particular for your work and understanding here.

GHC 9.2.4 just released with the DeepSubsumption language extension 🎉

I've given the update another try today. As this branch already had several changes on the HSX sides, I've started from scratch / master. The results can be found here: #1487

Closing this as GHC9 is on master already :)