I am in favor of this proposal. As a side note: I think it is a bit sad that we need to burden the user with these complexities. While I will gladly turn the extension on and will specify the stages; this is one thing more to learn for new users of TemplateHaskell. I would prefer if we could infer the import stages, even though this hurts the "imports can be inferred from the header" rule. I made a small remark for clarification on GitHub. Regarding the open syntax question I feel like the most natural thing would be to put the "splice" next to the qualified. i.e. with QualifiedPost we put it post, and with out we put it pre. I would also be fine with allowing both or with always demanding post. My personal taste is that I would dislike to have only pre, but I mainly want the syntax selection process to be efficient and am fine either way. Best, Malte On 2025-01-10 20:19, Moritz Angermann wrote:
Hi all,
I'm generally in support of this proposal. As many of you know, I strongly believe TemplateHaskell is a major wart that Haskell has, for many reasons. This proposal tries to address at least one of those: adding more clarity and explicitness about dependencies. It may help with cross compilation in that we have a clearer idea of what we exactly need to load in iserv (alternatives where we implicit link a runnable for target evaluation, can rely on dead code elimination for this, but having this from the start would already be helpful).
I've recently been looking a lot at Zig's comptime, as they seem to have gone down almost the same route. Maybe there's some inspiration to be drawn from Zig's solution in the future. It is, however, WAY more restrictive than what we currently have in the form of TemplateHaskell.
+1 on this one.
Best, Moritz
On Fri, 10 Jan 2025 at 18:19, Adam Gundry <[1]adam@well-typed.com> wrote:
Thanks Arnaud! With my "proposal co-author" hat on, I'd like to make a few points inline...
On 09/01/2025 06:34, Arnaud Spiwack wrote: > > On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack <[2]arnaud.spiwack@tweag.io > mailto:[3]arnaud.spiwack@tweag.io> wrote: > > [...] > > They introduce a new extension-XNoImplicitStagePersistence which > disables that, and a little bit of syntax to specify the stage of > imports. That's it. > > But it comes with severe limitations, most importantly: you can't > ever use a symbol defined in the current module in a quote or splice > of this current module, typed template Haskell is turned off.
Regarding typed TH, the proposal currently grants a bit of flexibility to the implementation in suggesting that TTH might not be supported at all, primarily because TTH has some existing unresolved issues around constraints. We could alternately say that TTH remains available (but also remains somewhat broken, because fixing it is out of scope of the implementation of this proposal).
> For these situations, the proposal kind of advertises using > `-XImplicitStagePersistence`. Which does seem like a fork-like > situation to me. Not cool.
Rather than seeing ImplicitStagePersistence as creating a language fork, I see it as necessary for backwards compatibility, but with the intention that in the long term NoImplicitStagePersistence is the way to go. This may still be difficult in some cases (e.g. codebases that make heavy use of Lift), but the idea is to start with a simple, restrictive baseline (NoImplicitStagePersistence) and then gradually add features relaxing this as needed (ExplicitLevelImports being the first of these, but perhaps later something for multiple levels within a single file).
Cheers,
Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, [4]https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list [5]ghc-steering-committee@haskell.org [6]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-co mmittee
References
1. mailto:adam@well-typed.com 2. mailto:arnaud.spiwack@tweag.io 3. mailto:arnaud.spiwack@tweag.io 4. https://www.well-typed.com/ 5. mailto:ghc-steering-committee@haskell.org 6. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee