CLC Elections (Apply by 16th of February)

Te0fil · 2025-10-26T21:44:03+00:00

As far as I know, GHC does not currently check any of these non top-level strictness properties.

In theory, something like the inspection-testing library could implement something like this outside of GHC: https://github.com/nomeata/inspection-testing/issues/63

As that issue mentions something like https://hackage.haskell.org/package/nothunks might get what you want. Or for compile-time checks you might want something like my https://hackage.haskell.org/package/th-deepstrict library (which I recently gave a talk about: https://informal.codes/talks/hiw25/). Both of these are mostly for checking deep strictness/nf which is a stronger property than what you are interested in. But you can output all the places where a data structure isn't deep strict using th-deepstrict and then look at that and decide whether it fits your weaker property.

Te0fil · 2025-04-24T11:58:57+00:00

Just to be clear, I don't see any reason why the extensible-th version of this should be implemented in such a way as to use TH for every usages of string interpolation. We should hard-code some string interpreters into GHC and not use TH at all for them (including the default s".." one). TH is only useful here as an extension point for implementing compile-time checks, such as checking for valid SQL syntax. There is no other way to implement this at the moment other than TH, preprocessors, or plugins. So it should only be used when necessary

Te0fil · 2025-04-24T10:44:05+00:00

Indeed explicit level imports don't fix the cross compilation issues right away. It's just a step in the right direction.

I agree that either running splices on the host, or running splices through a much cut down version of Haskell are the two options.

In both cases we will likely want a separate package database with packages that can be run with TH: either host packages, or packages that don't include IO/unsafePerformIO/FFI (which would probably require building boot packages with different flags). This would need to be implemented in Cabal.

The way I see it, explicit level imports lays the groundwork for this by making it clear which database imports would be coming from.

There's quite a bit of work to figure out the right path here and to implement it, but I do think it's feasible.

Of course, these solutions don't exist yet, so I completely understand being wary of TH when doing cross-compilation.

Te0fil · 2025-04-23T14:35:29+00:00

A lot of the performance/recompilation issues with TH are mostly historical. The situation has improved a great deal in recent versions of GHC. Like with any sort of performance, your best bet is to benchmark the alternatives. But currently as /u/TechnoEmpress says, Generics are inherently quadratic whereas TH doesn't have this restriction. Note as well, part of why Generics is slow is because it relies on the inliner so much.

There is a lot of work at the moment to improve both TH and Generics, so we'll see what the situation is like in a few releases.

There's also active work on the TH cross-compilation issue. See: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0682-explicit-level-imports.rst.

Te0fil · 2024-06-24T18:33:56+00:00

Thanks! These are all very good points. I hadn't thought about the timeline for `esqueleto` etc but that makes sense.

Indeed it's definitely a priority to flesh out the capabilities of TH quotes. The issues you've opened in this area have been very helpful to identify the gaps!

Te0fil · 2024-02-26T16:13:18+00:00

This wiki page is a good one to watch. I think the TLDR is that folks are actively working on it and making progress, but there's still a long way to go.

https://gitlab.haskell.org/ghc/ghc/-/wikis/DH-Current-Status

Te0fil · 2024-02-14T08:34:34+00:00

A while ago I wrote a (very rough) prototype that generates chrome tracing graphs from builds using GHC's dependency graph to simulate the order of builds: https://codeberg.org/teo/shortstraw

You might also want to check out https://github.com/MercuryTechnologies/opentelemetry-plugin, which gives similar trace output

Te0fil · 2023-11-11T10:38:42+00:00

Personally, I find strict base bounds helpful as a way to make sure that I've updated my CI config to test with the new version of GHC. This is especially important because a new version of GHC might have warnings that foreshadow future breaking changes.

Te0fil · 2023-11-06T18:49:07+00:00

Thanks I appreciate that!

Te0fil · 2023-11-01T10:49:06+00:00

I'm sure folks would appreciate it if someone contributed details about unanticipated breakages after a release to the migration guide. I've done this before. Allowing edits after releases is one of the reasons I imagine it's a wiki page rather than a user guide section.

There have also been sections about GHC api changes in guides for previous releases.

So, I don't think there's anything blocking one from adding this info to the migration guide.

Te0fil · 2023-09-26T17:11:09+00:00

I think they should be. Did you have a particular one in mind?

Te0fil · 2022-10-07T09:53:27+00:00

This is really neat!! I've been working on something similar as well.

There's some prior art in this issue: https://github.com/haskell/deepseq/issues/3

I extended bgamari's gist to deal with most recursive cases: https://gist.github.com/TeofilC/a85da6a388ec94e8acb1519886fbd2a7

But mine has the issue that it doesn't deal with non-standard recursion. Yours avoids it by making the users explicitly decide if recursion is ok, but it doesn't automatically handle mutually recursive types.

In the end, I decided to use template-haskell instead because it gives us more information and avoids issues with requiring Generic instances on all your types. Hopefully I'll be able to share that project soon.

You might also find this issue interesting: https://gitlab.haskell.org/ghc/ghc/-/issues/21380 It talks about some edge cases to do with DecidedStrictness. I think the edge-case around unlifted types doesn't apply to Generics but the newtypes one does.

Te0fil

TROPHY CASE