<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I vote accept. <br><br>The proposal itself is well written, and clarifies the concepts involved and the issue at hand. <br><br>I am on the fence with the syntax itself. I like the one presented in the proposal, it's very clean. I was a bit worried at first with having to import the same module multiple times at different levels, but I guess that cannot really be avoided.<br>I like Richard's comment on having different sections, a `splice` section, a level 0 section and `quote` section. I'm also not against the `{-# SPLICE #-}` syntax if we decide to go down that route, but it's a bit grittier than the keywords.<br><br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 13 Jan 2025 at 09:27, Sebastian Graf <<a href="mailto:sgraf1337@gmail.com">sgraf1337@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>I vote to accept this proposal.</div><div><br></div><div>I would have liked to see a clear specification of what gets compiled when with -XImplicitStagePersistence, but I see that this isn't strictly necessary to describe the extension in terms of the Haskell-the-language, plus it's quite complicated. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2448500943" target="_blank">I attempted to do so at the end of this post</a>.</div><div><br></div><div>I don't agree that -XNoImplicitStagePersistence is a fork. After all, users are not forced to use `-XNoImplicitStagePersistence` just because one of its imports uses it.</div><div><br></div><div>Cheers,</div><div>Sebastian<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 10. Jan. 2025 um 12:20 Uhr schrieb Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>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</div><div>reasons. This proposal tries to address at least one of those: adding more clarity and explicitness about dependencies. It may help with</div><div>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</div><div>target evaluation, can rely on dead code elimination for this, but having this from the start would already be helpful).</div><div><br></div><div>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</div><div>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.<br></div><div><br></div><div>+1 on this one.<br></div><div><br></div><div>Best,</div><div> Moritz</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 10 Jan 2025 at 18:19, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks Arnaud! With my "proposal co-author" hat on, I'd like to make a <br>
few points inline...<br>
<br>
<br>
On 09/01/2025 06:34, Arnaud Spiwack wrote:<br>
><br>
> On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a> <br>
> <mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>>> wrote:<br>
><br>
> [...]<br>
> <br>
> They introduce a new extension-XNoImplicitStagePersistence which<br>
> disables that, and a little bit of syntax to specify the stage of<br>
> imports. That's it.<br>
> <br>
> But it comes with severe limitations, most importantly: you can't<br>
> ever use a symbol defined in the current module in a quote or splice<br>
> of this current module, typed template Haskell is turned off.<br>
<br>
Regarding typed TH, the proposal currently grants a bit of flexibility <br>
to the implementation in suggesting that TTH might not be supported at <br>
all, primarily because TTH has some existing unresolved issues around <br>
constraints. We could alternately say that TTH remains available (but <br>
also remains somewhat broken, because fixing it is out of scope of the <br>
implementation of this proposal).<br>
<br>
<br>
> For these situations, the proposal kind of advertises using<br>
> `-XImplicitStagePersistence`. Which does seem like a fork-like<br>
> situation to me. Not cool.<br>
<br>
Rather than seeing ImplicitStagePersistence as creating a language fork, <br>
I see it as necessary for backwards compatibility, but with the <br>
intention that in the long term NoImplicitStagePersistence is the way to <br>
go. This may still be difficult in some cases (e.g. codebases that make <br>
heavy use of Lift), but the idea is to start with a simple, restrictive <br>
baseline (NoImplicitStagePersistence) and then gradually add features <br>
relaxing this as needed (ExplicitLevelImports being the first of these, <br>
but perhaps later something for multiple levels within a single file).<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><span style="font-family:arial,helvetica,sans-serif;font-size:small">-- </span><a href="http://mpg.is/" style="font-family:arial,helvetica,sans-serif;font-size:small" target="_blank">Matthías Páll Gissurarson</a><br></div></div>