-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilising template-haskell #16
Comments
@bgamari has noted the first step is using record field names. The second step is ghc-proposals/ghc-proposals#529 |
I'm guessing that this would also imply that we have smart constructors that only take the compulsory fields and any optional fields are added via record update? Since otherwise this would only be helpful for consuming not producing splices.
@Ericson2314 I'm excited about this proposal and I can see how it would make it easier to make template-haskell code backwards compatible. But it also seems like it would require a lot of rewriting of code that uses th to get the benefit. I wonder if we can keep backwards compatibility without using something like this. |
I'm basically wondering if we could use I'm not sure if this is feasible, since I'm assuming that writing such a mapping would be relatively easy (it might be hard or impossible). But, if it works then I think it would mean that downstream consumers wouldn't need to change anything to upgrade. |
@TeofilC Record fields and synonyms very much go together. And their deficiencies as a solution for "migrations" are not at all TH-specific and so worthy of addressing too.
I would not worry about this. Doing a one-time rewrite to avoid future breaking changes is absolutely worth it. |
Yeah I agree with you. It would definitely be worth it |
I'd be worried about using pattern synonyms here, because of the struggle to get completeness checking, along with some compile-time performance trouble. Instead, I've been idly thinking about some class ExpLike exp where
fromExp :: Exp -> exp
toExp :: exp -> Exp with one such class for each AST type. Then type-check Now, we can have a This approach adds some burden to GHC:
I think these costs are reasonable, though, and may provide a nice way forward. |
These still feel like issues worth fixing in general to me, however. We want "regular user code" to also be able to update data definitions with minimal pain. |
I think we might be able to minimise the work needed by just writing conversions between version N and N+1 and composing them somehow, eg, using some sort of fancy code generation. But that might be more trouble/complexity than it's worth We could also minimise effort by only having a handful of "LTS" template-haskell versions |
Yes, we could imagine chaining transformations, but I don't think much is saved by doing so, and it would be less performant. Yes, we would want to cap the number of LTS TH versions. Incidentally, one side effect of this plan is that, I think, my core-template-haskell AST could just be GHC's AST. Doing it this way means that any user code that uses TH would have to link against GHC, which maybe is bad. But actually if the AST were in a separate package (a long-term goal of @Ericson2314 I think), then this becomes more feasible. In any case, this is a "nice to have", not a requirement at all of this design. |
Could you link to some GHC issues for the issues you foresee with pattern synonyms @goldfirere ? |
Yes, I think we would want smart constructors as well. Moveover I think it would be quite reasonable to have a set of stable smart constructors which can construct only programs expressible in Haskell 2010. I would guess that these would satisfy a large fraction of TH usages and therefore eliminate much of the churn that it causes. We could similarly expose pattern synonyms matching against Haskell 2010 constructs, although the match-completeness problem is rather thorny here. |
I really like the idea of using I think we can divide the usages of the API into two broad categories: consuming and producing. I think most of the consumption of TH data is handled well by I'll try to explore this in the next couple of months. EDIT: I wrote this before reading the minutes from the last meeting. Feels like we are all vaguely on the same page. I too think that maybe just using quotes more is the way to go, and I don't really understand why that's not done more (other than in boot packages) |
If we can observe a number of usages actually being handled by The hypothetical package you propose seems as though it would only increase the surface area of what could ultimately be part of a "stable" interface to TH, correct? |
I think you are completely right @telser that there's a risk of just increasing the surface area. At the same time if we added a stable interface to the Of course all these issues would disappear if |
See also https://gitlab.haskell.org/ghc/ghc/-/issues/24021 which I raised independently of this discussion, but contains similar ideas. Thanks @TeofilC for pointing me here. I think the crucial first step is introducing a package distinction between "internal definitions" and "external view of AST", so that only the "internal" package is tightly coupled to GHC while the "external" package can be modified independently. There's a tricky question of how we design the API for the "external" package, and consequently how easy it is for it to support multiple GHC versions, but having the distinction at all would be a good start. |
I'd like to start a conversation about what steps we can take as a community to improve
template-haskell
backwards compatibility.The interface of
template-haskell
is tightly coupled to Haskell's syntax. This means that constructors and fields need to be added often as the language expands. Reacting to these changes normally just requires adding aNothing
value at use-sites, but over the entire ecosystem over several releases this can add up to a lot of work.My vague idea is to start publishing a package that exports a fixed
template-haskell
interface that isn't tied to a specific version of GHC. I think this can either happen by having minor versions oftemplate-haskell
support several GHCs or by creating a new package.The main thing I'd like from this discussion is to figure out if there's some unforeseen blockers and to find other people who are keen to work on this idea. I think the key thing to get something like this working is having enough people to comfortably maintain the compatibility shim.
The text was updated successfully, but these errors were encountered: