<div dir="ltr"><div>Thanks. Indeed, considering -XNoImplicitStagePersistence a fork is reasonable by that definition.</div><div><br></div><div>Although I guess I was having trouble with interpreting "most" and "happy" in that statement of the first test...</div><div>I would think that "most" people do not write Template Haskell splice functions or quote definitions (well, yet) in which case I don't think their code would be affected at all and thus would be "happy" to activate it.<br></div><div><br></div><div>Regardless, I think the benefits of this proposal far outweigh the mildly forking behavior, which could be further remedied as per Adam's response.</div><div><br></div><div>Sebastian<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Am Di., 14. Jan. 2025 um 08:42 Uhr schrieb Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</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"><div dir="ltr">Sebastian writes:</div><div dir="ltr"><br></div><div dir="ltr">> 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 dir="ltr"><br></div><div>This isn't what we mean by forklike in our guidelines. We mean to avoid situations where the same code means different things depending on the extensions turned on and/or needing different modules having incompatible sets of extensions. Our README reads:</div><div><p style="margin-left:40px"> By a "fork" we mean</p><div style="margin-left:40px">
</div><ul style="margin-left:40px"><li>It fails the test "Is this extension something that most people would be happy to enable, even if they don't want to use it?";</li><li>And it also fails the test "Do we think there's a reasonable chance
this extension will make it into a future language standard?"; that is,
the proposal reflects the stylistic preferences of a subset of the
Haskell community, rather than a consensus about the direction that (in
the committee's judgement) we want to push the whole language.</li></ul><div style="margin-left:40px">
</div><p style="margin-left:40px">The idea is that unless we can see a path to a point where
everyone has the extension turned on, we're left with different groups
of people using incompatible dialects of the language. A similar problem
arises with extensions that are mutually incompatible.</p><p>I don't think this passes the first test, but it does pass the second (though that future is probably quite far!). And I think that the proposition that there's no way to make what we want of Template Haskell without breaking the first test is reasonable (see also Adam's email above). But still, this does create a forky situation for us, which I wouldn't be doing my job as a shepherd if I wasn't pointing it out.<br></p></div><div>/Arnaud<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Jan 2025 at 22:31, Matthías Páll Gissurarson <<a href="mailto:mpg@mpg.is" target="_blank">mpg@mpg.is</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 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 style="font-family:arial,helvetica,sans-serif"></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Jan 2025 at 09:27, Sebastian Graf <<a href="mailto:sgraf1337@gmail.com" target="_blank">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>
_______________________________________________<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><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div></div>
</blockquote></div>