#682: Explicit Level Imports, recommendation: accept
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682 I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better. But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay? Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only. 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. For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward. The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
I forgot: there's a bunch of alternative syntax, so if you don't like the proposed syntax, please let us know which alternative you prefer. On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
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 <arnaud.spiwack@tweag.io <mailto: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, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
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 <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 <arnaud.spiwack@tweag.io <mailto: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, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Hi, I vote to accept this proposal. 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. I attempted to do so at the end of this post <https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2448500943> . 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. Cheers, Sebastian Am Fr., 10. Jan. 2025 um 12:20 Uhr schrieb Moritz Angermann < moritz.angermann@gmail.com>:
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 <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 <arnaud.spiwack@tweag.io <mailto: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, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org 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
I vote accept. The proposal itself is well written, and clarifies the concepts involved and the issue at hand. 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. 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. On Mon, 13 Jan 2025 at 09:27, Sebastian Graf <sgraf1337@gmail.com> wrote:
Hi,
I vote to accept this proposal.
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. I attempted to do so at the end of this post <https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2448500943> .
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.
Cheers, Sebastian
Am Fr., 10. Jan. 2025 um 12:20 Uhr schrieb Moritz Angermann < moritz.angermann@gmail.com>:
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 <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 <arnaud.spiwack@tweag.io <mailto: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, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org 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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- -- Matthías Páll Gissurarson <http://mpg.is/>
Sebastian writes:
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.
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: By a "fork" we mean - 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?"; - 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. 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. 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. /Arnaud On Mon, 13 Jan 2025 at 22:31, Matthías Páll Gissurarson <mpg@mpg.is> wrote:
I vote accept.
The proposal itself is well written, and clarifies the concepts involved and the issue at hand.
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. 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.
On Mon, 13 Jan 2025 at 09:27, Sebastian Graf <sgraf1337@gmail.com> wrote:
Hi,
I vote to accept this proposal.
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. I attempted to do so at the end of this post <https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2448500943> .
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.
Cheers, Sebastian
Am Fr., 10. Jan. 2025 um 12:20 Uhr schrieb Moritz Angermann < moritz.angermann@gmail.com>:
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 <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 <arnaud.spiwack@tweag.io <mailto: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, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org 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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- -- Matthías Páll Gissurarson <http://mpg.is/> _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
Thanks. Indeed, considering -XNoImplicitStagePersistence a fork is reasonable by that definition. Although I guess I was having trouble with interpreting "most" and "happy" in that statement of the first test... 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. Regardless, I think the benefits of this proposal far outweigh the mildly forking behavior, which could be further remedied as per Adam's response. Sebastian Am Di., 14. Jan. 2025 um 08:42 Uhr schrieb Arnaud Spiwack < arnaud.spiwack@tweag.io>:
Sebastian writes:
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.
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:
By a "fork" we mean
- 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?"; - 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.
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.
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. /Arnaud
On Mon, 13 Jan 2025 at 22:31, Matthías Páll Gissurarson <mpg@mpg.is> wrote:
I vote accept.
The proposal itself is well written, and clarifies the concepts involved and the issue at hand.
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. 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.
On Mon, 13 Jan 2025 at 09:27, Sebastian Graf <sgraf1337@gmail.com> wrote:
Hi,
I vote to accept this proposal.
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. I attempted to do so at the end of this post <https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2448500943> .
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.
Cheers, Sebastian
Am Fr., 10. Jan. 2025 um 12:20 Uhr schrieb Moritz Angermann < moritz.angermann@gmail.com>:
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 <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 <arnaud.spiwack@tweag.io <mailto: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, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- -- Matthías Páll Gissurarson <http://mpg.is/> _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
I want to add something. If we accept this (and I think we should), then we should strive to consider this a new beginning for Template Haskell, and what we consider the future of Template Haskell to be. It means that (as much as reasonable) every Template Haskell proposal will now be meant to primarily extend this one. In particular it'll be fine if a new proposal is incompatible with `-XImplictStagePersistence`, but not if it is incompatible with `-XNoImplicitPersistence`. I think that it's what we must be ready to commit to.
This is very easy for me to commit to. On Wed, Jan 15, 2025 at 2:58 PM Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
I want to add something. If we accept this (and I think we should), then we should strive to consider this a new beginning for Template Haskell, and what we consider the future of Template Haskell to be. It means that (as much as reasonable) every Template Haskell proposal will now be meant to primarily extend this one. In particular it'll be fine if a new proposal is incompatible with `-XImplictStagePersistence`, but not if it is incompatible with `-XNoImplicitPersistence`. I think that it's what we must be ready to commit to. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
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
Like Moritz, I am not a huge fan of TH, but do recognize its usefulness. Any improvement to TH that impriove its clarity has my support. +1 Cheers, Erik 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 <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 <arnaud.spiwack@tweag.io <mailto: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, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Seems reasonable and the impact seems minimal in practice (I like the pandoc example). In fact in our Buck2 build system at Meta we already have a similar distinction between compile-time and runtime dependencies but it doesn't have the corresponding language support, so getting the build system settings wrong can lead to weird compile errors - well, compile-time link errors typically. +1 Simon On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Arnaud I have responded with a lot of feedback on the Github thread <https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116> . TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet. I have arranged a call with Matthew. Simon On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Then, let's wait until your call with Matthew and decide how to act then. On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Arnaud
I have responded with a lot of feedback on the Github thread <https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116> .
TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet.
I have arranged a call with Matthew.
Simon
On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
Matthew and I had a good conversation. Some notes here <https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing>. He's going to work on a revision to the proposal which I'll iterate with him. Simon On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Then, let's wait until your call with Matthew and decide how to act then.
On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Arnaud
I have responded with a lot of feedback on the Github thread <https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116> .
TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet.
I have arranged a call with Matthew.
Simon
On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
Arnaud OK, following my call and some further iteration, the proposal is much improved. See here <https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please read the new "Proposed Change Specification" which has had a large rewrite. I vote to accept. BUT there is one point that the committee must resolve: *one extension of two?* It's just a judgement call and I lay out the choices in this post <https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731>. I doubt that we'll get much community feedback. I suggest that we just vote. I vote for one, not two. As does Sebastian. Over to you Arnaud. Let's get this one done. Matthew is busy implementing it for a customer and it has been on our to-do list for some time now. (Partly my fault.) Simon On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Matthew and I had a good conversation. Some notes here <https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing>.
He's going to work on a revision to the proposal which I'll iterate with him.
Simon
On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Then, let's wait until your call with Matthew and decide how to act then.
On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Arnaud
I have responded with a lot of feedback on the Github thread <https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116> .
TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet.
I have arranged a call with Matthew.
Simon
On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
I'm (unsurprisingly) in favour of acceptance, and I vote for two extensions. As I commented on the GitHub thread:
We shouldn't unnecessarily conflate a syntactic extension (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) just because the common case is to want both and we want to keep the number of extensions lower.
If there are reasons why having two extensions is actually problematic, I'd like to hear them. Also, at the risk of opening another avenue of discussion, we also need to resolve the syntax question (see https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232...). I don't have a very strong opinion here, but given that some people do, perhaps we should make ImportQualifiedPost affect splice imports so we have import splice qualified A -- By default import A splice qualified -- Under ImportQualifiedPost In any case, please do vote! It would be good to get this proposal done. Cheers, Adam On 27/01/2025 11:52, Simon Peyton Jones wrote:
Arnaud
OK, following my call and some further iteration, the proposal is much improved. See here <https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please read the new "Proposed Change Specification" which has had a large rewrite.
I vote to accept.
BUT there is one point that the committee must resolve: *one extension of two?* It's just a judgement call and I lay out the choices in this post <https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731>. I doubt that we'll get much community feedback. I suggest that we just vote. I vote for one, not two. As does Sebastian.
Over to you Arnaud. Let's get this one done. Matthew is busy implementing it for a customer and it has been on our to-do list for some time now. (Partly my fault.)
Simon
On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Matthew and I had a good conversation. Some notes here <https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing>.
He's going to work on a revision to the proposal which I'll iterate with him.
Simon
On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Then, let's wait until your call with Matthew and decide how to act then.
On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Arnaud
I have responded with a lot of feedback on the Github thread <https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116>.
TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet.
I have arranged a call with Matthew.
Simon
On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682 <https://github.com/ghc-proposals/ghc-proposals/pull/682>
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
Yes: all members of the steering committee, please vote. Evaluating proposals is what we all signed up to do! Thanks Simon On Mon, 3 Feb 2025 at 20:45, Adam Gundry <adam@well-typed.com> wrote:
I'm (unsurprisingly) in favour of acceptance, and I vote for two extensions. As I commented on the GitHub thread:
We shouldn't unnecessarily conflate a syntactic extension (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) just because the common case is to want both and we want to keep the number of extensions lower.
If there are reasons why having two extensions is actually problematic, I'd like to hear them.
Also, at the risk of opening another avenue of discussion, we also need to resolve the syntax question (see
https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232...).
I don't have a very strong opinion here, but given that some people do, perhaps we should make ImportQualifiedPost affect splice imports so we have
import splice qualified A -- By default import A splice qualified -- Under ImportQualifiedPost
In any case, please do vote! It would be good to get this proposal done.
Cheers,
Adam
On 27/01/2025 11:52, Simon Peyton Jones wrote:
Arnaud
OK, following my call and some further iteration, the proposal is much improved. See here <https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please read the new "Proposed Change Specification" which has had a large rewrite.
I vote to accept.
BUT there is one point that the committee must resolve: *one extension of two?* It's just a judgement call and I lay out the choices in this post < https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731>. I doubt that we'll get much community feedback. I suggest that we just vote. I vote for one, not two. As does Sebastian.
Over to you Arnaud. Let's get this one done. Matthew is busy implementing it for a customer and it has been on our to-do list for some time now. (Partly my fault.)
Simon
On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Matthew and I had a good conversation. Some notes here < https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... .
He's going to work on a revision to the proposal which I'll iterate with him.
Simon
On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Then, let's wait until your call with Matthew and decide how to act then.
On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Arnaud
I have responded with a lot of feedback on the Github thread < https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... .
TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet.
I have arranged a call with Matthew.
Simon
On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682 <https://github.com/ghc-proposals/ghc-proposals/pull/682
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Sorry I disappeared for a while. I second Simon's call, let's vote. Let me repost a link to Simon's pro and cons post https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... So far, we have the following votes - Simon: 1 extension - Adam: 2 extension (feels quite strongly about it) - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote anyway) Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? --- Beyond that we have a single piece of community feedback on the Github thread. It's from Michael Peyton Jones who is in favour of 2 extensions, find it here https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... --- For the record, I hadn't commented about it in my recommendation, despite my well-known and desperately public distaste for micro extensions. I have a couple of reasons: - I dislike micro-extensions less now that we are doing the GHC20XX (the last one was very modest, I'm in favour, by the way, of doing a much more ambitious language edition soon, otherwise my distaste will come back with a vengeance) - While I consider every proposal with several extensions in it with suspicion, the authors did argue for their second extension, I found the argument mildly convincing, and thought it wasn't worth fighting against. Now, even like this my preference is mildly for one extension. Adam says that it's easier to implement warnings with both the new syntax on and implicit stage persistence left turned on, than to implement errors when implicit stage persistence is turned off. It may be so, but I don't think we can avoid implementing the errors anyway, so I don't feel that it's a particularly compelling argument. I don't feel strongly. But that's presumably where my vote goes. On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
Yes: all members of the steering committee, please vote. Evaluating proposals is what we all signed up to do!
Thanks
Simon
On Mon, 3 Feb 2025 at 20:45, Adam Gundry <adam@well-typed.com> wrote:
I'm (unsurprisingly) in favour of acceptance, and I vote for two extensions. As I commented on the GitHub thread:
We shouldn't unnecessarily conflate a syntactic extension (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) just because the common case is to want both and we want to keep the number of extensions lower.
If there are reasons why having two extensions is actually problematic, I'd like to hear them.
Also, at the risk of opening another avenue of discussion, we also need to resolve the syntax question (see
https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232...).
I don't have a very strong opinion here, but given that some people do, perhaps we should make ImportQualifiedPost affect splice imports so we have
import splice qualified A -- By default import A splice qualified -- Under ImportQualifiedPost
In any case, please do vote! It would be good to get this proposal done.
Cheers,
Adam
On 27/01/2025 11:52, Simon Peyton Jones wrote:
Arnaud
OK, following my call and some further iteration, the proposal is much improved. See here <https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please read the new "Proposed Change Specification" which has had a large rewrite.
I vote to accept.
BUT there is one point that the committee must resolve: *one extension of two?* It's just a judgement call and I lay out the choices in this post < https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731>. I doubt that we'll get much community feedback. I suggest that we just vote. I vote for one, not two. As does Sebastian.
Over to you Arnaud. Let's get this one done. Matthew is busy implementing it for a customer and it has been on our to-do list for some time now. (Partly my fault.)
Simon
On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Matthew and I had a good conversation. Some notes here < https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... .
He's going to work on a revision to the proposal which I'll iterate with him.
Simon
On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Then, let's wait until your call with Matthew and decide how to act then.
On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Arnaud
I have responded with a lot of feedback on the Github thread < https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... .
TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet.
I have arranged a call with Matthew.
Simon
On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682 < https://github.com/ghc-proposals/ghc-proposals/pull/682>
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org 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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
Hi, I have read through the proposal, but there is something I am still unsure of. For the LANGUAGE pragma's is there any utility in using one separately form the other? It seems there isn't. In any one file you would use either one or the other. Thanks, Erik Arnaud Spiwack wrote:
Sorry I disappeared for a while. I second Simon's call, let's vote. Let me repost a link to Simon's pro and cons post https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199...
So far, we have the following votes
- Simon: 1 extension - Adam: 2 extension (feels quite strongly about it) - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote anyway)
Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think?
---
Beyond that we have a single piece of community feedback on the Github thread. It's from Michael Peyton Jones who is in favour of 2 extensions, find it here https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583...
---
For the record, I hadn't commented about it in my recommendation, despite my well-known and desperately public distaste for micro extensions. I have a couple of reasons: - I dislike micro-extensions less now that we are doing the GHC20XX (the last one was very modest, I'm in favour, by the way, of doing a much more ambitious language edition soon, otherwise my distaste will come back with a vengeance) - While I consider every proposal with several extensions in it with suspicion, the authors did argue for their second extension, I found the argument mildly convincing, and thought it wasn't worth fighting against.
Now, even like this my preference is mildly for one extension. Adam says that it's easier to implement warnings with both the new syntax on and implicit stage persistence left turned on, than to implement errors when implicit stage persistence is turned off. It may be so, but I don't think we can avoid implementing the errors anyway, so I don't feel that it's a particularly compelling argument. I don't feel strongly. But that's presumably where my vote goes.
On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
Yes: all members of the steering committee, please vote. Evaluating proposals is what we all signed up to do!
Thanks
Simon
On Mon, 3 Feb 2025 at 20:45, Adam Gundry <adam@well-typed.com> wrote:
I'm (unsurprisingly) in favour of acceptance, and I vote for two extensions. As I commented on the GitHub thread:
We shouldn't unnecessarily conflate a syntactic extension (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) just because the common case is to want both and we want to keep the number of extensions lower.
If there are reasons why having two extensions is actually problematic, I'd like to hear them.
Also, at the risk of opening another avenue of discussion, we also need to resolve the syntax question (see
https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232...).
I don't have a very strong opinion here, but given that some people do, perhaps we should make ImportQualifiedPost affect splice imports so we have
import splice qualified A -- By default import A splice qualified -- Under ImportQualifiedPost
In any case, please do vote! It would be good to get this proposal done.
Cheers,
Adam
On 27/01/2025 11:52, Simon Peyton Jones wrote:
Arnaud
OK, following my call and some further iteration, the proposal is much improved. See here <https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please read the new "Proposed Change Specification" which has had a large rewrite.
I vote to accept.
BUT there is one point that the committee must resolve: *one extension of two?* It's just a judgement call and I lay out the choices in this post < https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731>. I doubt that we'll get much community feedback. I suggest that we just vote. I vote for one, not two. As does Sebastian.
Over to you Arnaud. Let's get this one done. Matthew is busy implementing it for a customer and it has been on our to-do list for some time now. (Partly my fault.)
Simon
On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Matthew and I had a good conversation. Some notes here < https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... .
He's going to work on a revision to the proposal which I'll iterate with him.
Simon
On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Then, let's wait until your call with Matthew and decide how to act then.
On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Arnaud
I have responded with a lot of feedback on the Github thread < https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... .
TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet.
I have arranged a call with Matthew.
Simon
On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682 < https://github.com/ghc-proposals/ghc-proposals/pull/682>
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org 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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
I don't feel strongly about 1 vs 2 extensions, because I think the direction of travel is away from recommending individual extensions as a way to interact with the compiler and towards GHC20xx instead. And in GHC20xx I think we would enable either both or neither of these extensions, correct? Cheers Simon On Wed, 5 Feb 2025 at 08:16, Erik de Castro Lopo <erikd@mega-nerd.com> wrote:
Hi,
I have read through the proposal, but there is something I am still unsure of. For the LANGUAGE pragma's is there any utility in using one separately form the other? It seems there isn't. In any one file you would use either one or the other.
Thanks, Erik
Arnaud Spiwack wrote:
Sorry I disappeared for a while. I second Simon's call, let's vote. Let me repost a link to Simon's pro and cons post
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199...
So far, we have the following votes
- Simon: 1 extension - Adam: 2 extension (feels quite strongly about it) - Sebastian: 1 extension (on the Github thread, but I'll count it as a
vote
anyway)
Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think?
---
Beyond that we have a single piece of community feedback on the Github thread. It's from Michael Peyton Jones who is in favour of 2 extensions, find it here
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583...
---
For the record, I hadn't commented about it in my recommendation, despite my well-known and desperately public distaste for micro extensions. I
have
a couple of reasons: - I dislike micro-extensions less now that we are doing the GHC20XX (the last one was very modest, I'm in favour, by the way, of doing a much more ambitious language edition soon, otherwise my distaste will come back with a vengeance) - While I consider every proposal with several extensions in it with suspicion, the authors did argue for their second extension, I found the argument mildly convincing, and thought it wasn't worth fighting against.
Now, even like this my preference is mildly for one extension. Adam says that it's easier to implement warnings with both the new syntax on and implicit stage persistence left turned on, than to implement errors when implicit stage persistence is turned off. It may be so, but I don't think we can avoid implementing the errors anyway, so I don't feel that it's a particularly compelling argument. I don't feel strongly. But that's presumably where my vote goes.
On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Yes: all members of the steering committee, please vote. Evaluating proposals is what we all signed up to do!
Thanks
Simon
On Mon, 3 Feb 2025 at 20:45, Adam Gundry <adam@well-typed.com> wrote:
I'm (unsurprisingly) in favour of acceptance, and I vote for two extensions. As I commented on the GitHub thread:
We shouldn't unnecessarily conflate a syntactic extension (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) just because the common case is to want both and we want to keep the number of extensions lower.
If there are reasons why having two extensions is actually problematic, I'd like to hear them.
Also, at the risk of opening another avenue of discussion, we also need to resolve the syntax question (see
https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... ).
I don't have a very strong opinion here, but given that some people
do,
perhaps we should make ImportQualifiedPost affect splice imports so we have
import splice qualified A -- By default import A splice qualified -- Under ImportQualifiedPost
In any case, please do vote! It would be good to get this proposal done.
Cheers,
Adam
On 27/01/2025 11:52, Simon Peyton Jones wrote:
Arnaud
OK, following my call and some further iteration, the proposal is much improved. See here <https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please read the new "Proposed Change Specification" which has had a large rewrite.
I vote to accept.
BUT there is one point that the committee must resolve: *one extension of two?* It's just a judgement call and I lay out the choices in this post <
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... .
I doubt that we'll get much community feedback. I suggest that we just vote. I vote for one, not two. As does Sebastian.
Over to you Arnaud. Let's get this one done. Matthew is busy implementing it for a customer and it has been on our to-do list for some time now. (Partly my fault.)
Simon
On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>>
wrote:
Matthew and I had a good conversation. Some notes here <
https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y...
.
He's going to work on a revision to the proposal which I'll iterate with him.
Simon
On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Then, let's wait until your call with Matthew and decide how to act then.
On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Arnaud
I have responded with a lot of feedback on the Github thread <
https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25...
.
TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet.
I have arranged a call with Matthew.
Simon
On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto: arnaud.spiwack@tweag.io>> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell
https://github.com/ghc-proposals/ghc-proposals/pull/682
<
https://github.com/ghc-proposals/ghc-proposals/pull/682>
I've got to be honest, I'm not fully convinced by
the
proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this
leads to
a somewhat fork-like situation for which it isn't
clear
whether it will be resolved in the future. That
being
said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe
that we
can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be
available
for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less
responsive
and you recompile more files. Yay?
Anyway, the general gist of the solution is clear:
we
must be able to specify that we don't want to
import a
module for Template Haskell (there is subtleties in
this
too as you will want a little more control than
that for
cross-compilation reasons which I'm not competent
about
to comment on). But the devil is in the many
details.
There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of
advertises
using `-XImplicitStagePersistence`. Which does seem
like
a fork-like situation to me. Not cool. Yet… yet
Template
Haskell is a big messy ball of yarn, and I don't
think
it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to
support
this case. And I believe the authors are correct
when
they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out
there.
So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but
it's
probably the most reasonable way forward.
The real problem with this sort of proposal is that
then
I get to write way too long an email to the
committee.
Hopefully this didn't deter you. Read the proposal,
and
let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Simon M: I'm pretty we would enable either both or neither in editions, yes. --- Erik: See the argument summarized by Simon PJ here https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... , and the handful of comment below, these are the arguments which have been laid down so far for either side of this conversation. My summary of the summary is that there are two envisioned use-case for turning on ExplicitLevelImports while leaving ImplicitStagePersistence on: - Migration (this help compile a project, but progressively follow warnings to prepare a project for NoImplicitStagePersistence) - Exceptional ImplicitStagePersistence: in the current state of the library, it seems that you will sometimes need to use ImplicitStagePersistence (to define Lift function, perhaps, or in a module where you define a bunch of Template Haskell: not every problem has been solved). But because you are in a project which uses ExplicitLevelImport everywhere, you may want to still mark your imports consistently with the rest of the project, as being imports for slices, quotes, or neither. On Thu, 6 Feb 2025 at 00:37, Simon Marlow <marlowsd@gmail.com> wrote:
I don't feel strongly about 1 vs 2 extensions, because I think the direction of travel is away from recommending individual extensions as a way to interact with the compiler and towards GHC20xx instead. And in GHC20xx I think we would enable either both or neither of these extensions, correct?
Cheers Simon
On Wed, 5 Feb 2025 at 08:16, Erik de Castro Lopo <erikd@mega-nerd.com> wrote:
Hi,
I have read through the proposal, but there is something I am still unsure of. For the LANGUAGE pragma's is there any utility in using one separately form the other? It seems there isn't. In any one file you would use either one or the other.
Thanks, Erik
Arnaud Spiwack wrote:
Sorry I disappeared for a while. I second Simon's call, let's vote. Let me repost a link to Simon's pro and cons post
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199...
So far, we have the following votes
- Simon: 1 extension - Adam: 2 extension (feels quite strongly about it) - Sebastian: 1 extension (on the Github thread, but I'll count it as a
vote
anyway)
Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think?
---
Beyond that we have a single piece of community feedback on the Github thread. It's from Michael Peyton Jones who is in favour of 2 extensions, find it here
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583...
---
For the record, I hadn't commented about it in my recommendation,
despite
my well-known and desperately public distaste for micro extensions. I have a couple of reasons: - I dislike micro-extensions less now that we are doing the GHC20XX (the last one was very modest, I'm in favour, by the way, of doing a much more ambitious language edition soon, otherwise my distaste will come back with a vengeance) - While I consider every proposal with several extensions in it with suspicion, the authors did argue for their second extension, I found the argument mildly convincing, and thought it wasn't worth fighting against.
Now, even like this my preference is mildly for one extension. Adam says that it's easier to implement warnings with both the new syntax on and implicit stage persistence left turned on, than to implement errors when implicit stage persistence is turned off. It may be so, but I don't think we can avoid implementing the errors anyway, so I don't feel that it's a particularly compelling argument. I don't feel strongly. But that's presumably where my vote goes.
On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Yes: all members of the steering committee, please vote. Evaluating proposals is what we all signed up to do!
Thanks
Simon
On Mon, 3 Feb 2025 at 20:45, Adam Gundry <adam@well-typed.com> wrote:
I'm (unsurprisingly) in favour of acceptance, and I vote for two extensions. As I commented on the GitHub thread:
We shouldn't unnecessarily conflate a syntactic extension (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) just because the common case is to want both and we want to keep the number of extensions lower.
If there are reasons why having two extensions is actually problematic, I'd like to hear them.
Also, at the risk of opening another avenue of discussion, we also need to resolve the syntax question (see
https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... ).
I don't have a very strong opinion here, but given that some people
do,
perhaps we should make ImportQualifiedPost affect splice imports so we have
import splice qualified A -- By default import A splice qualified -- Under ImportQualifiedPost
In any case, please do vote! It would be good to get this proposal done.
Cheers,
Adam
On 27/01/2025 11:52, Simon Peyton Jones wrote:
Arnaud
OK, following my call and some further iteration, the proposal is much improved. See here <https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please read the new "Proposed Change Specification" which has had a large rewrite.
I vote to accept.
BUT there is one point that the committee must resolve: *one extension of two?* It's just a judgement call and I lay out the choices in this post <
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... .
I doubt that we'll get much community feedback. I suggest that we just vote. I vote for one, not two. As does Sebastian.
Over to you Arnaud. Let's get this one done. Matthew is busy implementing it for a customer and it has been on our to-do list
for
some time now. (Partly my fault.)
Simon
On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Matthew and I had a good conversation. Some notes here <
https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y...
.
He's going to work on a revision to the proposal which I'll iterate with him.
Simon
On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Then, let's wait until your call with Matthew and decide how to act then.
On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Arnaud
I have responded with a lot of feedback on the Github thread <
https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25...
.
TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet.
I have arranged a call with Matthew.
Simon
On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto: arnaud.spiwack@tweag.io>> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell
https://github.com/ghc-proposals/ghc-proposals/pull/682
<
https://github.com/ghc-proposals/ghc-proposals/pull/682>
I've got to be honest, I'm not fully convinced by
the
proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem
by
solving the absolute minimal problem, but this
leads to
a somewhat fork-like situation for which it isn't
clear
whether it will be resolved in the future. That
being
said, it solves a real problem which has plagued
GHC
compilation forever. And I'm inclined to believe
that we
can't really do much better.
But I'm getting ahead of myself. The problem is
that
when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be
available
for typechecking. This breaks `-fno-code` and
wounds
recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less
responsive
and you recompile more files. Yay?
Anyway, the general gist of the solution is clear:
we
must be able to specify that we don't want to
import a
module for Template Haskell (there is subtleties
in this
too as you will want a little more control than
that for
cross-compilation reasons which I'm not competent
about
to comment on). But the devil is in the many
details.
There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available
in
quotes and splices anyway. Sigh… So you have to
turn
this off. This is what the proposal does. And
pretty
much only.
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.
For these situations, the proposal kind of
advertises
using `-XImplicitStagePersistence`. Which does
seem like
a fork-like situation to me. Not cool. Yet… yet
Template
Haskell is a big messy ball of yarn, and I don't
think
it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to
support
this case. And I believe the authors are correct
when
they claim that this proposal, in practice, covers
a
vast majority of the uses of Template Haskell out
there.
So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but
it's
probably the most reasonable way forward.
The real problem with this sort of proposal is
that then
I get to write way too long an email to the
committee.
Hopefully this didn't deter you. Read the
proposal, and
let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
Sorry for the late reply! After reading the thread, I'm slightly in favor of having 2 extensions. While I agree that we already have too many extensions, the case for having two extensions is convincing. As Arnaud mentioned, extensions are often used in a long list in the .cabal file, and being able to have ExplicitLevelImports enabled during refactoring seems to be a win. We want to keep migration costs minimal. The subtle case of the list of extensions being order-dependent (as Richard mentioned) is a bit troubling, but I agree that that should be left to another proposal. On Thu, 6 Feb 2025 at 08:26, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
Simon M: I'm pretty we would enable either both or neither in editions, yes.
---
Erik: See the argument summarized by Simon PJ here https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... , and the handful of comment below, these are the arguments which have been laid down so far for either side of this conversation. My summary of the summary is that there are two envisioned use-case for turning on ExplicitLevelImports while leaving ImplicitStagePersistence on:
- Migration (this help compile a project, but progressively follow warnings to prepare a project for NoImplicitStagePersistence) - Exceptional ImplicitStagePersistence: in the current state of the library, it seems that you will sometimes need to use ImplicitStagePersistence (to define Lift function, perhaps, or in a module where you define a bunch of Template Haskell: not every problem has been solved). But because you are in a project which uses ExplicitLevelImport everywhere, you may want to still mark your imports consistently with the rest of the project, as being imports for slices, quotes, or neither.
On Thu, 6 Feb 2025 at 00:37, Simon Marlow <marlowsd@gmail.com> wrote:
I don't feel strongly about 1 vs 2 extensions, because I think the direction of travel is away from recommending individual extensions as a way to interact with the compiler and towards GHC20xx instead. And in GHC20xx I think we would enable either both or neither of these extensions, correct?
Cheers Simon
On Wed, 5 Feb 2025 at 08:16, Erik de Castro Lopo <erikd@mega-nerd.com> wrote:
Hi,
I have read through the proposal, but there is something I am still unsure of. For the LANGUAGE pragma's is there any utility in using one separately form the other? It seems there isn't. In any one file you would use either one or the other.
Thanks, Erik
Arnaud Spiwack wrote:
Sorry I disappeared for a while. I second Simon's call, let's vote. Let me repost a link to Simon's pro and cons post
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199...
So far, we have the following votes
- Simon: 1 extension - Adam: 2 extension (feels quite strongly about it) - Sebastian: 1 extension (on the Github thread, but I'll count it as a
vote
anyway)
Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think?
---
Beyond that we have a single piece of community feedback on the Github thread. It's from Michael Peyton Jones who is in favour of 2 extensions, find it here
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583...
---
For the record, I hadn't commented about it in my recommendation,
despite
my well-known and desperately public distaste for micro extensions. I have a couple of reasons: - I dislike micro-extensions less now that we are doing the GHC20XX (the last one was very modest, I'm in favour, by the way, of doing a much more ambitious language edition soon, otherwise my distaste will come back with a vengeance) - While I consider every proposal with several extensions in it with suspicion, the authors did argue for their second extension, I found the argument mildly convincing, and thought it wasn't worth fighting against.
Now, even like this my preference is mildly for one extension. Adam says that it's easier to implement warnings with both the new syntax on and implicit stage persistence left turned on, than to implement errors when implicit stage persistence is turned off. It may be so, but I don't think we can avoid implementing the errors anyway, so I don't feel that it's a particularly compelling argument. I don't feel strongly. But that's presumably where my vote goes.
On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Yes: all members of the steering committee, please vote. Evaluating proposals is what we all signed up to do!
Thanks
Simon
On Mon, 3 Feb 2025 at 20:45, Adam Gundry <adam@well-typed.com> wrote:
I'm (unsurprisingly) in favour of acceptance, and I vote for two extensions. As I commented on the GitHub thread:
> We shouldn't unnecessarily conflate a syntactic extension (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) just because the common case is to want both and we want to keep the number of extensions lower.
If there are reasons why having two extensions is actually problematic, I'd like to hear them.
Also, at the risk of opening another avenue of discussion, we also need to resolve the syntax question (see
https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... ).
I don't have a very strong opinion here, but given that some people
do,
perhaps we should make ImportQualifiedPost affect splice imports so we have
import splice qualified A -- By default import A splice qualified -- Under ImportQualifiedPost
In any case, please do vote! It would be good to get this proposal done.
Cheers,
Adam
On 27/01/2025 11:52, Simon Peyton Jones wrote: > Arnaud > > OK, following my call and some further iteration, the proposal is much > improved. See here > <https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please read > the new "Proposed Change Specification" which has had a large rewrite. > > I vote to accept. > > BUT there is one point that the committee must resolve: *one extension > of two?* It's just a judgement call and I lay out the choices in this > post > <
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... .
I doubt that we'll get much community feedback. I suggest that we just vote. I vote for one, not two. As does Sebastian. > > Over to you Arnaud. Let's get this one done. Matthew is busy > implementing it for a customer and it has been on our to-do list for > some time now. (Partly my fault.) > > Simon > > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com
wrote: > > Matthew and I had a good conversation. Some notes here > <
https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y...
>. > > He's going to work on a revision to the proposal which I'll iterate > with him. > > Simon > > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote: > > Then, let's wait until your call with Matthew and decide how to > act then. > > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > <simon.peytonjones@gmail.com > <mailto:simon.peytonjones@gmail.com>> wrote: > > Arnaud > > I have responded with a lot of feedback on the Github thread > <
https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25...
>. > > TL:DR: I like the direction of travel but have too many > questions of detail to be ready to accept it just yet. > > I have arranged a call with Matthew. > > Simon > > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > <arnaud.spiwack@tweag.io <mailto: arnaud.spiwack@tweag.io>> > wrote: > > > Mathew Pickering, Rodrigo Mesquita, and our own Adam > Gundry put forward a new proposal for the perenial > problem of dependencies and Template Haskell > https://github.com/ghc-proposals/ghc-proposals/pull/682 > < https://github.com/ghc-proposals/ghc-proposals/pull/682> > > I've got to be honest, I'm not fully convinced by the > proposal. More on that in a minute, but it learns a > lesson from previous attempts at the same problem by > solving the absolute minimal problem, but this leads to > a somewhat fork-like situation for which it isn't clear > whether it will be resolved in the future. That being > said, it solves a real problem which has plagued GHC > compilation forever. And I'm inclined to believe that we > can't really do much better. > > But I'm getting ahead of myself. The problem is that > when you have -XTemplateHaskell in a file, all the > dependencies' compiled code must suddenly be available > for typechecking. This breaks `-fno-code` and wounds > recompilation avoidance. This is probably the main > reason why it's a widely held belief that Template > Haskell is slow: you use Template Haskell in a few > modules, and suddenly your IDE is much less responsive > and you recompile more files. Yay? > > Anyway, the general gist of the solution is clear: we > must be able to specify that we don't want to import a > module for Template Haskell (there is subtleties in this > too as you will want a little more control than that for > cross-compilation reasons which I'm not competent about > to comment on). But the devil is in the many details. > There's this thing called implicit cross-stage > persistence which says that anything you import > not-for-template-haskell is going to be available in > quotes and splices anyway. Sigh… So you have to turn > this off. This is what the proposal does. And pretty > much only. > > 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. > > For these situations, the proposal kind of advertises > using `-XImplicitStagePersistence`. Which does seem like > a fork-like situation to me. Not cool. Yet… yet Template > Haskell is a big messy ball of yarn, and I don't think > it's fair to ask of any proposal to entangle it > completely. The failure of past attempts seem to support > this case. And I believe the authors are correct when > they claim that this proposal, in practice, covers a > vast majority of the uses of Template Haskell out there. > So maybe we can see that as a new foundation for > Template Haskell. I'm not thrilled about it, but it's > probably the most reasonable way forward. > > The real problem with this sort of proposal is that then > I get to write way too long an email to the committee. > Hopefully this didn't deter you. Read the proposal, and > let's vote. > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com > <https://moduscreate.com> and https://tweag.io > <https://tweag.io>.
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- -- Matthías Páll Gissurarson <http://mpg.is/>
I agrre with this. On 2025-02-06 17:57, Matthías Páll Gissurarson wrote:
Sorry for the late reply!
After reading the thread, I'm slightly in favor of having 2 extensions.
While I agree that we already have too many extensions, the case for having two extensions is convincing. As Arnaud mentioned, extensions are often used in a long list in the .cabal file, and being able to have ExplicitLevelImports enabled during refactoring seems to be a win. We want to keep migration costs minimal.
The subtle case of the list of extensions being order-dependent (as Richard mentioned) is a bit troubling, but I agree that that should be left to another proposal.
On Thu, 6 Feb 2025 at 08:26, Arnaud Spiwack <[1]arnaud.spiwack@tweag.io> wrote:
Simon M: I'm pretty we would enable either both or neither in editions, yes.
---
Erik: See the argument summarized by Simon PJ here [2]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment -2609199731 , and the handful of comment below, these are the arguments which have been laid down so far for either side of this conversation. My summary of the summary is that there are two envisioned use-case for turning on ExplicitLevelImports while leaving ImplicitStagePersistence on:
- Migration (this help compile a project, but progressively follow warnings to prepare a project for NoImplicitStagePersistence) - Exceptional ImplicitStagePersistence: in the current state of the library, it seems that you will sometimes need to use ImplicitStagePersistence (to define Lift function, perhaps, or in a module where you define a bunch of Template Haskell: not every problem has been solved). But because you are in a project which uses ExplicitLevelImport everywhere, you may want to still mark your imports consistently with the rest of the project, as being imports for slices, quotes, or neither.
On Thu, 6 Feb 2025 at 00:37, Simon Marlow <[3]marlowsd@gmail.com> wrote:
I don't feel strongly about 1 vs 2 extensions, because I think the direction of travel is away from recommending individual extensions as a way to interact with the compiler and towards GHC20xx instead. And in GHC20xx I think we would enable either both or neither of these extensions, correct?
Cheers Simon
On Wed, 5 Feb 2025 at 08:16, Erik de Castro Lopo <[4]erikd@mega-nerd.com> wrote:
Hi,
I have read through the proposal, but there is something I am still unsure of. For the LANGUAGE pragma's is there any utility in using one separately form the other? It seems there isn't. In any one file you would use either one or the other.
Thanks, Erik
Arnaud Spiwack wrote:
> Sorry I disappeared for a while. I second Simon's call, let's vote. Let me > repost a link to Simon's pro and cons post > [5]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731 > > So far, we have the following votes > > - Simon: 1 extension > - Adam: 2 extension (feels quite strongly about it) > - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote > anyway) > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > --- > > Beyond that we have a single piece of community feedback on the Github > thread. It's from Michael Peyton Jones who is in favour of 2 extensions, > find it here > [6]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609583126 > > --- > > For the record, I hadn't commented about it in my recommendation, despite > my well-known and desperately public distaste for micro extensions. I have > a couple of reasons: > - I dislike micro-extensions less now that we are doing the GHC20XX (the > last one was very modest, I'm in favour, by the way, of doing a much more > ambitious language edition soon, otherwise my distaste will come back with > a vengeance) > - While I consider every proposal with several extensions in it with > suspicion, the authors did argue for their second extension, I found the > argument mildly convincing, and thought it wasn't worth fighting against. > > Now, even like this my preference is mildly for one extension. Adam says > that it's easier to implement warnings with both the new syntax on and > implicit stage persistence left turned on, than to implement errors when > implicit stage persistence is turned off. It may be so, but I don't think > we can avoid implementing the errors anyway, so I don't feel that it's a > particularly compelling argument. I don't feel strongly. But that's > presumably where my vote goes. > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones <[7]simon.peytonjones@gmail.com> > wrote: > > > Yes: all members of the steering committee, please vote. Evaluating > > proposals is what we all signed up to do! > > > > Thanks > > > > Simon > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry <[8]adam@well-typed.com> wrote: > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two > >> extensions. As I commented on the GitHub thread: > >> > >> > We shouldn't unnecessarily conflate a syntactic extension > >> (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) > >> just because the common case is to want both and we want to keep the > >> number of extensions lower. > >> > >> If there are reasons why having two extensions is actually problematic, > >> I'd like to hear them. > >> > >> Also, at the risk of opening another avenue of discussion, we also need > >> to resolve the syntax question (see > >> > >> [9]https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio n_r1849123243). > >> > >> I don't have a very strong opinion here, but given that some people do, > >> perhaps we should make ImportQualifiedPost affect splice imports so we > >> have > >> > >> import splice qualified A -- By default > >> import A splice qualified -- Under ImportQualifiedPost > >> > >> In any case, please do vote! It would be good to get this proposal done. > >> > >> Cheers, > >> > >> Adam > >> > >> > >> > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > >> > Arnaud > >> > > >> > OK, following my call and some further iteration, the proposal is much > >> > improved. See here > >> > <[10]https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please > >> read > >> > the new "Proposed Change Specification" which has had a large rewrite. > >> > > >> > I vote to accept. > >> > > >> > BUT there is one point that the committee must resolve: *one extension > >> > of two?* It's just a judgement call and I lay out the choices in this > >> > post > >> > < > >> [11]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom ment-2609199731>. > >> I doubt that we'll get much community feedback. I suggest that we just > >> vote. I vote for one, not two. As does Sebastian. > >> > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > >> > implementing it for a customer and it has been on our to-do list for > >> > some time now. (Partly my fault.) > >> > > >> > Simon > >> > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > >> > <[12]simon.peytonjones@gmail.com <mailto:[13]simon.peytonjones@gmail.com>> > >> wrote: > >> > > >> > Matthew and I had a good conversation. Some notes here > >> > < > >> [14]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R Phk5MslruY7yXD0/edit?usp=sharing > >> >. > >> > > >> > He's going to work on a revision to the proposal which I'll iterate > >> > with him. > >> > > >> > Simon > >> > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > >> > <[15]arnaud.spiwack@tweag.io <mailto:[16]arnaud.spiwack@tweag.io>> wrote: > >> > > >> > Then, let's wait until your call with Matthew and decide how to > >> > act then. > >> > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > >> > <[17]simon.peytonjones@gmail.com > >> > <mailto:[18]simon.peytonjones@gmail.com>> wrote: > >> > > >> > Arnaud > >> > > >> > I have responded with a lot of feedback on the Github thread > >> > < > >> [19]https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ estreview-2562175116 > >> >. > >> > > >> > TL:DR: I like the direction of travel but have too many > >> > questions of detail to be ready to accept it just yet. > >> > > >> > I have arranged a call with Matthew. > >> > > >> > Simon > >> > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > >> > <[20]arnaud.spiwack@tweag.io <mailto:[21]arnaud.spiwack@tweag.io>> > >> > wrote: > >> > > >> > > >> > Mathew Pickering, Rodrigo Mesquita, and our own Adam > >> > Gundry put forward a new proposal for the perenial > >> > problem of dependencies and Template Haskell > >> > [22]https://github.com/ghc-proposals/ghc-proposals/pull/682 > >> > < > >> [23]https://github.com/ghc-proposals/ghc-proposals/pull/682> > >> > > >> > I've got to be honest, I'm not fully convinced by the > >> > proposal. More on that in a minute, but it learns a > >> > lesson from previous attempts at the same problem by > >> > solving the absolute minimal problem, but this leads to > >> > a somewhat fork-like situation for which it isn't clear > >> > whether it will be resolved in the future. That being > >> > said, it solves a real problem which has plagued GHC > >> > compilation forever. And I'm inclined to believe that we > >> > can't really do much better. > >> > > >> > But I'm getting ahead of myself. The problem is that > >> > when you have -XTemplateHaskell in a file, all the > >> > dependencies' compiled code must suddenly be available > >> > for typechecking. This breaks `-fno-code` and wounds > >> > recompilation avoidance. This is probably the main > >> > reason why it's a widely held belief that Template > >> > Haskell is slow: you use Template Haskell in a few > >> > modules, and suddenly your IDE is much less responsive > >> > and you recompile more files. Yay? > >> > > >> > Anyway, the general gist of the solution is clear: we > >> > must be able to specify that we don't want to import a > >> > module for Template Haskell (there is subtleties in this > >> > too as you will want a little more control than that for > >> > cross-compilation reasons which I'm not competent about > >> > to comment on). But the devil is in the many details. > >> > There's this thing called implicit cross-stage > >> > persistence which says that anything you import > >> > not-for-template-haskell is going to be available in > >> > quotes and splices anyway. Sigh… So you have to turn > >> > this off. This is what the proposal does. And pretty > >> > much only. > >> > > >> > 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. > >> > > >> > For these situations, the proposal kind of advertises > >> > using `-XImplicitStagePersistence`. Which does seem like > >> > a fork-like situation to me. Not cool. Yet… yet Template > >> > Haskell is a big messy ball of yarn, and I don't think > >> > it's fair to ask of any proposal to entangle it > >> > completely. The failure of past attempts seem to support > >> > this case. And I believe the authors are correct when > >> > they claim that this proposal, in practice, covers a > >> > vast majority of the uses of Template Haskell out there. > >> > So maybe we can see that as a new foundation for > >> > Template Haskell. I'm not thrilled about it, but it's > >> > probably the most reasonable way forward. > >> > > >> > The real problem with this sort of proposal is that then > >> > I get to write way too long an email to the committee. > >> > Hopefully this didn't deter you. Read the proposal, and > >> > let's vote. > >> > > >> > -- > >> > Arnaud Spiwack > >> > Director, Research at [24]https://moduscreate.com > >> > <[25]https://moduscreate.com> and [26]https://tweag.io > >> > <[27]https://tweag.io>. > >> > >> > >> -- > >> Adam Gundry, Haskell Consultant > >> Well-Typed LLP, [28]https://www.well-typed.com/ > >> > >> Registered in England & Wales, OC335890 > >> 27 Old Gloucester Street, London WC1N 3AX, England > >> > >> _______________________________________________ > >> ghc-steering-committee mailing list > >> [29]ghc-steering-committee@haskell.org > >> [30]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > >> > > _______________________________________________ > > ghc-steering-committee mailing list > > [31]ghc-steering-committee@haskell.org > > [32]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > > > > -- > Arnaud Spiwack > Director, Research at [33]https://moduscreate.com and [34]https://tweag.io.
-- -------------------------------------------------------------------- -- Erik de Castro Lopo [35]http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list [36]ghc-steering-committee@haskell.org [37]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
--
Arnaud Spiwack Director, Research at [38]https://moduscreate.com and [39]https://tweag.io.
_______________________________________________ ghc-steering-committee mailing list [40]ghc-steering-committee@haskell.org [41]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
--
-- [42]Matthías Páll Gissurarson
References
1. mailto:arnaud.spiwack@tweag.io 2. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 3. mailto:marlowsd@gmail.com 4. mailto:erikd@mega-nerd.com 5. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... 7. mailto:simon.peytonjones@gmail.com 8. mailto:adam@well-typed.com 9. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... 10. https://github.com/ghc-proposals/ghc-proposals/pull/682 11. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 12. mailto:simon.peytonjones@gmail.com 13. mailto:simon.peytonjones@gmail.com 14. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... 15. mailto:arnaud.spiwack@tweag.io 16. mailto:arnaud.spiwack@tweag.io 17. mailto:simon.peytonjones@gmail.com 18. mailto:simon.peytonjones@gmail.com 19. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... 20. mailto:arnaud.spiwack@tweag.io 21. mailto:arnaud.spiwack@tweag.io 22. https://github.com/ghc-proposals/ghc-proposals/pull/682 23. https://github.com/ghc-proposals/ghc-proposals/pull/682 24. https://moduscreate.com/ 25. https://moduscreate.com/ 26. https://tweag.io/ 27. https://tweag.io/ 28. https://www.well-typed.com/ 29. mailto:ghc-steering-committee@haskell.org 30. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 31. mailto:ghc-steering-committee@haskell.org 32. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 33. https://moduscreate.com/ 34. https://tweag.io/ 35. http://www.mega-nerd.com/ 36. mailto:ghc-steering-committee@haskell.org 37. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 38. https://moduscreate.com/ 39. https://tweag.io/ 40. mailto:ghc-steering-committee@haskell.org 41. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 42. http://mpg.is/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
OK, slightly in favor of two extensions. Erik Erik de Castro Lopo wrote:
Hi,
I have read through the proposal, but there is something I am still unsure of. For the LANGUAGE pragma's is there any utility in using one separately form the other? It seems there isn't. In any one file you would use either one or the other.
Thanks, Erik
Arnaud Spiwack wrote:
Sorry I disappeared for a while. I second Simon's call, let's vote. Let me repost a link to Simon's pro and cons post https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199...
So far, we have the following votes
- Simon: 1 extension - Adam: 2 extension (feels quite strongly about it) - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote anyway)
Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think?
---
Beyond that we have a single piece of community feedback on the Github thread. It's from Michael Peyton Jones who is in favour of 2 extensions, find it here https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583...
---
For the record, I hadn't commented about it in my recommendation, despite my well-known and desperately public distaste for micro extensions. I have a couple of reasons: - I dislike micro-extensions less now that we are doing the GHC20XX (the last one was very modest, I'm in favour, by the way, of doing a much more ambitious language edition soon, otherwise my distaste will come back with a vengeance) - While I consider every proposal with several extensions in it with suspicion, the authors did argue for their second extension, I found the argument mildly convincing, and thought it wasn't worth fighting against.
Now, even like this my preference is mildly for one extension. Adam says that it's easier to implement warnings with both the new syntax on and implicit stage persistence left turned on, than to implement errors when implicit stage persistence is turned off. It may be so, but I don't think we can avoid implementing the errors anyway, so I don't feel that it's a particularly compelling argument. I don't feel strongly. But that's presumably where my vote goes.
On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
Yes: all members of the steering committee, please vote. Evaluating proposals is what we all signed up to do!
Thanks
Simon
On Mon, 3 Feb 2025 at 20:45, Adam Gundry <adam@well-typed.com> wrote:
I'm (unsurprisingly) in favour of acceptance, and I vote for two extensions. As I commented on the GitHub thread:
We shouldn't unnecessarily conflate a syntactic extension (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) just because the common case is to want both and we want to keep the number of extensions lower.
If there are reasons why having two extensions is actually problematic, I'd like to hear them.
Also, at the risk of opening another avenue of discussion, we also need to resolve the syntax question (see
https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232...).
I don't have a very strong opinion here, but given that some people do, perhaps we should make ImportQualifiedPost affect splice imports so we have
import splice qualified A -- By default import A splice qualified -- Under ImportQualifiedPost
In any case, please do vote! It would be good to get this proposal done.
Cheers,
Adam
On 27/01/2025 11:52, Simon Peyton Jones wrote:
Arnaud
OK, following my call and some further iteration, the proposal is much improved. See here <https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please read the new "Proposed Change Specification" which has had a large rewrite.
I vote to accept.
BUT there is one point that the committee must resolve: *one extension of two?* It's just a judgement call and I lay out the choices in this post < https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731>. I doubt that we'll get much community feedback. I suggest that we just vote. I vote for one, not two. As does Sebastian.
Over to you Arnaud. Let's get this one done. Matthew is busy implementing it for a customer and it has been on our to-do list for some time now. (Partly my fault.)
Simon
On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Matthew and I had a good conversation. Some notes here < https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... .
He's going to work on a revision to the proposal which I'll iterate with him.
Simon
On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Then, let's wait until your call with Matthew and decide how to act then.
On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Arnaud
I have responded with a lot of feedback on the Github thread < https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... .
TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet.
I have arranged a call with Matthew.
Simon
On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682 < https://github.com/ghc-proposals/ghc-proposals/pull/682>
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org 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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Ok, we have enough of a quorum at this point. If everybody else voted 1 extension this would come at a rough draw. It can't be a strong enough push to overrule the preference of the authors. I'll give it a handful more day, say until next Wednesday 12th February. If someone has a strong objection, please voice it very loudly. Otherwise I'll declare the proposal as accepted in its current state. Best, Arnaud On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo <erikd@mega-nerd.com> wrote:
OK, slightly in favor of two extensions.
Erik
Erik de Castro Lopo wrote:
Hi,
I have read through the proposal, but there is something I am still unsure of. For the LANGUAGE pragma's is there any utility in using one separately form the other? It seems there isn't. In any one file you would use either one or the other.
Thanks, Erik
Arnaud Spiwack wrote:
Sorry I disappeared for a while. I second Simon's call, let's vote. Let me repost a link to Simon's pro and cons post
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199...
So far, we have the following votes
- Simon: 1 extension - Adam: 2 extension (feels quite strongly about it) - Sebastian: 1 extension (on the Github thread, but I'll count it as a
vote
anyway)
Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think?
---
Beyond that we have a single piece of community feedback on the Github thread. It's from Michael Peyton Jones who is in favour of 2 extensions, find it here
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583...
---
For the record, I hadn't commented about it in my recommendation,
despite
my well-known and desperately public distaste for micro extensions. I have a couple of reasons: - I dislike micro-extensions less now that we are doing the GHC20XX (the last one was very modest, I'm in favour, by the way, of doing a much more ambitious language edition soon, otherwise my distaste will come back with a vengeance) - While I consider every proposal with several extensions in it with suspicion, the authors did argue for their second extension, I found the argument mildly convincing, and thought it wasn't worth fighting against.
Now, even like this my preference is mildly for one extension. Adam says that it's easier to implement warnings with both the new syntax on and implicit stage persistence left turned on, than to implement errors when implicit stage persistence is turned off. It may be so, but I don't think we can avoid implementing the errors anyway, so I don't feel that it's a particularly compelling argument. I don't feel strongly. But that's presumably where my vote goes.
On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Yes: all members of the steering committee, please vote. Evaluating proposals is what we all signed up to do!
Thanks
Simon
On Mon, 3 Feb 2025 at 20:45, Adam Gundry <adam@well-typed.com> wrote:
I'm (unsurprisingly) in favour of acceptance, and I vote for two extensions. As I commented on the GitHub thread:
We shouldn't unnecessarily conflate a syntactic extension (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) just because the common case is to want both and we want to keep the number of extensions lower.
If there are reasons why having two extensions is actually problematic, I'd like to hear them.
Also, at the risk of opening another avenue of discussion, we also need to resolve the syntax question (see
https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... ).
I don't have a very strong opinion here, but given that some people
do,
perhaps we should make ImportQualifiedPost affect splice imports so we have
import splice qualified A -- By default import A splice qualified -- Under ImportQualifiedPost
In any case, please do vote! It would be good to get this proposal done.
Cheers,
Adam
On 27/01/2025 11:52, Simon Peyton Jones wrote:
Arnaud
OK, following my call and some further iteration, the proposal is much improved. See here <https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please read the new "Proposed Change Specification" which has had a large rewrite.
I vote to accept.
BUT there is one point that the committee must resolve: *one extension of two?* It's just a judgement call and I lay out the choices in this post <
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... .
I doubt that we'll get much community feedback. I suggest that we just vote. I vote for one, not two. As does Sebastian.
Over to you Arnaud. Let's get this one done. Matthew is busy implementing it for a customer and it has been on our to-do list
for
some time now. (Partly my fault.)
Simon
On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com
wrote:
Matthew and I had a good conversation. Some notes here <
https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y...
.
He's going to work on a revision to the proposal which I'll iterate with him.
Simon
On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
Then, let's wait until your call with Matthew and decide how to act then.
On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
Arnaud
I have responded with a lot of feedback on the Github thread <
https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25...
.
TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet.
I have arranged a call with Matthew.
Simon
On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto: arnaud.spiwack@tweag.io>> wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell
https://github.com/ghc-proposals/ghc-proposals/pull/682
<
https://github.com/ghc-proposals/ghc-proposals/pull/682>
I've got to be honest, I'm not fully convinced by
the
proposal. More on that in a minute, but it learns
a
lesson from previous attempts at the same problem
by
solving the absolute minimal problem, but this
leads to
a somewhat fork-like situation for which it isn't
clear
whether it will be resolved in the future. That
being
said, it solves a real problem which has plagued
GHC
compilation forever. And I'm inclined to believe
that we
can't really do much better.
But I'm getting ahead of myself. The problem is
that
when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be
available
for typechecking. This breaks `-fno-code` and
wounds
recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less
responsive
and you recompile more files. Yay?
Anyway, the general gist of the solution is
clear: we
must be able to specify that we don't want to
import a
module for Template Haskell (there is subtleties
in this
too as you will want a little more control than
that for
cross-compilation reasons which I'm not competent
about
to comment on). But the devil is in the many
details.
There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available
in
quotes and splices anyway. Sigh… So you have to
turn
this off. This is what the proposal does. And
pretty
much only.
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.
For these situations, the proposal kind of
advertises
using `-XImplicitStagePersistence`. Which does
seem like
a fork-like situation to me. Not cool. Yet… yet
Template
Haskell is a big messy ball of yarn, and I don't
think
it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to
support
this case. And I believe the authors are correct
when
they claim that this proposal, in practice,
covers a
vast majority of the uses of Template Haskell out
there.
So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but
it's
probably the most reasonable way forward.
The real problem with this sort of proposal is
that then
I get to write way too long an email to the
committee.
Hopefully this didn't deter you. Read the
proposal, and
let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
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
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
I do not object to accepting the proposal, but I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread. I know we all dread wasting our time with syntax discussions but lets at least think about it for 5 minutes. Best, Malte On 2025-02-07 15:48, Arnaud Spiwack wrote:
Ok, we have enough of a quorum at this point. If everybody else voted 1 extension this would come at a rough draw. It can't be a strong enough push to overrule the preference of the authors.
I'll give it a handful more day, say until next Wednesday 12th February. If someone has a strong objection, please voice it very loudly. Otherwise I'll declare the proposal as accepted in its current state.
Best, Arnaud
On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo <[1]erikd@mega-nerd.com> wrote:
OK, slightly in favor of two extensions.
Erik
Erik de Castro Lopo wrote:
> Hi, > > I have read through the proposal, but there is something I am still unsure > of. For the LANGUAGE pragma's is there any utility in using one separately > form the other? It seems there isn't. In any one file you would use either > one or the other. > > Thanks, > Erik > > Arnaud Spiwack wrote: > > > Sorry I disappeared for a while. I second Simon's call, let's vote. Let me > > repost a link to Simon's pro and cons post > > [2]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731 > > > > So far, we have the following votes > > > > - Simon: 1 extension > > - Adam: 2 extension (feels quite strongly about it) > > - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote > > anyway) > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > --- > > > > Beyond that we have a single piece of community feedback on the Github > > thread. It's from Michael Peyton Jones who is in favour of 2 extensions, > > find it here > > [3]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609583126 > > > > --- > > > > For the record, I hadn't commented about it in my recommendation, despite > > my well-known and desperately public distaste for micro extensions. I have > > a couple of reasons: > > - I dislike micro-extensions less now that we are doing the GHC20XX (the > > last one was very modest, I'm in favour, by the way, of doing a much more > > ambitious language edition soon, otherwise my distaste will come back with > > a vengeance) > > - While I consider every proposal with several extensions in it with > > suspicion, the authors did argue for their second extension, I found the > > argument mildly convincing, and thought it wasn't worth fighting against. > > > > Now, even like this my preference is mildly for one extension. Adam says > > that it's easier to implement warnings with both the new syntax on and > > implicit stage persistence left turned on, than to implement errors when > > implicit stage persistence is turned off. It may be so, but I don't think > > we can avoid implementing the errors anyway, so I don't feel that it's a > > particularly compelling argument. I don't feel strongly. But that's > > presumably where my vote goes. > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones <[4]simon.peytonjones@gmail.com> > > wrote: > > > > > Yes: all members of the steering committee, please vote. Evaluating > > > proposals is what we all signed up to do! > > > > > > Thanks > > > > > > Simon > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry <[5]adam@well-typed.com> wrote: > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two > > >> extensions. As I commented on the GitHub thread: > > >> > > >> > We shouldn't unnecessarily conflate a syntactic extension > > >> (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) > > >> just because the common case is to want both and we want to keep the > > >> number of extensions lower. > > >> > > >> If there are reasons why having two extensions is actually problematic, > > >> I'd like to hear them. > > >> > > >> Also, at the risk of opening another avenue of discussion, we also need > > >> to resolve the syntax question (see > > >> > > >> [6]https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio n_r1849123243). > > >> > > >> I don't have a very strong opinion here, but given that some people do, > > >> perhaps we should make ImportQualifiedPost affect splice imports so we > > >> have > > >> > > >> import splice qualified A -- By default > > >> import A splice qualified -- Under ImportQualifiedPost > > >> > > >> In any case, please do vote! It would be good to get this proposal done. > > >> > > >> Cheers, > > >> > > >> Adam > > >> > > >> > > >> > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > >> > Arnaud > > >> > > > >> > OK, following my call and some further iteration, the proposal is much > > >> > improved. See here > > >> > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please > > >> read > > >> > the new "Proposed Change Specification" which has had a large rewrite. > > >> > > > >> > I vote to accept. > > >> > > > >> > BUT there is one point that the committee must resolve: *one extension > > >> > of two?* It's just a judgement call and I lay out the choices in this > > >> > post > > >> > < > > >> [8]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731>. > > >> I doubt that we'll get much community feedback. I suggest that we just > > >> vote. I vote for one, not two. As does Sebastian. > > >> > > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > > >> > implementing it for a customer and it has been on our to-do list for > > >> > some time now. (Partly my fault.) > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > >> > <[9]simon.peytonjones@gmail.com <mailto:[10]simon.peytonjones@gmail.com>> > > >> wrote: > > >> > > > >> > Matthew and I had a good conversation. Some notes here > > >> > < > > >> [11]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R Phk5MslruY7yXD0/edit?usp=sharing > > >> >. > > >> > > > >> > He's going to work on a revision to the proposal which I'll iterate > > >> > with him. > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > >> > <[12]arnaud.spiwack@tweag.io <mailto:[13]arnaud.spiwack@tweag.io>> wrote: > > >> > > > >> > Then, let's wait until your call with Matthew and decide how to > > >> > act then. > > >> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > >> > <[14]simon.peytonjones@gmail.com > > >> > <mailto:[15]simon.peytonjones@gmail.com>> wrote: > > >> > > > >> > Arnaud > > >> > > > >> > I have responded with a lot of feedback on the Github thread > > >> > < > > >> [16]https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ estreview-2562175116 > > >> >. > > >> > > > >> > TL:DR: I like the direction of travel but have too many > > >> > questions of detail to be ready to accept it just yet. > > >> > > > >> > I have arranged a call with Matthew. > > >> > > > >> > Simon > > >> > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > > >> > <[17]arnaud.spiwack@tweag.io <mailto:[18]arnaud.spiwack@tweag.io>> > > >> > wrote: > > >> > > > >> > > > >> > Mathew Pickering, Rodrigo Mesquita, and our own Adam > > >> > Gundry put forward a new proposal for the perenial > > >> > problem of dependencies and Template Haskell > > >> > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > >> > < > > >> [20]https://github.com/ghc-proposals/ghc-proposals/pull/682> > > >> > > > >> > I've got to be honest, I'm not fully convinced by the > > >> > proposal. More on that in a minute, but it learns a > > >> > lesson from previous attempts at the same problem by > > >> > solving the absolute minimal problem, but this leads to > > >> > a somewhat fork-like situation for which it isn't clear > > >> > whether it will be resolved in the future. That being > > >> > said, it solves a real problem which has plagued GHC > > >> > compilation forever. And I'm inclined to believe that we > > >> > can't really do much better. > > >> > > > >> > But I'm getting ahead of myself. The problem is that > > >> > when you have -XTemplateHaskell in a file, all the > > >> > dependencies' compiled code must suddenly be available > > >> > for typechecking. This breaks `-fno-code` and wounds > > >> > recompilation avoidance. This is probably the main > > >> > reason why it's a widely held belief that Template > > >> > Haskell is slow: you use Template Haskell in a few > > >> > modules, and suddenly your IDE is much less responsive > > >> > and you recompile more files. Yay? > > >> > > > >> > Anyway, the general gist of the solution is clear: we > > >> > must be able to specify that we don't want to import a > > >> > module for Template Haskell (there is subtleties in this > > >> > too as you will want a little more control than that for > > >> > cross-compilation reasons which I'm not competent about > > >> > to comment on). But the devil is in the many details. > > >> > There's this thing called implicit cross-stage > > >> > persistence which says that anything you import > > >> > not-for-template-haskell is going to be available in > > >> > quotes and splices anyway. Sigh… So you have to turn > > >> > this off. This is what the proposal does. And pretty > > >> > much only. > > >> > > > >> > 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. > > >> > > > >> > For these situations, the proposal kind of advertises > > >> > using `-XImplicitStagePersistence`. Which does seem like > > >> > a fork-like situation to me. Not cool. Yet… yet Template > > >> > Haskell is a big messy ball of yarn, and I don't think > > >> > it's fair to ask of any proposal to entangle it > > >> > completely. The failure of past attempts seem to support > > >> > this case. And I believe the authors are correct when > > >> > they claim that this proposal, in practice, covers a > > >> > vast majority of the uses of Template Haskell out there. > > >> > So maybe we can see that as a new foundation for > > >> > Template Haskell. I'm not thrilled about it, but it's > > >> > probably the most reasonable way forward. > > >> > > > >> > The real problem with this sort of proposal is that then > > >> > I get to write way too long an email to the committee. > > >> > Hopefully this didn't deter you. Read the proposal, and > > >> > let's vote. > > >> > > > >> > -- > > >> > Arnaud Spiwack > > >> > Director, Research at [21]https://moduscreate.com > > >> > <[22]https://moduscreate.com> and [23]https://tweag.io > > >> > <[24]https://tweag.io>. > > >> > > >> > > >> -- > > >> Adam Gundry, Haskell Consultant > > >> Well-Typed LLP, [25]https://www.well-typed.com/ > > >> > > >> Registered in England & Wales, OC335890 > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > >> > > >> _______________________________________________ > > >> ghc-steering-committee mailing list > > >> [26]ghc-steering-committee@haskell.org > > >> [27]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > >> > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > [28]ghc-steering-committee@haskell.org > > > [29]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > > > > > > > > -- > > Arnaud Spiwack > > Director, Research at [30]https://moduscreate.com and [31]https://tweag.io. > > > -- > -------------------------------------------------------------------- -- > Erik de Castro Lopo > [32]http://www.mega-nerd.com/ >
-- -------------------------------------------------------------------- -- Erik de Castro Lopo [33]http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list [34]ghc-steering-committee@haskell.org [35]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
--
Arnaud Spiwack Director, Research at [36]https://moduscreate.com and [37]https://tweag.io.
References
1. mailto:erikd@mega-nerd.com 2. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... 4. mailto:simon.peytonjones@gmail.com 5. mailto:adam@well-typed.com 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 8. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 9. mailto:simon.peytonjones@gmail.com 10. mailto:simon.peytonjones@gmail.com 11. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... 12. mailto:arnaud.spiwack@tweag.io 13. mailto:arnaud.spiwack@tweag.io 14. mailto:simon.peytonjones@gmail.com 15. mailto:simon.peytonjones@gmail.com 16. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... 17. mailto:arnaud.spiwack@tweag.io 18. mailto:arnaud.spiwack@tweag.io 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 21. https://moduscreate.com/ 22. https://moduscreate.com/ 23. https://tweag.io/ 24. https://tweag.io/ 25. https://www.well-typed.com/ 26. mailto:ghc-steering-committee@haskell.org 27. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 28. mailto:ghc-steering-committee@haskell.org 29. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 30. https://moduscreate.com/ 31. https://tweag.io/ 32. http://www.mega-nerd.com/ 33. http://www.mega-nerd.com/ 34. mailto:ghc-steering-committee@haskell.org 35. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 36. https://moduscreate.com/ 37. https://tweag.io/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread. OK -- but I suspect that most of us have lost context. Would you like to post (on the Github) a message explaining: - what the syntactic alternatives are - what you recommend That will help to focus the discussion Thanks! Simon On Fri, 7 Feb 2025 at 12:16, Malte Ott <malte.ott@maralorn.de> wrote:
I do not object to accepting the proposal, but I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
I know we all dread wasting our time with syntax discussions but lets at least think about it for 5 minutes.
Best, Malte
On 2025-02-07 15:48, Arnaud Spiwack wrote:
Ok, we have enough of a quorum at this point. If everybody else voted 1 extension this would come at a rough draw. It can't be a strong enough push to overrule the preference of the authors.
I'll give it a handful more day, say until next Wednesday 12th February. If someone has a strong objection, please voice it very loudly. Otherwise I'll declare the proposal as accepted in its current state.
Best, Arnaud
On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo <[1]erikd@mega-nerd.com> wrote:
OK, slightly in favor of two extensions.
Erik
Erik de Castro Lopo wrote:
> Hi, > > I have read through the proposal, but there is something I am still unsure > of. For the LANGUAGE pragma's is there any utility in using one separately > form the other? It seems there isn't. In any one file you would use either > one or the other. > > Thanks, > Erik > > Arnaud Spiwack wrote: > > > Sorry I disappeared for a while. I second Simon's call, let's vote. Let me > > repost a link to Simon's pro and cons post > > [2] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731 > > > > So far, we have the following votes > > > > - Simon: 1 extension > > - Adam: 2 extension (feels quite strongly about it) > > - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote > > anyway) > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > --- > > > > Beyond that we have a single piece of community feedback on the Github > > thread. It's from Michael Peyton Jones who is in favour of 2 extensions, > > find it here > > [3] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609583126 > > > > --- > > > > For the record, I hadn't commented about it in my recommendation, despite > > my well-known and desperately public distaste for micro extensions. I have > > a couple of reasons: > > - I dislike micro-extensions less now that we are doing the GHC20XX (the > > last one was very modest, I'm in favour, by the way, of doing a much more > > ambitious language edition soon, otherwise my distaste will come back with > > a vengeance) > > - While I consider every proposal with several extensions in it with > > suspicion, the authors did argue for their second extension, I found the > > argument mildly convincing, and thought it wasn't worth fighting against. > > > > Now, even like this my preference is mildly for one extension. Adam says > > that it's easier to implement warnings with both the new syntax on and > > implicit stage persistence left turned on, than to implement errors when > > implicit stage persistence is turned off. It may be so, but I don't think > > we can avoid implementing the errors anyway, so I don't feel that it's a > > particularly compelling argument. I don't feel strongly. But that's > > presumably where my vote goes. > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones <[4]simon.peytonjones@gmail.com> > > wrote: > > > > > Yes: all members of the steering committee, please vote. Evaluating > > > proposals is what we all signed up to do! > > > > > > Thanks > > > > > > Simon > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry <[5]adam@well-typed.com> wrote: > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two > > >> extensions. As I commented on the GitHub thread: > > >> > > >> > We shouldn't unnecessarily conflate a syntactic extension > > >> (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) > > >> just because the common case is to want both and we want to keep the > > >> number of extensions lower. > > >> > > >> If there are reasons why having two extensions is actually problematic, > > >> I'd like to hear them. > > >> > > >> Also, at the risk of opening another avenue of discussion, we also need > > >> to resolve the syntax question (see > > >> > > >> [6] https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio n_r1849123243). > > >> > > >> I don't have a very strong opinion here, but given that some people do, > > >> perhaps we should make ImportQualifiedPost affect splice imports so we > > >> have > > >> > > >> import splice qualified A -- By default > > >> import A splice qualified -- Under ImportQualifiedPost > > >> > > >> In any case, please do vote! It would be good to get this proposal done. > > >> > > >> Cheers, > > >> > > >> Adam > > >> > > >> > > >> > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > >> > Arnaud > > >> > > > >> > OK, following my call and some further iteration, the proposal is much > > >> > improved. See here > > >> > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please > > >> read > > >> > the new "Proposed Change Specification" which has had a large rewrite. > > >> > > > >> > I vote to accept. > > >> > > > >> > BUT there is one point that the committee must resolve: *one extension > > >> > of two?* It's just a judgement call and I lay out the choices in this > > >> > post > > >> > < > > >> [8] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731>. > > >> I doubt that we'll get much community feedback. I suggest that we just > > >> vote. I vote for one, not two. As does Sebastian. > > >> > > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > > >> > implementing it for a customer and it has been on our to-do list for > > >> > some time now. (Partly my fault.) > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > >> > <[9]simon.peytonjones@gmail.com <mailto:[10]simon.peytonjones@gmail.com>> > > >> wrote: > > >> > > > >> > Matthew and I had a good conversation. Some notes here > > >> > < > > >> [11] https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R Phk5MslruY7yXD0/edit?usp=sharing > > >> >. > > >> > > > >> > He's going to work on a revision to the proposal which I'll iterate > > >> > with him. > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > >> > <[12]arnaud.spiwack@tweag.io <mailto:[13]arnaud.spiwack@tweag.io>> wrote: > > >> > > > >> > Then, let's wait until your call with Matthew and decide how to > > >> > act then. > > >> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > >> > <[14]simon.peytonjones@gmail.com > > >> > <mailto:[15]simon.peytonjones@gmail.com>> wrote: > > >> > > > >> > Arnaud > > >> > > > >> > I have responded with a lot of feedback on the Github thread > > >> > < > > >> [16] https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ estreview-2562175116 > > >> >. > > >> > > > >> > TL:DR: I like the direction of travel but have too many > > >> > questions of detail to be ready to accept it just yet. > > >> > > > >> > I have arranged a call with Matthew. > > >> > > > >> > Simon > > >> > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > > >> > <[17]arnaud.spiwack@tweag.io <mailto:[18]arnaud.spiwack@tweag.io>> > > >> > wrote: > > >> > > > >> > > > >> > Mathew Pickering, Rodrigo Mesquita, and our own Adam > > >> > Gundry put forward a new proposal for the perenial > > >> > problem of dependencies and Template Haskell > > >> > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > >> > < > > >> [20]https://github.com/ghc-proposals/ghc-proposals/pull/682> > > >> > > > >> > I've got to be honest, I'm not fully convinced by the > > >> > proposal. More on that in a minute, but it learns a > > >> > lesson from previous attempts at the same problem by > > >> > solving the absolute minimal problem, but this leads to > > >> > a somewhat fork-like situation for which it isn't clear > > >> > whether it will be resolved in the future. That being > > >> > said, it solves a real problem which has plagued GHC > > >> > compilation forever. And I'm inclined to believe that we > > >> > can't really do much better. > > >> > > > >> > But I'm getting ahead of myself. The problem is that > > >> > when you have -XTemplateHaskell in a file, all the > > >> > dependencies' compiled code must suddenly be available > > >> > for typechecking. This breaks `-fno-code` and wounds > > >> > recompilation avoidance. This is probably the main > > >> > reason why it's a widely held belief that Template > > >> > Haskell is slow: you use Template Haskell in a few > > >> > modules, and suddenly your IDE is much less responsive > > >> > and you recompile more files. Yay? > > >> > > > >> > Anyway, the general gist of the solution is clear: we > > >> > must be able to specify that we don't want to import a > > >> > module for Template Haskell (there is subtleties in this > > >> > too as you will want a little more control than that for > > >> > cross-compilation reasons which I'm not competent about > > >> > to comment on). But the devil is in the many details. > > >> > There's this thing called implicit cross-stage > > >> > persistence which says that anything you import > > >> > not-for-template-haskell is going to be available in > > >> > quotes and splices anyway. Sigh… So you have to turn > > >> > this off. This is what the proposal does. And pretty > > >> > much only. > > >> > > > >> > 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. > > >> > > > >> > For these situations, the proposal kind of advertises > > >> > using `-XImplicitStagePersistence`. Which does seem like > > >> > a fork-like situation to me. Not cool. Yet… yet Template > > >> > Haskell is a big messy ball of yarn, and I don't think > > >> > it's fair to ask of any proposal to entangle it > > >> > completely. The failure of past attempts seem to support > > >> > this case. And I believe the authors are correct when > > >> > they claim that this proposal, in practice, covers a > > >> > vast majority of the uses of Template Haskell out there. > > >> > So maybe we can see that as a new foundation for > > >> > Template Haskell. I'm not thrilled about it, but it's > > >> > probably the most reasonable way forward. > > >> > > > >> > The real problem with this sort of proposal is that then > > >> > I get to write way too long an email to the committee. > > >> > Hopefully this didn't deter you. Read the proposal, and > > >> > let's vote. > > >> > > > >> > -- > > >> > Arnaud Spiwack > > >> > Director, Research at [21]https://moduscreate.com > > >> > <[22]https://moduscreate.com> and [23]https://tweag.io > > >> > <[24]https://tweag.io>. > > >> > > >> > > >> -- > > >> Adam Gundry, Haskell Consultant > > >> Well-Typed LLP, [25]https://www.well-typed.com/ > > >> > > >> Registered in England & Wales, OC335890 > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > >> > > >> _______________________________________________ > > >> ghc-steering-committee mailing list > > >> [26]ghc-steering-committee@haskell.org > > >> [27] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > >> > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > [28]ghc-steering-committee@haskell.org > > > [29] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > > > > > > > > -- > > Arnaud Spiwack > > Director, Research at [30]https://moduscreate.com and [31]https://tweag.io. > > > -- > -------------------------------------------------------------------- -- > Erik de Castro Lopo > [32]http://www.mega-nerd.com/ >
-- -------------------------------------------------------------------- -- Erik de Castro Lopo [33]http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list [34]ghc-steering-committee@haskell.org [35] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
--
Arnaud Spiwack Director, Research at [36]https://moduscreate.com and [37]https://tweag.io.
References
1. mailto:erikd@mega-nerd.com 2. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... 4. mailto:simon.peytonjones@gmail.com 5. mailto:adam@well-typed.com 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 8. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 9. mailto:simon.peytonjones@gmail.com 10. mailto:simon.peytonjones@gmail.com 11. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... 12. mailto:arnaud.spiwack@tweag.io 13. mailto:arnaud.spiwack@tweag.io 14. mailto:simon.peytonjones@gmail.com 15. mailto:simon.peytonjones@gmail.com 16. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... 17. mailto:arnaud.spiwack@tweag.io 18. mailto:arnaud.spiwack@tweag.io 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 21. https://moduscreate.com/ 22. https://moduscreate.com/ 23. https://tweag.io/ 24. https://tweag.io/ 25. https://www.well-typed.com/ 26. mailto:ghc-steering-committee@haskell.org 27. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 28. mailto:ghc-steering-committee@haskell.org 29. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 30. https://moduscreate.com/ 31. https://tweag.io/ 32. http://www.mega-nerd.com/ 33. http://www.mega-nerd.com/ 34. mailto:ghc-steering-committee@haskell.org 35. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 36. https://moduscreate.com/ 37. https://tweag.io/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org 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
For the record, the syntactic alternatives can be found in [§8.5 Syntactic alternatives]( https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/prop... ) Malte seems to be uncomfortable with the fact that the proposed syntax is import slice Foo import quote Bar Even when ImportQualifiedPost, which enables the syntax import Foo qualified [as …] is enabled. The proposal offers alternative syntaxes like import Foo slice Import Bar quote or (to sound more English) import Foo for slice import Bar for quote Richard Eisenberg, in the thread, suggests that the motivation for ImportQualifiedPost doesn't apply to slice/quote because he believes that there's going to be one block of import slice, one block of import (nothing), one block of import quote, and they aren't going to be mixed together. Them being more visually distinguished by starting with the keyword is an asset in this view. Many seem convinced My understanding of Malte's point is that this is not intuitive enough that it can be left implicit in the proposal, and he'd like the proposal to at least state explicitly that it ignores ImportQualifiedPost. Malte, let me know if I misrepresent your point of view (or anybody else's). On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
OK -- but I suspect that most of us have lost context.
Would you like to post (on the Github) a message explaining:
- what the syntactic alternatives are - what you recommend
That will help to focus the discussion
Thanks!
Simon
On Fri, 7 Feb 2025 at 12:16, Malte Ott <malte.ott@maralorn.de> wrote:
I do not object to accepting the proposal, but I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
I know we all dread wasting our time with syntax discussions but lets at least think about it for 5 minutes.
Best, Malte
On 2025-02-07 15:48, Arnaud Spiwack wrote:
Ok, we have enough of a quorum at this point. If everybody else voted 1 extension this would come at a rough draw. It can't be a strong enough push to overrule the preference of the authors.
I'll give it a handful more day, say until next Wednesday 12th February. If someone has a strong objection, please voice it very loudly. Otherwise I'll declare the proposal as accepted in its current state.
Best, Arnaud
On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo <[1]erikd@mega-nerd.com> wrote:
OK, slightly in favor of two extensions.
Erik
Erik de Castro Lopo wrote:
> Hi, > > I have read through the proposal, but there is something I am still unsure > of. For the LANGUAGE pragma's is there any utility in using one separately > form the other? It seems there isn't. In any one file you would use either > one or the other. > > Thanks, > Erik > > Arnaud Spiwack wrote: > > > Sorry I disappeared for a while. I second Simon's call, let's vote. Let me > > repost a link to Simon's pro and cons post > > [2] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731 > > > > So far, we have the following votes > > > > - Simon: 1 extension > > - Adam: 2 extension (feels quite strongly about it) > > - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote > > anyway) > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > --- > > > > Beyond that we have a single piece of community feedback on the Github > > thread. It's from Michael Peyton Jones who is in favour of 2 extensions, > > find it here > > [3] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609583126 > > > > --- > > > > For the record, I hadn't commented about it in my recommendation, despite > > my well-known and desperately public distaste for micro extensions. I have > > a couple of reasons: > > - I dislike micro-extensions less now that we are doing the GHC20XX (the > > last one was very modest, I'm in favour, by the way, of doing a much more > > ambitious language edition soon, otherwise my distaste will come back with > > a vengeance) > > - While I consider every proposal with several extensions in it with > > suspicion, the authors did argue for their second extension, I found the > > argument mildly convincing, and thought it wasn't worth fighting against. > > > > Now, even like this my preference is mildly for one extension. Adam says > > that it's easier to implement warnings with both the new syntax on and > > implicit stage persistence left turned on, than to implement errors when > > implicit stage persistence is turned off. It may be so, but I don't think > > we can avoid implementing the errors anyway, so I don't feel that it's a > > particularly compelling argument. I don't feel strongly. But that's > > presumably where my vote goes. > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones <[4]simon.peytonjones@gmail.com> > > wrote: > > > > > Yes: all members of the steering committee, please vote. Evaluating > > > proposals is what we all signed up to do! > > > > > > Thanks > > > > > > Simon > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry <[5]adam@well-typed.com> wrote: > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two > > >> extensions. As I commented on the GitHub thread: > > >> > > >> > We shouldn't unnecessarily conflate a syntactic extension > > >> (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) > > >> just because the common case is to want both and we want to keep the > > >> number of extensions lower. > > >> > > >> If there are reasons why having two extensions is actually problematic, > > >> I'd like to hear them. > > >> > > >> Also, at the risk of opening another avenue of discussion, we also need > > >> to resolve the syntax question (see > > >> > > >> [6] https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio n_r1849123243). > > >> > > >> I don't have a very strong opinion here, but given that some people do, > > >> perhaps we should make ImportQualifiedPost affect splice imports so we > > >> have > > >> > > >> import splice qualified A -- By default > > >> import A splice qualified -- Under ImportQualifiedPost > > >> > > >> In any case, please do vote! It would be good to get this proposal done. > > >> > > >> Cheers, > > >> > > >> Adam > > >> > > >> > > >> > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > >> > Arnaud > > >> > > > >> > OK, following my call and some further iteration, the proposal is much > > >> > improved. See here > > >> > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please > > >> read > > >> > the new "Proposed Change Specification" which has had a large rewrite. > > >> > > > >> > I vote to accept. > > >> > > > >> > BUT there is one point that the committee must resolve: *one extension > > >> > of two?* It's just a judgement call and I lay out the choices in this > > >> > post > > >> > < > > >> [8] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731>. > > >> I doubt that we'll get much community feedback. I suggest that we just > > >> vote. I vote for one, not two. As does Sebastian. > > >> > > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > > >> > implementing it for a customer and it has been on our to-do list for > > >> > some time now. (Partly my fault.) > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > >> > <[9]simon.peytonjones@gmail.com <mailto:[10]simon.peytonjones@gmail.com>> > > >> wrote: > > >> > > > >> > Matthew and I had a good conversation. Some notes here > > >> > < > > >> [11] https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R Phk5MslruY7yXD0/edit?usp=sharing > > >> >. > > >> > > > >> > He's going to work on a revision to the proposal which I'll iterate > > >> > with him. > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > >> > <[12]arnaud.spiwack@tweag.io <mailto:[13]arnaud.spiwack@tweag.io>> wrote: > > >> > > > >> > Then, let's wait until your call with Matthew and decide how to > > >> > act then. > > >> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > >> > <[14]simon.peytonjones@gmail.com > > >> > <mailto:[15]simon.peytonjones@gmail.com>> wrote: > > >> > > > >> > Arnaud > > >> > > > >> > I have responded with a lot of feedback on the Github thread > > >> > < > > >> [16] https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ estreview-2562175116 > > >> >. > > >> > > > >> > TL:DR: I like the direction of travel but have too many > > >> > questions of detail to be ready to accept it just yet. > > >> > > > >> > I have arranged a call with Matthew. > > >> > > > >> > Simon > > >> > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > > >> > <[17]arnaud.spiwack@tweag.io <mailto:[18]arnaud.spiwack@tweag.io>> > > >> > wrote: > > >> > > > >> > > > >> > Mathew Pickering, Rodrigo Mesquita, and our own Adam > > >> > Gundry put forward a new proposal for the perenial > > >> > problem of dependencies and Template Haskell > > >> > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > >> > < > > >> [20]https://github.com/ghc-proposals/ghc-proposals/pull/682
> > >> > > > >> > I've got to be honest, I'm not fully convinced by the > > >> > proposal. More on that in a minute, but it learns a > > >> > lesson from previous attempts at the same problem by > > >> > solving the absolute minimal problem, but this leads to > > >> > a somewhat fork-like situation for which it isn't clear > > >> > whether it will be resolved in the future. That being > > >> > said, it solves a real problem which has plagued GHC > > >> > compilation forever. And I'm inclined to believe that we > > >> > can't really do much better. > > >> > > > >> > But I'm getting ahead of myself. The problem is that > > >> > when you have -XTemplateHaskell in a file, all the > > >> > dependencies' compiled code must suddenly be available > > >> > for typechecking. This breaks `-fno-code` and wounds > > >> > recompilation avoidance. This is probably the main > > >> > reason why it's a widely held belief that Template > > >> > Haskell is slow: you use Template Haskell in a few > > >> > modules, and suddenly your IDE is much less responsive > > >> > and you recompile more files. Yay? > > >> > > > >> > Anyway, the general gist of the solution is clear: we > > >> > must be able to specify that we don't want to import a > > >> > module for Template Haskell (there is subtleties in this > > >> > too as you will want a little more control than that for > > >> > cross-compilation reasons which I'm not competent about > > >> > to comment on). But the devil is in the many details. > > >> > There's this thing called implicit cross-stage > > >> > persistence which says that anything you import > > >> > not-for-template-haskell is going to be available in > > >> > quotes and splices anyway. Sigh… So you have to turn > > >> > this off. This is what the proposal does. And pretty > > >> > much only. > > >> > > > >> > 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. > > >> > > > >> > For these situations, the proposal kind of advertises > > >> > using `-XImplicitStagePersistence`. Which does seem like > > >> > a fork-like situation to me. Not cool. Yet… yet Template > > >> > Haskell is a big messy ball of yarn, and I don't think > > >> > it's fair to ask of any proposal to entangle it > > >> > completely. The failure of past attempts seem to support > > >> > this case. And I believe the authors are correct when > > >> > they claim that this proposal, in practice, covers a > > >> > vast majority of the uses of Template Haskell out there. > > >> > So maybe we can see that as a new foundation for > > >> > Template Haskell. I'm not thrilled about it, but it's > > >> > probably the most reasonable way forward. > > >> > > > >> > The real problem with this sort of proposal is that then > > >> > I get to write way too long an email to the committee. > > >> > Hopefully this didn't deter you. Read the proposal, and > > >> > let's vote. > > >> > > > >> > -- > > >> > Arnaud Spiwack > > >> > Director, Research at [21]https://moduscreate.com > > >> > <[22]https://moduscreate.com> and [23]https://tweag.io > > >> > <[24]https://tweag.io>. > > >> > > >> > > >> -- > > >> Adam Gundry, Haskell Consultant > > >> Well-Typed LLP, [25]https://www.well-typed.com/ > > >> > > >> Registered in England & Wales, OC335890 > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > >> > > >> _______________________________________________ > > >> ghc-steering-committee mailing list > > >> [26]ghc-steering-committee@haskell.org > > >> [27] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > >> > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > [28]ghc-steering-committee@haskell.org > > > [29] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > > > > > > > > -- > > Arnaud Spiwack > > Director, Research at [30]https://moduscreate.com and [31]https://tweag.io. > > > -- >
--------------------------------------------------------------------
-- > Erik de Castro Lopo > [32]http://www.mega-nerd.com/ >
--
--------------------------------------------------------------------
-- Erik de Castro Lopo [33]http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list [34]ghc-steering-committee@haskell.org [35]
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
ommittee
--
Arnaud Spiwack Director, Research at [36]https://moduscreate.com and [37]https://tweag.io.
References
1. mailto:erikd@mega-nerd.com 2.
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199...
3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... 4. mailto:simon.peytonjones@gmail.com 5. mailto:adam@well-typed.com 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 8. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 9. mailto:simon.peytonjones@gmail.com 10. mailto:simon.peytonjones@gmail.com 11. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... 12. mailto:arnaud.spiwack@tweag.io 13. mailto:arnaud.spiwack@tweag.io 14. mailto:simon.peytonjones@gmail.com 15. mailto:simon.peytonjones@gmail.com 16. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... 17. mailto:arnaud.spiwack@tweag.io 18. mailto:arnaud.spiwack@tweag.io 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 21. https://moduscreate.com/ 22. https://moduscreate.com/ 23. https://tweag.io/ 24. https://tweag.io/ 25. https://www.well-typed.com/ 26. mailto:ghc-steering-committee@haskell.org 27. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 28. mailto:ghc-steering-committee@haskell.org 29. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 30. https://moduscreate.com/ 31. https://tweag.io/ 32. http://www.mega-nerd.com/ 33. http://www.mega-nerd.com/ 34. mailto:ghc-steering-committee@haskell.org 35. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 36. https://moduscreate.com/ 37. https://tweag.io/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
Yes, Arnaud, that was my point, thank you. People voiced opinions about syntax and I didn’t want to silently ignore them. I, however, retract my point about the proposal being ambiguous regarding ImportQualifiedPost. I actually think the specification is clear. Now it is up to us to consider the alternatives. If the rest of the committee does not think that any of the listed syntactic alternatives have merit, I am fine with that. I am not super convinced by Richards argument because I am sceptical that (all) code formatters would implement that grouping soon. So I would consider the proposed alternative of allowing splices after the modid. Best, Malte On 2025-02-10 15:25, Arnaud Spiwack wrote:
For the record, the syntactic alternatives can be found in [§8.5 Syntactic alternatives]([1]https://github.com/well-typed/ghc-proposals/blob/wip/l evel-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternati ves)
Malte seems to be uncomfortable with the fact that the proposed syntax is
import slice Foo import quote Bar
Even when ImportQualifiedPost, which enables the syntax
import Foo qualified [as …]
is enabled.
The proposal offers alternative syntaxes like
import Foo slice Import Bar quote
or (to sound more English)
import Foo for slice import Bar for quote
Richard Eisenberg, in the thread, suggests that the motivation for ImportQualifiedPost doesn't apply to slice/quote because he believes that there's going to be one block of import slice, one block of import (nothing), one block of import quote, and they aren't going to be mixed together. Them being more visually distinguished by starting with the keyword is an asset in this view. Many seem convinced
My understanding of Malte's point is that this is not intuitive enough that it can be left implicit in the proposal, and he'd like the proposal to at least state explicitly that it ignores ImportQualifiedPost.
Malte, let me know if I misrepresent your point of view (or anybody else's).
On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones <[2]simon.peytonjones@gmail.com> wrote:
I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
OK -- but I suspect that most of us have lost context.
Would you like to post (on the Github) a message explaining: * what the syntactic alternatives are * what you recommend
That will help to focus the discussion
Thanks!
Simon
On Fri, 7 Feb 2025 at 12:16, Malte Ott <[3]malte.ott@maralorn.de> wrote:
I do not object to accepting the proposal, but I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
I know we all dread wasting our time with syntax discussions but lets at least think about it for 5 minutes.
Best, Malte
On 2025-02-07 15:48, Arnaud Spiwack wrote: > Ok, we have enough of a quorum at this point. If everybody else voted 1 > extension this would come at a rough draw. It can't be a strong enough > push to overrule the preference of the authors. > > I'll give it a handful more day, say until next Wednesday 12th > February. If someone has a strong objection, please voice it very > loudly. Otherwise I'll declare the proposal as accepted in its current > state. > > Best, > Arnaud > > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo > <[1][4]erikd@mega-nerd.com> wrote: > > OK, slightly in favor of two extensions. > > Erik > > Erik de Castro Lopo wrote: > > > Hi, > > > > I have read through the proposal, but there is something I am > still unsure > > of. For the LANGUAGE pragma's is there any utility in using one > separately > > form the other? It seems there isn't. In any one file you would > use either > > one or the other. > > > > Thanks, > > Erik > > > > Arnaud Spiwack wrote: > > > > > Sorry I disappeared for a while. I second Simon's call, let's > vote. Let me > > > repost a link to Simon's pro and cons post > > > > [2][5]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuec omm > ent-2609199731 > > > > > > So far, we have the following votes > > > > > > - Simon: 1 extension > > > - Adam: 2 extension (feels quite strongly about it) > > > - Sebastian: 1 extension (on the Github thread, but I'll count > it as a vote > > > anyway) > > > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > > > --- > > > > > > Beyond that we have a single piece of community feedback on the > Github > > > thread. It's from Michael Peyton Jones who is in favour of 2 > extensions, > > > find it here > > > > [3][6]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuec omm > ent-2609583126 > > > > > > --- > > > > > > For the record, I hadn't commented about it in my > recommendation, despite > > > my well-known and desperately public distaste for micro > extensions. I have > > > a couple of reasons: > > > - I dislike micro-extensions less now that we are doing the > GHC20XX (the > > > last one was very modest, I'm in favour, by the way, of doing a > much more > > > ambitious language edition soon, otherwise my distaste will come > back with > > > a vengeance) > > > - While I consider every proposal with several extensions in it > with > > > suspicion, the authors did argue for their second extension, I > found the > > > argument mildly convincing, and thought it wasn't worth fighting > against. > > > > > > Now, even like this my preference is mildly for one extension. > Adam says > > > that it's easier to implement warnings with both the new syntax > on and > > > implicit stage persistence left turned on, than to implement > errors when > > > implicit stage persistence is turned off. It may be so, but I > don't think > > > we can avoid implementing the errors anyway, so I don't feel > that it's a > > > particularly compelling argument. I don't feel strongly. But > that's > > > presumably where my vote goes. > > > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > <[4][7]simon.peytonjones@gmail.com> > > > wrote: > > > > > > > Yes: all members of the steering committee, please vote. > Evaluating > > > > proposals is what we all signed up to do! > > > > > > > > Thanks > > > > > > > > Simon > > > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry > <[5][8]adam@well-typed.com> wrote: > > > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for > two > > > >> extensions. As I commented on the GitHub thread: > > > >> > > > >> > We shouldn't unnecessarily conflate a syntactic extension > > > >> (ExplicitLevelImports) with a semantic one > (NoImplicitStagePersistence) > > > >> just because the common case is to want both and we want to > keep the > > > >> number of extensions lower. > > > >> > > > >> If there are reasons why having two extensions is actually > problematic, > > > >> I'd like to hear them. > > > >> > > > >> Also, at the risk of opening another avenue of discussion, we > also need > > > >> to resolve the syntax question (see > > > >> > > > >> > [6][9]https://github.com/ghc-proposals/ghc-proposals/pull/682#discus sio > n_r1849123243). > > > >> > > > >> I don't have a very strong opinion here, but given that some > people do, > > > >> perhaps we should make ImportQualifiedPost affect splice > imports so we > > > >> have > > > >> > > > >> import splice qualified A -- By default > > > >> import A splice qualified -- Under ImportQualifiedPost > > > >> > > > >> In any case, please do vote! It would be good to get this > proposal done. > > > >> > > > >> Cheers, > > > >> > > > >> Adam > > > >> > > > >> > > > >> > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > > >> > Arnaud > > > >> > > > > >> > OK, following my call and some further iteration, the > proposal is much > > > >> > improved. See here > > > >> > > <[7][10]https://github.com/ghc-proposals/ghc-proposals/pull/682>. > Please > > > >> read > > > >> > the new "Proposed Change Specification" which has had a > large rewrite. > > > >> > > > > >> > I vote to accept. > > > >> > > > > >> > BUT there is one point that the committee must resolve: > *one extension > > > >> > of two?* It's just a judgement call and I lay out the > choices in this > > > >> > post > > > >> > < > > > >> > [8][11]https://github.com/ghc-proposals/ghc-proposals/pull/682#issue comm > ent-2609199731>. > > > >> I doubt that we'll get much community feedback. I suggest > that we just > > > >> vote. I vote for one, not two. As does Sebastian. > > > >> > > > > >> > Over to you Arnaud. Let's get this one done. Matthew is > busy > > > >> > implementing it for a customer and it has been on our to-do > list for > > > >> > some time now. (Partly my fault.) > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > > >> > <[9][12]simon.peytonjones@gmail.com > <mailto:[10][13]simon.peytonjones@gmail.com>> > > > >> wrote: > > > >> > > > > >> > Matthew and I had a good conversation. Some notes here > > > >> > < > > > >> > [11][14]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQ R58R > Phk5MslruY7yXD0/edit?usp=sharing > > > >> >. > > > >> > > > > >> > He's going to work on a revision to the proposal which > I'll iterate > > > >> > with him. > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > > >> > <[12][15]arnaud.spiwack@tweag.io > <mailto:[13][16]arnaud.spiwack@tweag.io>> wrote: > > > >> > > > > >> > Then, let's wait until your call with Matthew and > decide how to > > > >> > act then. > > > >> > > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > > >> > <[14][17]simon.peytonjones@gmail.com > > > >> > <mailto:[15][18]simon.peytonjones@gmail.com>> wrote: > > > >> > > > > >> > Arnaud > > > >> > > > > >> > I have responded with a lot of feedback on the > Github thread > > > >> > < > > > >> > [16][19]https://github.com/ghc-proposals/ghc-proposals/pull/682#pull requ > estreview-2562175116 > > > >> >. > > > >> > > > > >> > TL:DR: I like the direction of travel but have > too many > > > >> > questions of detail to be ready to accept it > just yet. > > > >> > > > > >> > I have arranged a call with Matthew. > > > >> > > > > >> > Simon > > > >> > > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > > > >> > <[17][20]arnaud.spiwack@tweag.io > <mailto:[18][21]arnaud.spiwack@tweag.io>> > > > >> > wrote: > > > >> > > > > >> > > > > >> > Mathew Pickering, Rodrigo Mesquita, and our > own Adam > > > >> > Gundry put forward a new proposal for the > perenial > > > >> > problem of dependencies and Template > Haskell > > > >> > > [19][22]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > >> > < > > > >> [20][23]https://github.com/ghc-proposals/ghc-proposals/pull/682> > > > >> > > > > >> > I've got to be honest, I'm not fully > convinced by the > > > >> > proposal. More on that in a minute, but it > learns a > > > >> > lesson from previous attempts at the same > problem by > > > >> > solving the absolute minimal problem, but > this leads to > > > >> > a somewhat fork-like situation for which it > isn't clear > > > >> > whether it will be resolved in the future. > That being > > > >> > said, it solves a real problem which has > plagued GHC > > > >> > compilation forever. And I'm inclined to > believe that we > > > >> > can't really do much better. > > > >> > > > > >> > But I'm getting ahead of myself. The > problem is that > > > >> > when you have -XTemplateHaskell in a file, > all the > > > >> > dependencies' compiled code must suddenly > be available > > > >> > for typechecking. This breaks `-fno-code` > and wounds > > > >> > recompilation avoidance. This is probably > the main > > > >> > reason why it's a widely held belief that > Template > > > >> > Haskell is slow: you use Template Haskell > in a few > > > >> > modules, and suddenly your IDE is much less > responsive > > > >> > and you recompile more files. Yay? > > > >> > > > > >> > Anyway, the general gist of the solution is > clear: we > > > >> > must be able to specify that we don't want > to import a > > > >> > module for Template Haskell (there is > subtleties in this > > > >> > too as you will want a little more control > than that for > > > >> > cross-compilation reasons which I'm not > competent about > > > >> > to comment on). But the devil is in the > many details. > > > >> > There's this thing called implicit > cross-stage > > > >> > persistence which says that anything you > import > > > >> > not-for-template-haskell is going to be > available in > > > >> > quotes and splices anyway. Sigh… So you > have to turn > > > >> > this off. This is what the proposal does. > And pretty > > > >> > much only. > > > >> > > > > >> > 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. > > > >> > > > > >> > For these situations, the proposal kind of > advertises > > > >> > using `-XImplicitStagePersistence`. Which > does seem like > > > >> > a fork-like situation to me. Not cool. Yet… > yet Template > > > >> > Haskell is a big messy ball of yarn, and I > don't think > > > >> > it's fair to ask of any proposal to > entangle it > > > >> > completely. The failure of past attempts > seem to support > > > >> > this case. And I believe the authors are > correct when > > > >> > they claim that this proposal, in practice, > covers a > > > >> > vast majority of the uses of Template > Haskell out there. > > > >> > So maybe we can see that as a new > foundation for > > > >> > Template Haskell. I'm not thrilled about > it, but it's > > > >> > probably the most reasonable way forward. > > > >> > > > > >> > The real problem with this sort of proposal > is that then > > > >> > I get to write way too long an email to the > committee. > > > >> > Hopefully this didn't deter you. Read the > proposal, and > > > >> > let's vote. > > > >> > > > > >> > -- > > > >> > Arnaud Spiwack > > > >> > Director, Research at > [21][24]https://moduscreate.com > > > >> > <[22][25]https://moduscreate.com> and > [23][26]https://tweag.io > > > >> > <[24][27]https://tweag.io>. > > > >> > > > >> > > > >> -- > > > >> Adam Gundry, Haskell Consultant > > > >> Well-Typed LLP, [25][28]https://www.well-typed.com/ > > > >> > > > >> Registered in England & Wales, OC335890 > > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > > >> > > > >> _______________________________________________ > > > >> ghc-steering-committee mailing list > > > >> [26][29]ghc-steering-committee@haskell.org > > > >> > [27][30]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri ng-c > ommittee > > > >> > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > [28][31]ghc-steering-committee@haskell.org > > > > > [29][32]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri ng-c > ommittee > > > > > > > > > > > > > -- > > > Arnaud Spiwack > > > Director, Research at [30][33]https://moduscreate.com and > [31][34]https://tweag.io. > > > > > > -- > > > -------------------------------------------------------------------- > -- > > Erik de Castro Lopo > > [32][35]http://www.mega-nerd.com/ > > > > -- > -------------------------------------------------------------------- > -- > Erik de Castro Lopo > [33][36]http://www.mega-nerd.com/ > _______________________________________________ > ghc-steering-committee mailing list > [34][37]ghc-steering-committee@haskell.org > [35][38]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri ng-c > ommittee > > -- > > Arnaud Spiwack > Director, Research at [36][39]https://moduscreate.com and > [37][40]https://tweag.io. > > References > > 1. mailto:[41]erikd@mega-nerd.com > 2. [42]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom ment-2609199731 > 3. [43]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom ment-2609583126 > 4. mailto:[44]simon.peytonjones@gmail.com > 5. mailto:[45]adam@well-typed.com > 6. [46]https://github.com/ghc-proposals/ghc-proposals/pull/682#discussi on_r1849123243 > 7. [47]https://github.com/ghc-proposals/ghc-proposals/pull/682 > 8. [48]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom ment-2609199731 > 9. mailto:[49]simon.peytonjones@gmail.com > 10. mailto:[50]simon.peytonjones@gmail.com > 11. [51]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R Phk5MslruY7yXD0/edit?usp=sharing > 12. mailto:[52]arnaud.spiwack@tweag.io > 13. mailto:[53]arnaud.spiwack@tweag.io > 14. mailto:[54]simon.peytonjones@gmail.com > 15. mailto:[55]simon.peytonjones@gmail.com > 16. [56]https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ estreview-2562175116 > 17. mailto:[57]arnaud.spiwack@tweag.io > 18. mailto:[58]arnaud.spiwack@tweag.io > 19. [59]https://github.com/ghc-proposals/ghc-proposals/pull/682 > 20. [60]https://github.com/ghc-proposals/ghc-proposals/pull/682 > 21. [61]https://moduscreate.com/ > 22. [62]https://moduscreate.com/ > 23. [63]https://tweag.io/ > 24. [64]https://tweag.io/ > 25. [65]https://www.well-typed.com/ > 26. mailto:[66]ghc-steering-committee@haskell.org > 27. [67]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > 28. mailto:[68]ghc-steering-committee@haskell.org > 29. [69]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > 30. [70]https://moduscreate.com/ > 31. [71]https://tweag.io/ > 32. [72]http://www.mega-nerd.com/ > 33. [73]http://www.mega-nerd.com/ > 34. mailto:[74]ghc-steering-committee@haskell.org > 35. [75]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > 36. [76]https://moduscreate.com/ > 37. [77]https://tweag.io/
> _______________________________________________ > ghc-steering-committee mailing list > [78]ghc-steering-committee@haskell.org > [79]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
_______________________________________________ ghc-steering-committee mailing list [80]ghc-steering-committee@haskell.org [81]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
_______________________________________________ ghc-steering-committee mailing list [82]ghc-steering-committee@haskell.org [83]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
-- Arnaud Spiwack Director, Research at [84]https://moduscreate.com and [85]https://tweag.io.
References
1. https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/prop... 2. mailto:simon.peytonjones@gmail.com 3. mailto:malte.ott@maralorn.de 4. mailto:erikd@mega-nerd.com 5. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm 7. mailto:simon.peytonjones@gmail.com 8. mailto:adam@well-typed.com 9. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio 10. https://github.com/ghc-proposals/ghc-proposals/pull/682 11. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm 12. mailto:simon.peytonjones@gmail.com 13. mailto:simon.peytonjones@gmail.com 14. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R 15. mailto:arnaud.spiwack@tweag.io 16. mailto:arnaud.spiwack@tweag.io 17. mailto:simon.peytonjones@gmail.com 18. mailto:simon.peytonjones@gmail.com 19. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ 20. mailto:arnaud.spiwack@tweag.io 21. mailto:arnaud.spiwack@tweag.io 22. https://github.com/ghc-proposals/ghc-proposals/pull/682 23. https://github.com/ghc-proposals/ghc-proposals/pull/682 24. https://moduscreate.com/ 25. https://moduscreate.com/ 26. https://tweag.io/ 27. https://tweag.io/ 28. https://www.well-typed.com/ 29. mailto:ghc-steering-committee@haskell.org 30. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c 31. mailto:ghc-steering-committee@haskell.org 32. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c 33. https://moduscreate.com/ 34. https://tweag.io/ 35. http://www.mega-nerd.com/ 36. http://www.mega-nerd.com/ 37. mailto:ghc-steering-committee@haskell.org 38. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c 39. https://moduscreate.com/ 40. https://tweag.io/ 41. mailto:erikd@mega-nerd.com 42. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 43. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... 44. mailto:simon.peytonjones@gmail.com 45. mailto:adam@well-typed.com 46. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... 47. https://github.com/ghc-proposals/ghc-proposals/pull/682 48. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 49. mailto:simon.peytonjones@gmail.com 50. mailto:simon.peytonjones@gmail.com 51. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... 52. mailto:arnaud.spiwack@tweag.io 53. mailto:arnaud.spiwack@tweag.io 54. mailto:simon.peytonjones@gmail.com 55. mailto:simon.peytonjones@gmail.com 56. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... 57. mailto:arnaud.spiwack@tweag.io 58. mailto:arnaud.spiwack@tweag.io 59. https://github.com/ghc-proposals/ghc-proposals/pull/682 60. https://github.com/ghc-proposals/ghc-proposals/pull/682 61. https://moduscreate.com/ 62. https://moduscreate.com/ 63. https://tweag.io/ 64. https://tweag.io/ 65. https://www.well-typed.com/ 66. mailto:ghc-steering-committee@haskell.org 67. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 68. mailto:ghc-steering-committee@haskell.org 69. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 70. https://moduscreate.com/ 71. https://tweag.io/ 72. http://www.mega-nerd.com/ 73. http://www.mega-nerd.com/ 74. mailto:ghc-steering-committee@haskell.org 75. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 76. https://moduscreate.com/ 77. https://tweag.io/ 78. mailto:ghc-steering-committee@haskell.org 79. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 80. mailto:ghc-steering-committee@haskell.org 81. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 82. mailto:ghc-steering-committee@haskell.org 83. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 84. https://moduscreate.com/ 85. https://tweag.io/
There's a little bit of a debate going on in the Github thread on the topic of syntax. I'll give this one one last push. If the authors decide that they are ok with specifying the keywords before and after the module name, then we can accept immediately, as there's no voice against this. Otherwise I'll recapitulate everybody's argument here and call for a quick vote. On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
For the record, the syntactic alternatives can be found in [§8.5 Syntactic alternatives]( https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/prop... )
Malte seems to be uncomfortable with the fact that the proposed syntax is
import slice Foo import quote Bar
Even when ImportQualifiedPost, which enables the syntax
import Foo qualified [as …]
is enabled.
The proposal offers alternative syntaxes like
import Foo slice Import Bar quote
or (to sound more English)
import Foo for slice import Bar for quote
Richard Eisenberg, in the thread, suggests that the motivation for ImportQualifiedPost doesn't apply to slice/quote because he believes that there's going to be one block of import slice, one block of import (nothing), one block of import quote, and they aren't going to be mixed together. Them being more visually distinguished by starting with the keyword is an asset in this view. Many seem convinced
My understanding of Malte's point is that this is not intuitive enough that it can be left implicit in the proposal, and he'd like the proposal to at least state explicitly that it ignores ImportQualifiedPost.
Malte, let me know if I misrepresent your point of view (or anybody else's).
On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
OK -- but I suspect that most of us have lost context.
Would you like to post (on the Github) a message explaining:
- what the syntactic alternatives are - what you recommend
That will help to focus the discussion
Thanks!
Simon
On Fri, 7 Feb 2025 at 12:16, Malte Ott <malte.ott@maralorn.de> wrote:
I do not object to accepting the proposal, but I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
I know we all dread wasting our time with syntax discussions but lets at least think about it for 5 minutes.
Best, Malte
On 2025-02-07 15:48, Arnaud Spiwack wrote:
Ok, we have enough of a quorum at this point. If everybody else voted 1 extension this would come at a rough draw. It can't be a strong enough push to overrule the preference of the authors.
I'll give it a handful more day, say until next Wednesday 12th February. If someone has a strong objection, please voice it very loudly. Otherwise I'll declare the proposal as accepted in its current state.
Best, Arnaud
On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo <[1]erikd@mega-nerd.com> wrote:
OK, slightly in favor of two extensions.
Erik
Erik de Castro Lopo wrote:
> Hi, > > I have read through the proposal, but there is something I am still unsure > of. For the LANGUAGE pragma's is there any utility in using one separately > form the other? It seems there isn't. In any one file you would use either > one or the other. > > Thanks, > Erik > > Arnaud Spiwack wrote: > > > Sorry I disappeared for a while. I second Simon's call, let's vote. Let me > > repost a link to Simon's pro and cons post > > [2] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731 > > > > So far, we have the following votes > > > > - Simon: 1 extension > > - Adam: 2 extension (feels quite strongly about it) > > - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote > > anyway) > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > --- > > > > Beyond that we have a single piece of community feedback on the Github > > thread. It's from Michael Peyton Jones who is in favour of 2 extensions, > > find it here > > [3] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609583126 > > > > --- > > > > For the record, I hadn't commented about it in my recommendation, despite > > my well-known and desperately public distaste for micro extensions. I have > > a couple of reasons: > > - I dislike micro-extensions less now that we are doing the GHC20XX (the > > last one was very modest, I'm in favour, by the way, of doing a much more > > ambitious language edition soon, otherwise my distaste will come back with > > a vengeance) > > - While I consider every proposal with several extensions in it with > > suspicion, the authors did argue for their second extension, I found the > > argument mildly convincing, and thought it wasn't worth fighting against. > > > > Now, even like this my preference is mildly for one extension. Adam says > > that it's easier to implement warnings with both the new syntax on and > > implicit stage persistence left turned on, than to implement errors when > > implicit stage persistence is turned off. It may be so, but I don't think > > we can avoid implementing the errors anyway, so I don't feel that it's a > > particularly compelling argument. I don't feel strongly. But that's > > presumably where my vote goes. > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones <[4]simon.peytonjones@gmail.com> > > wrote: > > > > > Yes: all members of the steering committee, please vote. Evaluating > > > proposals is what we all signed up to do! > > > > > > Thanks > > > > > > Simon > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry <[5]adam@well-typed.com> wrote: > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two > > >> extensions. As I commented on the GitHub thread: > > >> > > >> > We shouldn't unnecessarily conflate a syntactic extension > > >> (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) > > >> just because the common case is to want both and we want to keep the > > >> number of extensions lower. > > >> > > >> If there are reasons why having two extensions is actually problematic, > > >> I'd like to hear them. > > >> > > >> Also, at the risk of opening another avenue of discussion, we also need > > >> to resolve the syntax question (see > > >> > > >> [6] https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio n_r1849123243). > > >> > > >> I don't have a very strong opinion here, but given that some people do, > > >> perhaps we should make ImportQualifiedPost affect splice imports so we > > >> have > > >> > > >> import splice qualified A -- By default > > >> import A splice qualified -- Under ImportQualifiedPost > > >> > > >> In any case, please do vote! It would be good to get this proposal done. > > >> > > >> Cheers, > > >> > > >> Adam > > >> > > >> > > >> > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > >> > Arnaud > > >> > > > >> > OK, following my call and some further iteration, the proposal is much > > >> > improved. See here > > >> > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please > > >> read > > >> > the new "Proposed Change Specification" which has had a large rewrite. > > >> > > > >> > I vote to accept. > > >> > > > >> > BUT there is one point that the committee must resolve: *one extension > > >> > of two?* It's just a judgement call and I lay out the choices in this > > >> > post > > >> > < > > >> [8] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731>. > > >> I doubt that we'll get much community feedback. I suggest that we just > > >> vote. I vote for one, not two. As does Sebastian. > > >> > > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > > >> > implementing it for a customer and it has been on our to-do list for > > >> > some time now. (Partly my fault.) > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > >> > <[9]simon.peytonjones@gmail.com <mailto:[10]simon.peytonjones@gmail.com>> > > >> wrote: > > >> > > > >> > Matthew and I had a good conversation. Some notes here > > >> > < > > >> [11] https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R Phk5MslruY7yXD0/edit?usp=sharing > > >> >. > > >> > > > >> > He's going to work on a revision to the proposal which I'll iterate > > >> > with him. > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > >> > <[12]arnaud.spiwack@tweag.io <mailto:[13]arnaud.spiwack@tweag.io>> wrote: > > >> > > > >> > Then, let's wait until your call with Matthew and decide how to > > >> > act then. > > >> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > >> > <[14]simon.peytonjones@gmail.com > > >> > <mailto:[15]simon.peytonjones@gmail.com>> wrote: > > >> > > > >> > Arnaud > > >> > > > >> > I have responded with a lot of feedback on the Github thread > > >> > < > > >> [16] https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ estreview-2562175116 > > >> >. > > >> > > > >> > TL:DR: I like the direction of travel but have too many > > >> > questions of detail to be ready to accept it just yet. > > >> > > > >> > I have arranged a call with Matthew. > > >> > > > >> > Simon > > >> > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > > >> > <[17]arnaud.spiwack@tweag.io <mailto:[18]arnaud.spiwack@tweag.io>> > > >> > wrote: > > >> > > > >> > > > >> > Mathew Pickering, Rodrigo Mesquita, and our own Adam > > >> > Gundry put forward a new proposal for the perenial > > >> > problem of dependencies and Template Haskell > > >> > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > >> > < > > >> [20] https://github.com/ghc-proposals/ghc-proposals/pull/682> > > >> > > > >> > I've got to be honest, I'm not fully convinced by the > > >> > proposal. More on that in a minute, but it learns a > > >> > lesson from previous attempts at the same problem by > > >> > solving the absolute minimal problem, but this leads to > > >> > a somewhat fork-like situation for which it isn't clear > > >> > whether it will be resolved in the future. That being > > >> > said, it solves a real problem which has plagued GHC > > >> > compilation forever. And I'm inclined to believe that we > > >> > can't really do much better. > > >> > > > >> > But I'm getting ahead of myself. The problem is that > > >> > when you have -XTemplateHaskell in a file, all the > > >> > dependencies' compiled code must suddenly be available > > >> > for typechecking. This breaks `-fno-code` and wounds > > >> > recompilation avoidance. This is probably the main > > >> > reason why it's a widely held belief that Template > > >> > Haskell is slow: you use Template Haskell in a few > > >> > modules, and suddenly your IDE is much less responsive > > >> > and you recompile more files. Yay? > > >> > > > >> > Anyway, the general gist of the solution is clear: we > > >> > must be able to specify that we don't want to import a > > >> > module for Template Haskell (there is subtleties in this > > >> > too as you will want a little more control than that for > > >> > cross-compilation reasons which I'm not competent about > > >> > to comment on). But the devil is in the many details. > > >> > There's this thing called implicit cross-stage > > >> > persistence which says that anything you import > > >> > not-for-template-haskell is going to be available in > > >> > quotes and splices anyway. Sigh… So you have to turn > > >> > this off. This is what the proposal does. And pretty > > >> > much only. > > >> > > > >> > 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. > > >> > > > >> > For these situations, the proposal kind of advertises > > >> > using `-XImplicitStagePersistence`. Which does seem like > > >> > a fork-like situation to me. Not cool. Yet… yet Template > > >> > Haskell is a big messy ball of yarn, and I don't think > > >> > it's fair to ask of any proposal to entangle it > > >> > completely. The failure of past attempts seem to support > > >> > this case. And I believe the authors are correct when > > >> > they claim that this proposal, in practice, covers a > > >> > vast majority of the uses of Template Haskell out there. > > >> > So maybe we can see that as a new foundation for > > >> > Template Haskell. I'm not thrilled about it, but it's > > >> > probably the most reasonable way forward. > > >> > > > >> > The real problem with this sort of proposal is that then > > >> > I get to write way too long an email to the committee. > > >> > Hopefully this didn't deter you. Read the proposal, and > > >> > let's vote. > > >> > > > >> > -- > > >> > Arnaud Spiwack > > >> > Director, Research at [21]https://moduscreate.com > > >> > <[22]https://moduscreate.com> and [23]https://tweag.io > > >> > <[24]https://tweag.io>. > > >> > > >> > > >> -- > > >> Adam Gundry, Haskell Consultant > > >> Well-Typed LLP, [25]https://www.well-typed.com/ > > >> > > >> Registered in England & Wales, OC335890 > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > >> > > >> _______________________________________________ > > >> ghc-steering-committee mailing list > > >> [26]ghc-steering-committee@haskell.org > > >> [27] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > >> > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > [28]ghc-steering-committee@haskell.org > > > [29] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > > > > > > > > -- > > Arnaud Spiwack > > Director, Research at [30]https://moduscreate.com and [31]https://tweag.io. > > > -- >
--------------------------------------------------------------------
-- > Erik de Castro Lopo > [32]http://www.mega-nerd.com/ >
--
--------------------------------------------------------------------
-- Erik de Castro Lopo [33]http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list [34]ghc-steering-committee@haskell.org [35]
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
ommittee
--
Arnaud Spiwack Director, Research at [36]https://moduscreate.com and [37]https://tweag.io.
References
1. mailto:erikd@mega-nerd.com 2.
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199...
3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... 4. mailto:simon.peytonjones@gmail.com 5. mailto:adam@well-typed.com 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 8. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 9. mailto:simon.peytonjones@gmail.com 10. mailto:simon.peytonjones@gmail.com 11. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... 12. mailto:arnaud.spiwack@tweag.io 13. mailto:arnaud.spiwack@tweag.io 14. mailto:simon.peytonjones@gmail.com 15. mailto:simon.peytonjones@gmail.com 16. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... 17. mailto:arnaud.spiwack@tweag.io 18. mailto:arnaud.spiwack@tweag.io 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 21. https://moduscreate.com/ 22. https://moduscreate.com/ 23. https://tweag.io/ 24. https://tweag.io/ 25. https://www.well-typed.com/ 26. mailto:ghc-steering-committee@haskell.org 27. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 28. mailto:ghc-steering-committee@haskell.org 29. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 30. https://moduscreate.com/ 31. https://tweag.io/ 32. http://www.mega-nerd.com/ 33. http://www.mega-nerd.com/ 34. mailto:ghc-steering-committee@haskell.org 35. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 36. https://moduscreate.com/ 37. https://tweag.io/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
So, let me recap the situation. The authors favourite syntax is `import splice A` `import quote B` But some community members in the thread (most vocally Matt Parsons, e.g. here https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558... ) feel that there should be more options, that is that all of `import splice A` / `import A splice` `import quote B` / `import A quote` Be available, lest people prefer the right-hand positions and do a proposal to add an extra extension later. The authors are ok (but evidently not ecstatic https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436... ) with allowing both positions for their keyword. It turns out not to be too big of a hassle to implement. Which I propose to be the resolution. Very non-committal on our part, but because it isn't costly, we might as well. This hasn't been a very busy thread, so… let me backtrack: I'll be on holiday next week, so I'll accept the changes as I'm back, this means that you have one week to disagree. Now, this hasn't been a very busy thread so I expect nobody has strong opinions. But, let me propose a protocol. If (and only if) someone is of the strong opinion that only in front is a much better solution. Let them state “I strongly think that `import splice A` should be the only syntax`. One of us says that, let each of you vote, I'll tally the vote when I'm back. PS: I'm excluding only `import A splice` as an option because the authors don't want that and it would require an overwhelming majority to force that on the authors, which evidently doesn't exist, so let's not muddy the water. So the two options are “only in front” and “both position” Speak to you all in a week, Arnaud On Fri, 14 Feb 2025 at 14:19, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
There's a little bit of a debate going on in the Github thread on the topic of syntax. I'll give this one one last push. If the authors decide that they are ok with specifying the keywords before and after the module name, then we can accept immediately, as there's no voice against this. Otherwise I'll recapitulate everybody's argument here and call for a quick vote.
On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
For the record, the syntactic alternatives can be found in [§8.5 Syntactic alternatives]( https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/prop... )
Malte seems to be uncomfortable with the fact that the proposed syntax is
import slice Foo import quote Bar
Even when ImportQualifiedPost, which enables the syntax
import Foo qualified [as …]
is enabled.
The proposal offers alternative syntaxes like
import Foo slice Import Bar quote
or (to sound more English)
import Foo for slice import Bar for quote
Richard Eisenberg, in the thread, suggests that the motivation for ImportQualifiedPost doesn't apply to slice/quote because he believes that there's going to be one block of import slice, one block of import (nothing), one block of import quote, and they aren't going to be mixed together. Them being more visually distinguished by starting with the keyword is an asset in this view. Many seem convinced
My understanding of Malte's point is that this is not intuitive enough that it can be left implicit in the proposal, and he'd like the proposal to at least state explicitly that it ignores ImportQualifiedPost.
Malte, let me know if I misrepresent your point of view (or anybody else's).
On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
OK -- but I suspect that most of us have lost context.
Would you like to post (on the Github) a message explaining:
- what the syntactic alternatives are - what you recommend
That will help to focus the discussion
Thanks!
Simon
On Fri, 7 Feb 2025 at 12:16, Malte Ott <malte.ott@maralorn.de> wrote:
I do not object to accepting the proposal, but I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
I know we all dread wasting our time with syntax discussions but lets at least think about it for 5 minutes.
Best, Malte
On 2025-02-07 15:48, Arnaud Spiwack wrote:
Ok, we have enough of a quorum at this point. If everybody else voted 1 extension this would come at a rough draw. It can't be a strong enough push to overrule the preference of the authors.
I'll give it a handful more day, say until next Wednesday 12th February. If someone has a strong objection, please voice it very loudly. Otherwise I'll declare the proposal as accepted in its current state.
Best, Arnaud
On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo <[1]erikd@mega-nerd.com> wrote:
OK, slightly in favor of two extensions.
Erik
Erik de Castro Lopo wrote:
> Hi, > > I have read through the proposal, but there is something I am still unsure > of. For the LANGUAGE pragma's is there any utility in using one separately > form the other? It seems there isn't. In any one file you would use either > one or the other. > > Thanks, > Erik > > Arnaud Spiwack wrote: > > > Sorry I disappeared for a while. I second Simon's call, let's vote. Let me > > repost a link to Simon's pro and cons post > > [2] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731 > > > > So far, we have the following votes > > > > - Simon: 1 extension > > - Adam: 2 extension (feels quite strongly about it) > > - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote > > anyway) > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > --- > > > > Beyond that we have a single piece of community feedback on the Github > > thread. It's from Michael Peyton Jones who is in favour of 2 extensions, > > find it here > > [3] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609583126 > > > > --- > > > > For the record, I hadn't commented about it in my recommendation, despite > > my well-known and desperately public distaste for micro extensions. I have > > a couple of reasons: > > - I dislike micro-extensions less now that we are doing the GHC20XX (the > > last one was very modest, I'm in favour, by the way, of doing a much more > > ambitious language edition soon, otherwise my distaste will come back with > > a vengeance) > > - While I consider every proposal with several extensions in it with > > suspicion, the authors did argue for their second extension, I found the > > argument mildly convincing, and thought it wasn't worth fighting against. > > > > Now, even like this my preference is mildly for one extension. Adam says > > that it's easier to implement warnings with both the new syntax on and > > implicit stage persistence left turned on, than to implement errors when > > implicit stage persistence is turned off. It may be so, but I don't think > > we can avoid implementing the errors anyway, so I don't feel that it's a > > particularly compelling argument. I don't feel strongly. But that's > > presumably where my vote goes. > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones <[4]simon.peytonjones@gmail.com> > > wrote: > > > > > Yes: all members of the steering committee, please vote. Evaluating > > > proposals is what we all signed up to do! > > > > > > Thanks > > > > > > Simon > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry <[5]adam@well-typed.com> wrote: > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two > > >> extensions. As I commented on the GitHub thread: > > >> > > >> > We shouldn't unnecessarily conflate a syntactic extension > > >> (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) > > >> just because the common case is to want both and we want to keep the > > >> number of extensions lower. > > >> > > >> If there are reasons why having two extensions is actually problematic, > > >> I'd like to hear them. > > >> > > >> Also, at the risk of opening another avenue of discussion, we also need > > >> to resolve the syntax question (see > > >> > > >> [6] https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio n_r1849123243). > > >> > > >> I don't have a very strong opinion here, but given that some people do, > > >> perhaps we should make ImportQualifiedPost affect splice imports so we > > >> have > > >> > > >> import splice qualified A -- By default > > >> import A splice qualified -- Under ImportQualifiedPost > > >> > > >> In any case, please do vote! It would be good to get this proposal done. > > >> > > >> Cheers, > > >> > > >> Adam > > >> > > >> > > >> > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > >> > Arnaud > > >> > > > >> > OK, following my call and some further iteration, the proposal is much > > >> > improved. See here > > >> > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please > > >> read > > >> > the new "Proposed Change Specification" which has had a large rewrite. > > >> > > > >> > I vote to accept. > > >> > > > >> > BUT there is one point that the committee must resolve: *one extension > > >> > of two?* It's just a judgement call and I lay out the choices in this > > >> > post > > >> > < > > >> [8] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731>. > > >> I doubt that we'll get much community feedback. I suggest that we just > > >> vote. I vote for one, not two. As does Sebastian. > > >> > > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > > >> > implementing it for a customer and it has been on our to-do list for > > >> > some time now. (Partly my fault.) > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > >> > <[9]simon.peytonjones@gmail.com <mailto:[10]simon.peytonjones@gmail.com>> > > >> wrote: > > >> > > > >> > Matthew and I had a good conversation. Some notes here > > >> > < > > >> [11] https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R Phk5MslruY7yXD0/edit?usp=sharing > > >> >. > > >> > > > >> > He's going to work on a revision to the proposal which I'll iterate > > >> > with him. > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > >> > <[12]arnaud.spiwack@tweag.io <mailto:[13]arnaud.spiwack@tweag.io>> wrote: > > >> > > > >> > Then, let's wait until your call with Matthew and decide how to > > >> > act then. > > >> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > >> > <[14]simon.peytonjones@gmail.com > > >> > <mailto:[15]simon.peytonjones@gmail.com>> wrote: > > >> > > > >> > Arnaud > > >> > > > >> > I have responded with a lot of feedback on the Github thread > > >> > < > > >> [16] https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ estreview-2562175116 > > >> >. > > >> > > > >> > TL:DR: I like the direction of travel but have too many > > >> > questions of detail to be ready to accept it just yet. > > >> > > > >> > I have arranged a call with Matthew. > > >> > > > >> > Simon > > >> > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > > >> > <[17]arnaud.spiwack@tweag.io <mailto:[18]arnaud.spiwack@tweag.io>> > > >> > wrote: > > >> > > > >> > > > >> > Mathew Pickering, Rodrigo Mesquita, and our own Adam > > >> > Gundry put forward a new proposal for the perenial > > >> > problem of dependencies and Template Haskell > > >> > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > >> > < > > >> [20] https://github.com/ghc-proposals/ghc-proposals/pull/682> > > >> > > > >> > I've got to be honest, I'm not fully convinced by the > > >> > proposal. More on that in a minute, but it learns a > > >> > lesson from previous attempts at the same problem by > > >> > solving the absolute minimal problem, but this leads to > > >> > a somewhat fork-like situation for which it isn't clear > > >> > whether it will be resolved in the future. That being > > >> > said, it solves a real problem which has plagued GHC > > >> > compilation forever. And I'm inclined to believe that we > > >> > can't really do much better. > > >> > > > >> > But I'm getting ahead of myself. The problem is that > > >> > when you have -XTemplateHaskell in a file, all the > > >> > dependencies' compiled code must suddenly be available > > >> > for typechecking. This breaks `-fno-code` and wounds > > >> > recompilation avoidance. This is probably the main > > >> > reason why it's a widely held belief that Template > > >> > Haskell is slow: you use Template Haskell in a few > > >> > modules, and suddenly your IDE is much less responsive > > >> > and you recompile more files. Yay? > > >> > > > >> > Anyway, the general gist of the solution is clear: we > > >> > must be able to specify that we don't want to import a > > >> > module for Template Haskell (there is subtleties in this > > >> > too as you will want a little more control than that for > > >> > cross-compilation reasons which I'm not competent about > > >> > to comment on). But the devil is in the many details. > > >> > There's this thing called implicit cross-stage > > >> > persistence which says that anything you import > > >> > not-for-template-haskell is going to be available in > > >> > quotes and splices anyway. Sigh… So you have to turn > > >> > this off. This is what the proposal does. And pretty > > >> > much only. > > >> > > > >> > 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. > > >> > > > >> > For these situations, the proposal kind of advertises > > >> > using `-XImplicitStagePersistence`. Which does seem like > > >> > a fork-like situation to me. Not cool. Yet… yet Template > > >> > Haskell is a big messy ball of yarn, and I don't think > > >> > it's fair to ask of any proposal to entangle it > > >> > completely. The failure of past attempts seem to support > > >> > this case. And I believe the authors are correct when > > >> > they claim that this proposal, in practice, covers a > > >> > vast majority of the uses of Template Haskell out there. > > >> > So maybe we can see that as a new foundation for > > >> > Template Haskell. I'm not thrilled about it, but it's > > >> > probably the most reasonable way forward. > > >> > > > >> > The real problem with this sort of proposal is that then > > >> > I get to write way too long an email to the committee. > > >> > Hopefully this didn't deter you. Read the proposal, and > > >> > let's vote. > > >> > > > >> > -- > > >> > Arnaud Spiwack > > >> > Director, Research at [21]https://moduscreate.com > > >> > <[22]https://moduscreate.com> and [23]https://tweag.io > > >> > <[24]https://tweag.io>. > > >> > > >> > > >> -- > > >> Adam Gundry, Haskell Consultant > > >> Well-Typed LLP, [25]https://www.well-typed.com/ > > >> > > >> Registered in England & Wales, OC335890 > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > >> > > >> _______________________________________________ > > >> ghc-steering-committee mailing list > > >> [26]ghc-steering-committee@haskell.org > > >> [27] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > >> > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > [28]ghc-steering-committee@haskell.org > > > [29] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > > > > > > > > -- > > Arnaud Spiwack > > Director, Research at [30]https://moduscreate.com and [31]https://tweag.io. > > > -- >
--------------------------------------------------------------------
-- > Erik de Castro Lopo > [32]http://www.mega-nerd.com/ >
--
--------------------------------------------------------------------
-- Erik de Castro Lopo [33]http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list [34]ghc-steering-committee@haskell.org [35]
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
ommittee
--
Arnaud Spiwack Director, Research at [36]https://moduscreate.com and [37]https://tweag.io.
References
1. mailto:erikd@mega-nerd.com 2.
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199...
3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... 4. mailto:simon.peytonjones@gmail.com 5. mailto:adam@well-typed.com 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 8. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 9. mailto:simon.peytonjones@gmail.com 10. mailto:simon.peytonjones@gmail.com 11. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... 12. mailto:arnaud.spiwack@tweag.io 13. mailto:arnaud.spiwack@tweag.io 14. mailto:simon.peytonjones@gmail.com 15. mailto:simon.peytonjones@gmail.com 16. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... 17. mailto:arnaud.spiwack@tweag.io 18. mailto:arnaud.spiwack@tweag.io 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 21. https://moduscreate.com/ 22. https://moduscreate.com/ 23. https://tweag.io/ 24. https://tweag.io/ 25. https://www.well-typed.com/ 26. mailto:ghc-steering-committee@haskell.org 27. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 28. mailto:ghc-steering-committee@haskell.org 29. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 30. https://moduscreate.com/ 31. https://tweag.io/ 32. http://www.mega-nerd.com/ 33. http://www.mega-nerd.com/ 34. mailto:ghc-steering-committee@haskell.org 35. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 36. https://moduscreate.com/ 37. https://tweag.io/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
Syntax is always troublesome, and best resolved by a vote. I think you are asking us to vote on: - (A) splice/quote keywords only before the module name - (B) splice/quote keywords either before or after the module name I vote (A). My opinion is not a strong one. Let's see what other committee members think. RSVP Simon On Fri, 21 Feb 2025 at 07:17, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
So, let me recap the situation.
The authors favourite syntax is `import splice A` `import quote B`
But some community members in the thread (most vocally Matt Parsons, e.g. here https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558... ) feel that there should be more options, that is that all of `import splice A` / `import A splice` `import quote B` / `import A quote`
Be available, lest people prefer the right-hand positions and do a proposal to add an extra extension later.
The authors are ok (but evidently not ecstatic https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436... ) with allowing both positions for their keyword. It turns out not to be too big of a hassle to implement. Which I propose to be the resolution. Very non-committal on our part, but because it isn't costly, we might as well.
This hasn't been a very busy thread, so… let me backtrack: I'll be on holiday next week, so I'll accept the changes as I'm back, this means that you have one week to disagree. Now, this hasn't been a very busy thread so I expect nobody has strong opinions. But, let me propose a protocol. If (and only if) someone is of the strong opinion that only in front is a much better solution. Let them state “I strongly think that `import splice A` should be the only syntax`. One of us says that, let each of you vote, I'll tally the vote when I'm back.
PS: I'm excluding only `import A splice` as an option because the authors don't want that and it would require an overwhelming majority to force that on the authors, which evidently doesn't exist, so let's not muddy the water. So the two options are “only in front” and “both position”
Speak to you all in a week, Arnaud
On Fri, 14 Feb 2025 at 14:19, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
There's a little bit of a debate going on in the Github thread on the topic of syntax. I'll give this one one last push. If the authors decide that they are ok with specifying the keywords before and after the module name, then we can accept immediately, as there's no voice against this. Otherwise I'll recapitulate everybody's argument here and call for a quick vote.
On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
For the record, the syntactic alternatives can be found in [§8.5 Syntactic alternatives]( https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/prop... )
Malte seems to be uncomfortable with the fact that the proposed syntax is
import slice Foo import quote Bar
Even when ImportQualifiedPost, which enables the syntax
import Foo qualified [as …]
is enabled.
The proposal offers alternative syntaxes like
import Foo slice Import Bar quote
or (to sound more English)
import Foo for slice import Bar for quote
Richard Eisenberg, in the thread, suggests that the motivation for ImportQualifiedPost doesn't apply to slice/quote because he believes that there's going to be one block of import slice, one block of import (nothing), one block of import quote, and they aren't going to be mixed together. Them being more visually distinguished by starting with the keyword is an asset in this view. Many seem convinced
My understanding of Malte's point is that this is not intuitive enough that it can be left implicit in the proposal, and he'd like the proposal to at least state explicitly that it ignores ImportQualifiedPost.
Malte, let me know if I misrepresent your point of view (or anybody else's).
On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
OK -- but I suspect that most of us have lost context.
Would you like to post (on the Github) a message explaining:
- what the syntactic alternatives are - what you recommend
That will help to focus the discussion
Thanks!
Simon
On Fri, 7 Feb 2025 at 12:16, Malte Ott <malte.ott@maralorn.de> wrote:
I do not object to accepting the proposal, but I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
I know we all dread wasting our time with syntax discussions but lets at least think about it for 5 minutes.
Best, Malte
On 2025-02-07 15:48, Arnaud Spiwack wrote:
Ok, we have enough of a quorum at this point. If everybody else voted 1 extension this would come at a rough draw. It can't be a strong enough push to overrule the preference of the authors.
I'll give it a handful more day, say until next Wednesday 12th February. If someone has a strong objection, please voice it very loudly. Otherwise I'll declare the proposal as accepted in its current state.
Best, Arnaud
On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo <[1]erikd@mega-nerd.com> wrote:
OK, slightly in favor of two extensions.
Erik
Erik de Castro Lopo wrote:
> Hi, > > I have read through the proposal, but there is something I am still unsure > of. For the LANGUAGE pragma's is there any utility in using one separately > form the other? It seems there isn't. In any one file you would use either > one or the other. > > Thanks, > Erik > > Arnaud Spiwack wrote: > > > Sorry I disappeared for a while. I second Simon's call, let's vote. Let me > > repost a link to Simon's pro and cons post > > [2] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731 > > > > So far, we have the following votes > > > > - Simon: 1 extension > > - Adam: 2 extension (feels quite strongly about it) > > - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote > > anyway) > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > --- > > > > Beyond that we have a single piece of community feedback on the Github > > thread. It's from Michael Peyton Jones who is in favour of 2 extensions, > > find it here > > [3] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609583126 > > > > --- > > > > For the record, I hadn't commented about it in my recommendation, despite > > my well-known and desperately public distaste for micro extensions. I have > > a couple of reasons: > > - I dislike micro-extensions less now that we are doing the GHC20XX (the > > last one was very modest, I'm in favour, by the way, of doing a much more > > ambitious language edition soon, otherwise my distaste will come back with > > a vengeance) > > - While I consider every proposal with several extensions in it with > > suspicion, the authors did argue for their second extension, I found the > > argument mildly convincing, and thought it wasn't worth fighting against. > > > > Now, even like this my preference is mildly for one extension. Adam says > > that it's easier to implement warnings with both the new syntax on and > > implicit stage persistence left turned on, than to implement errors when > > implicit stage persistence is turned off. It may be so, but I don't think > > we can avoid implementing the errors anyway, so I don't feel that it's a > > particularly compelling argument. I don't feel strongly. But that's > > presumably where my vote goes. > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones <[4]simon.peytonjones@gmail.com> > > wrote: > > > > > Yes: all members of the steering committee, please vote. Evaluating > > > proposals is what we all signed up to do! > > > > > > Thanks > > > > > > Simon > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry <[5]adam@well-typed.com> wrote: > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two > > >> extensions. As I commented on the GitHub thread: > > >> > > >> > We shouldn't unnecessarily conflate a syntactic extension > > >> (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) > > >> just because the common case is to want both and we want to keep the > > >> number of extensions lower. > > >> > > >> If there are reasons why having two extensions is actually problematic, > > >> I'd like to hear them. > > >> > > >> Also, at the risk of opening another avenue of discussion, we also need > > >> to resolve the syntax question (see > > >> > > >> [6] https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio n_r1849123243). > > >> > > >> I don't have a very strong opinion here, but given that some people do, > > >> perhaps we should make ImportQualifiedPost affect splice imports so we > > >> have > > >> > > >> import splice qualified A -- By default > > >> import A splice qualified -- Under ImportQualifiedPost > > >> > > >> In any case, please do vote! It would be good to get this proposal done. > > >> > > >> Cheers, > > >> > > >> Adam > > >> > > >> > > >> > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > >> > Arnaud > > >> > > > >> > OK, following my call and some further iteration, the proposal is much > > >> > improved. See here > > >> > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. Please > > >> read > > >> > the new "Proposed Change Specification" which has had a large rewrite. > > >> > > > >> > I vote to accept. > > >> > > > >> > BUT there is one point that the committee must resolve: *one extension > > >> > of two?* It's just a judgement call and I lay out the choices in this > > >> > post > > >> > < > > >> [8] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm ent-2609199731>. > > >> I doubt that we'll get much community feedback. I suggest that we just > > >> vote. I vote for one, not two. As does Sebastian. > > >> > > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > > >> > implementing it for a customer and it has been on our to-do list for > > >> > some time now. (Partly my fault.) > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > >> > <[9]simon.peytonjones@gmail.com <mailto:[10]simon.peytonjones@gmail.com>> > > >> wrote: > > >> > > > >> > Matthew and I had a good conversation. Some notes here > > >> > < > > >> [11] https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R Phk5MslruY7yXD0/edit?usp=sharing > > >> >. > > >> > > > >> > He's going to work on a revision to the proposal which I'll iterate > > >> > with him. > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > >> > <[12]arnaud.spiwack@tweag.io <mailto:[13]arnaud.spiwack@tweag.io>> wrote: > > >> > > > >> > Then, let's wait until your call with Matthew and decide how to > > >> > act then. > > >> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > >> > <[14]simon.peytonjones@gmail.com > > >> > <mailto:[15]simon.peytonjones@gmail.com>> wrote: > > >> > > > >> > Arnaud > > >> > > > >> > I have responded with a lot of feedback on the Github thread > > >> > < > > >> [16] https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ estreview-2562175116 > > >> >. > > >> > > > >> > TL:DR: I like the direction of travel but have too many > > >> > questions of detail to be ready to accept it just yet. > > >> > > > >> > I have arranged a call with Matthew. > > >> > > > >> > Simon > > >> > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > > >> > <[17]arnaud.spiwack@tweag.io <mailto:[18]arnaud.spiwack@tweag.io>> > > >> > wrote: > > >> > > > >> > > > >> > Mathew Pickering, Rodrigo Mesquita, and our own Adam > > >> > Gundry put forward a new proposal for the perenial > > >> > problem of dependencies and Template Haskell > > >> > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > >> > < > > >> [20] https://github.com/ghc-proposals/ghc-proposals/pull/682> > > >> > > > >> > I've got to be honest, I'm not fully convinced by the > > >> > proposal. More on that in a minute, but it learns a > > >> > lesson from previous attempts at the same problem by > > >> > solving the absolute minimal problem, but this leads to > > >> > a somewhat fork-like situation for which it isn't clear > > >> > whether it will be resolved in the future. That being > > >> > said, it solves a real problem which has plagued GHC > > >> > compilation forever. And I'm inclined to believe that we > > >> > can't really do much better. > > >> > > > >> > But I'm getting ahead of myself. The problem is that > > >> > when you have -XTemplateHaskell in a file, all the > > >> > dependencies' compiled code must suddenly be available > > >> > for typechecking. This breaks `-fno-code` and wounds > > >> > recompilation avoidance. This is probably the main > > >> > reason why it's a widely held belief that Template > > >> > Haskell is slow: you use Template Haskell in a few > > >> > modules, and suddenly your IDE is much less responsive > > >> > and you recompile more files. Yay? > > >> > > > >> > Anyway, the general gist of the solution is clear: we > > >> > must be able to specify that we don't want to import a > > >> > module for Template Haskell (there is subtleties in this > > >> > too as you will want a little more control than that for > > >> > cross-compilation reasons which I'm not competent about > > >> > to comment on). But the devil is in the many details. > > >> > There's this thing called implicit cross-stage > > >> > persistence which says that anything you import > > >> > not-for-template-haskell is going to be available in > > >> > quotes and splices anyway. Sigh… So you have to turn > > >> > this off. This is what the proposal does. And pretty > > >> > much only. > > >> > > > >> > 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. > > >> > > > >> > For these situations, the proposal kind of advertises > > >> > using `-XImplicitStagePersistence`. Which does seem like > > >> > a fork-like situation to me. Not cool. Yet… yet Template > > >> > Haskell is a big messy ball of yarn, and I don't think > > >> > it's fair to ask of any proposal to entangle it > > >> > completely. The failure of past attempts seem to support > > >> > this case. And I believe the authors are correct when > > >> > they claim that this proposal, in practice, covers a > > >> > vast majority of the uses of Template Haskell out there. > > >> > So maybe we can see that as a new foundation for > > >> > Template Haskell. I'm not thrilled about it, but it's > > >> > probably the most reasonable way forward. > > >> > > > >> > The real problem with this sort of proposal is that then > > >> > I get to write way too long an email to the committee. > > >> > Hopefully this didn't deter you. Read the proposal, and > > >> > let's vote. > > >> > > > >> > -- > > >> > Arnaud Spiwack > > >> > Director, Research at [21]https://moduscreate.com > > >> > <[22]https://moduscreate.com> and [23]https://tweag.io > > >> > <[24]https://tweag.io>. > > >> > > >> > > >> -- > > >> Adam Gundry, Haskell Consultant > > >> Well-Typed LLP, [25]https://www.well-typed.com/ > > >> > > >> Registered in England & Wales, OC335890 > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > >> > > >> _______________________________________________ > > >> ghc-steering-committee mailing list > > >> [26]ghc-steering-committee@haskell.org > > >> [27] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > >> > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > [28]ghc-steering-committee@haskell.org > > > [29] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > > > > > > > > > -- > > Arnaud Spiwack > > Director, Research at [30]https://moduscreate.com and [31]https://tweag.io. > > > -- >
--------------------------------------------------------------------
-- > Erik de Castro Lopo > [32]http://www.mega-nerd.com/ >
--
--------------------------------------------------------------------
-- Erik de Castro Lopo [33]http://www.mega-nerd.com/ _______________________________________________ ghc-steering-committee mailing list [34]ghc-steering-committee@haskell.org [35]
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
ommittee
--
Arnaud Spiwack Director, Research at [36]https://moduscreate.com and [37]https://tweag.io.
References
1. mailto:erikd@mega-nerd.com 2.
https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199...
3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... 4. mailto:simon.peytonjones@gmail.com 5. mailto:adam@well-typed.com 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 8. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 9. mailto:simon.peytonjones@gmail.com 10. mailto:simon.peytonjones@gmail.com 11. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... 12. mailto:arnaud.spiwack@tweag.io 13. mailto:arnaud.spiwack@tweag.io 14. mailto:simon.peytonjones@gmail.com 15. mailto:simon.peytonjones@gmail.com 16. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... 17. mailto:arnaud.spiwack@tweag.io 18. mailto:arnaud.spiwack@tweag.io 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 21. https://moduscreate.com/ 22. https://moduscreate.com/ 23. https://tweag.io/ 24. https://tweag.io/ 25. https://www.well-typed.com/ 26. mailto:ghc-steering-committee@haskell.org 27. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 28. mailto:ghc-steering-committee@haskell.org 29. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 30. https://moduscreate.com/ 31. https://tweag.io/ 32. http://www.mega-nerd.com/ 33. http://www.mega-nerd.com/ 34. mailto:ghc-steering-committee@haskell.org 35. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 36. https://moduscreate.com/ 37. https://tweag.io/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
There may have been delivery issues last week to the committee mailing list. Did everybody get this email by Simon and mine below? On Fri, 21 Feb 2025 at 17:23, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Syntax is always troublesome, and best resolved by a vote. I think you are asking us to vote on:
- (A) splice/quote keywords only before the module name - (B) splice/quote keywords either before or after the module name
I vote (A). My opinion is not a strong one. Let's see what other committee members think. RSVP
Simon
On Fri, 21 Feb 2025 at 07:17, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
So, let me recap the situation.
The authors favourite syntax is `import splice A` `import quote B`
But some community members in the thread (most vocally Matt Parsons, e.g. here https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558... ) feel that there should be more options, that is that all of `import splice A` / `import A splice` `import quote B` / `import A quote`
Be available, lest people prefer the right-hand positions and do a proposal to add an extra extension later.
The authors are ok (but evidently not ecstatic https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436... ) with allowing both positions for their keyword. It turns out not to be too big of a hassle to implement. Which I propose to be the resolution. Very non-committal on our part, but because it isn't costly, we might as well.
This hasn't been a very busy thread, so… let me backtrack: I'll be on holiday next week, so I'll accept the changes as I'm back, this means that you have one week to disagree. Now, this hasn't been a very busy thread so I expect nobody has strong opinions. But, let me propose a protocol. If (and only if) someone is of the strong opinion that only in front is a much better solution. Let them state “I strongly think that `import splice A` should be the only syntax`. One of us says that, let each of you vote, I'll tally the vote when I'm back.
PS: I'm excluding only `import A splice` as an option because the authors don't want that and it would require an overwhelming majority to force that on the authors, which evidently doesn't exist, so let's not muddy the water. So the two options are “only in front” and “both position”
Speak to you all in a week, Arnaud
On Fri, 14 Feb 2025 at 14:19, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
There's a little bit of a debate going on in the Github thread on the topic of syntax. I'll give this one one last push. If the authors decide that they are ok with specifying the keywords before and after the module name, then we can accept immediately, as there's no voice against this. Otherwise I'll recapitulate everybody's argument here and call for a quick vote.
On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:
For the record, the syntactic alternatives can be found in [§8.5 Syntactic alternatives]( https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/prop... )
Malte seems to be uncomfortable with the fact that the proposed syntax is
import slice Foo import quote Bar
Even when ImportQualifiedPost, which enables the syntax
import Foo qualified [as …]
is enabled.
The proposal offers alternative syntaxes like
import Foo slice Import Bar quote
or (to sound more English)
import Foo for slice import Bar for quote
Richard Eisenberg, in the thread, suggests that the motivation for ImportQualifiedPost doesn't apply to slice/quote because he believes that there's going to be one block of import slice, one block of import (nothing), one block of import quote, and they aren't going to be mixed together. Them being more visually distinguished by starting with the keyword is an asset in this view. Many seem convinced
My understanding of Malte's point is that this is not intuitive enough that it can be left implicit in the proposal, and he'd like the proposal to at least state explicitly that it ignores ImportQualifiedPost.
Malte, let me know if I misrepresent your point of view (or anybody else's).
On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
OK -- but I suspect that most of us have lost context.
Would you like to post (on the Github) a message explaining:
- what the syntactic alternatives are - what you recommend
That will help to focus the discussion
Thanks!
Simon
On Fri, 7 Feb 2025 at 12:16, Malte Ott <malte.ott@maralorn.de> wrote:
I do not object to accepting the proposal, but I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
I know we all dread wasting our time with syntax discussions but lets at least think about it for 5 minutes.
Best, Malte
On 2025-02-07 15:48, Arnaud Spiwack wrote: > Ok, we have enough of a quorum at this point. If everybody else voted 1 > extension this would come at a rough draw. It can't be a strong enough > push to overrule the preference of the authors. > > I'll give it a handful more day, say until next Wednesday 12th > February. If someone has a strong objection, please voice it very > loudly. Otherwise I'll declare the proposal as accepted in its current > state. > > Best, > Arnaud > > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo > <[1]erikd@mega-nerd.com> wrote: > > OK, slightly in favor of two extensions. > > Erik > > Erik de Castro Lopo wrote: > > > Hi, > > > > I have read through the proposal, but there is something I am > still unsure > > of. For the LANGUAGE pragma's is there any utility in using one > separately > > form the other? It seems there isn't. In any one file you would > use either > > one or the other. > > > > Thanks, > > Erik > > > > Arnaud Spiwack wrote: > > > > > Sorry I disappeared for a while. I second Simon's call, let's > vote. Let me > > > repost a link to Simon's pro and cons post > > > > [2] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > ent-2609199731 > > > > > > So far, we have the following votes > > > > > > - Simon: 1 extension > > > - Adam: 2 extension (feels quite strongly about it) > > > - Sebastian: 1 extension (on the Github thread, but I'll count > it as a vote > > > anyway) > > > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > > > --- > > > > > > Beyond that we have a single piece of community feedback on the > Github > > > thread. It's from Michael Peyton Jones who is in favour of 2 > extensions, > > > find it here > > > > [3] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > ent-2609583126 > > > > > > --- > > > > > > For the record, I hadn't commented about it in my > recommendation, despite > > > my well-known and desperately public distaste for micro > extensions. I have > > > a couple of reasons: > > > - I dislike micro-extensions less now that we are doing the > GHC20XX (the > > > last one was very modest, I'm in favour, by the way, of doing a > much more > > > ambitious language edition soon, otherwise my distaste will come > back with > > > a vengeance) > > > - While I consider every proposal with several extensions in it > with > > > suspicion, the authors did argue for their second extension, I > found the > > > argument mildly convincing, and thought it wasn't worth fighting > against. > > > > > > Now, even like this my preference is mildly for one extension. > Adam says > > > that it's easier to implement warnings with both the new syntax > on and > > > implicit stage persistence left turned on, than to implement > errors when > > > implicit stage persistence is turned off. It may be so, but I > don't think > > > we can avoid implementing the errors anyway, so I don't feel > that it's a > > > particularly compelling argument. I don't feel strongly. But > that's > > > presumably where my vote goes. > > > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > <[4]simon.peytonjones@gmail.com> > > > wrote: > > > > > > > Yes: all members of the steering committee, please vote. > Evaluating > > > > proposals is what we all signed up to do! > > > > > > > > Thanks > > > > > > > > Simon > > > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry > <[5]adam@well-typed.com> wrote: > > > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for > two > > > >> extensions. As I commented on the GitHub thread: > > > >> > > > >> > We shouldn't unnecessarily conflate a syntactic extension > > > >> (ExplicitLevelImports) with a semantic one > (NoImplicitStagePersistence) > > > >> just because the common case is to want both and we want to > keep the > > > >> number of extensions lower. > > > >> > > > >> If there are reasons why having two extensions is actually > problematic, > > > >> I'd like to hear them. > > > >> > > > >> Also, at the risk of opening another avenue of discussion, we > also need > > > >> to resolve the syntax question (see > > > >> > > > >> > [6] https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio > n_r1849123243). > > > >> > > > >> I don't have a very strong opinion here, but given that some > people do, > > > >> perhaps we should make ImportQualifiedPost affect splice > imports so we > > > >> have > > > >> > > > >> import splice qualified A -- By default > > > >> import A splice qualified -- Under ImportQualifiedPost > > > >> > > > >> In any case, please do vote! It would be good to get this > proposal done. > > > >> > > > >> Cheers, > > > >> > > > >> Adam > > > >> > > > >> > > > >> > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > > >> > Arnaud > > > >> > > > > >> > OK, following my call and some further iteration, the > proposal is much > > > >> > improved. See here > > > >> > > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. > Please > > > >> read > > > >> > the new "Proposed Change Specification" which has had a > large rewrite. > > > >> > > > > >> > I vote to accept. > > > >> > > > > >> > BUT there is one point that the committee must resolve: > *one extension > > > >> > of two?* It's just a judgement call and I lay out the > choices in this > > > >> > post > > > >> > < > > > >> > [8] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > ent-2609199731>. > > > >> I doubt that we'll get much community feedback. I suggest > that we just > > > >> vote. I vote for one, not two. As does Sebastian. > > > >> > > > > >> > Over to you Arnaud. Let's get this one done. Matthew is > busy > > > >> > implementing it for a customer and it has been on our to-do > list for > > > >> > some time now. (Partly my fault.) > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > > >> > <[9]simon.peytonjones@gmail.com > <mailto:[10]simon.peytonjones@gmail.com>> > > > >> wrote: > > > >> > > > > >> > Matthew and I had a good conversation. Some notes here > > > >> > < > > > >> > [11] https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R > Phk5MslruY7yXD0/edit?usp=sharing > > > >> >. > > > >> > > > > >> > He's going to work on a revision to the proposal which > I'll iterate > > > >> > with him. > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > > >> > <[12]arnaud.spiwack@tweag.io > <mailto:[13]arnaud.spiwack@tweag.io>> wrote: > > > >> > > > > >> > Then, let's wait until your call with Matthew and > decide how to > > > >> > act then. > > > >> > > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > > >> > <[14]simon.peytonjones@gmail.com > > > >> > <mailto:[15]simon.peytonjones@gmail.com>> wrote: > > > >> > > > > >> > Arnaud > > > >> > > > > >> > I have responded with a lot of feedback on the > Github thread > > > >> > < > > > >> > [16] https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ > estreview-2562175116 > > > >> >. > > > >> > > > > >> > TL:DR: I like the direction of travel but have > too many > > > >> > questions of detail to be ready to accept it > just yet. > > > >> > > > > >> > I have arranged a call with Matthew. > > > >> > > > > >> > Simon > > > >> > > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > > > >> > <[17]arnaud.spiwack@tweag.io > <mailto:[18]arnaud.spiwack@tweag.io>> > > > >> > wrote: > > > >> > > > > >> > > > > >> > Mathew Pickering, Rodrigo Mesquita, and our > own Adam > > > >> > Gundry put forward a new proposal for the > perenial > > > >> > problem of dependencies and Template > Haskell > > > >> > > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > >> > < > > > >> [20] https://github.com/ghc-proposals/ghc-proposals/pull/682> > > > >> > > > > >> > I've got to be honest, I'm not fully > convinced by the > > > >> > proposal. More on that in a minute, but it > learns a > > > >> > lesson from previous attempts at the same > problem by > > > >> > solving the absolute minimal problem, but > this leads to > > > >> > a somewhat fork-like situation for which it > isn't clear > > > >> > whether it will be resolved in the future. > That being > > > >> > said, it solves a real problem which has > plagued GHC > > > >> > compilation forever. And I'm inclined to > believe that we > > > >> > can't really do much better. > > > >> > > > > >> > But I'm getting ahead of myself. The > problem is that > > > >> > when you have -XTemplateHaskell in a file, > all the > > > >> > dependencies' compiled code must suddenly > be available > > > >> > for typechecking. This breaks `-fno-code` > and wounds > > > >> > recompilation avoidance. This is probably > the main > > > >> > reason why it's a widely held belief that > Template > > > >> > Haskell is slow: you use Template Haskell > in a few > > > >> > modules, and suddenly your IDE is much less > responsive > > > >> > and you recompile more files. Yay? > > > >> > > > > >> > Anyway, the general gist of the solution is > clear: we > > > >> > must be able to specify that we don't want > to import a > > > >> > module for Template Haskell (there is > subtleties in this > > > >> > too as you will want a little more control > than that for > > > >> > cross-compilation reasons which I'm not > competent about > > > >> > to comment on). But the devil is in the > many details. > > > >> > There's this thing called implicit > cross-stage > > > >> > persistence which says that anything you > import > > > >> > not-for-template-haskell is going to be > available in > > > >> > quotes and splices anyway. Sigh… So you > have to turn > > > >> > this off. This is what the proposal does. > And pretty > > > >> > much only. > > > >> > > > > >> > 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. > > > >> > > > > >> > For these situations, the proposal kind of > advertises > > > >> > using `-XImplicitStagePersistence`. Which > does seem like > > > >> > a fork-like situation to me. Not cool. Yet… > yet Template > > > >> > Haskell is a big messy ball of yarn, and I > don't think > > > >> > it's fair to ask of any proposal to > entangle it > > > >> > completely. The failure of past attempts > seem to support > > > >> > this case. And I believe the authors are > correct when > > > >> > they claim that this proposal, in practice, > covers a > > > >> > vast majority of the uses of Template > Haskell out there. > > > >> > So maybe we can see that as a new > foundation for > > > >> > Template Haskell. I'm not thrilled about > it, but it's > > > >> > probably the most reasonable way forward. > > > >> > > > > >> > The real problem with this sort of proposal > is that then > > > >> > I get to write way too long an email to the > committee. > > > >> > Hopefully this didn't deter you. Read the > proposal, and > > > >> > let's vote. > > > >> > > > > >> > -- > > > >> > Arnaud Spiwack > > > >> > Director, Research at > [21]https://moduscreate.com > > > >> > <[22]https://moduscreate.com> and > [23]https://tweag.io > > > >> > <[24]https://tweag.io>. > > > >> > > > >> > > > >> -- > > > >> Adam Gundry, Haskell Consultant > > > >> Well-Typed LLP, [25]https://www.well-typed.com/ > > > >> > > > >> Registered in England & Wales, OC335890 > > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > > >> > > > >> _______________________________________________ > > > >> ghc-steering-committee mailing list > > > >> [26]ghc-steering-committee@haskell.org > > > >> > [27] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > > >> > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > [28]ghc-steering-committee@haskell.org > > > > > [29] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > > > > > > > > > > > > -- > > > Arnaud Spiwack > > > Director, Research at [30]https://moduscreate.com and > [31]https://tweag.io. > > > > > > -- > > > -------------------------------------------------------------------- > -- > > Erik de Castro Lopo > > [32]http://www.mega-nerd.com/ > > > > -- > -------------------------------------------------------------------- > -- > Erik de Castro Lopo > [33]http://www.mega-nerd.com/ > _______________________________________________ > ghc-steering-committee mailing list > [34]ghc-steering-committee@haskell.org > [35] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > -- > > Arnaud Spiwack > Director, Research at [36]https://moduscreate.com and > [37]https://tweag.io. > > References > > 1. mailto:erikd@mega-nerd.com > 2. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... > 3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... > 4. mailto:simon.peytonjones@gmail.com > 5. mailto:adam@well-typed.com > 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... > 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 8. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... > 9. mailto:simon.peytonjones@gmail.com > 10. mailto:simon.peytonjones@gmail.com > 11. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... > 12. mailto:arnaud.spiwack@tweag.io > 13. mailto:arnaud.spiwack@tweag.io > 14. mailto:simon.peytonjones@gmail.com > 15. mailto:simon.peytonjones@gmail.com > 16. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... > 17. mailto:arnaud.spiwack@tweag.io > 18. mailto:arnaud.spiwack@tweag.io > 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 21. https://moduscreate.com/ > 22. https://moduscreate.com/ > 23. https://tweag.io/ > 24. https://tweag.io/ > 25. https://www.well-typed.com/ > 26. mailto:ghc-steering-committee@haskell.org > 27. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 28. mailto:ghc-steering-committee@haskell.org > 29. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 30. https://moduscreate.com/ > 31. https://tweag.io/ > 32. http://www.mega-nerd.com/ > 33. http://www.mega-nerd.com/ > 34. mailto:ghc-steering-committee@haskell.org > 35. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 36. https://moduscreate.com/ > 37. https://tweag.io/
> _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org > 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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
I for my part are kinda dissatisfied by both options. And I am very much sympathetic to the position that a committee shouldn’t settle alternatives by allowing all of them. That being said I am still in favor of leaving the proposal like it is now, which is (B). My dream would be to rename ImportQualifiedPost to ImportAnnotationsPost or something similar and then treat splice exactly as qualified. Seeing that that’s much too much trouble I would consider doing that but not changing the extension name. I can also see the reasoning that we should just go with (A) now without blocking the proposal any longer because it will always be possible to convert it to (B) later. Best Malte On 2025-03-03 15:52, Arnaud Spiwack wrote:
There may have been delivery issues last week to the committee mailing list. Did everybody get this email by Simon and mine below?
On Fri, 21 Feb 2025 at 17:23, Simon Peyton Jones <[1]simon.peytonjones@gmail.com> wrote:
Syntax is always troublesome, and best resolved by a vote. I think you are asking us to vote on: * (A) splice/quote keywords only before the module name * (B) splice/quote keywords either before or after the module name
I vote (A). My opinion is not a strong one. Let's see what other committee members think. RSVP
Simon
On Fri, 21 Feb 2025 at 07:17, Arnaud Spiwack <[2]arnaud.spiwack@tweag.io> wrote:
So, let me recap the situation.
The authors favourite syntax is `import splice A` `import quote B`
But some community members in the thread (most vocally Matt Parsons, e.g. here [3]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment -2651558160 ) feel that there should be more options, that is that all of `import splice A` / `import A splice` `import quote B` / `import A quote`
Be available, lest people prefer the right-hand positions and do a proposal to add an extra extension later.
The authors are ok (but evidently not ecstatic [4]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment -2671436455 ) with allowing both positions for their keyword. It turns out not to be too big of a hassle to implement. Which I propose to be the resolution. Very non-committal on our part, but because it isn't costly, we might as well.
This hasn't been a very busy thread, so… let me backtrack: I'll be on holiday next week, so I'll accept the changes as I'm back, this means that you have one week to disagree. Now, this hasn't been a very busy thread so I expect nobody has strong opinions. But, let me propose a protocol. If (and only if) someone is of the strong opinion that only in front is a much better solution. Let them state “I strongly think that `import splice A` should be the only syntax`. One of us says that, let each of you vote, I'll tally the vote when I'm back.
PS: I'm excluding only `import A splice` as an option because the authors don't want that and it would require an overwhelming majority to force that on the authors, which evidently doesn't exist, so let's not muddy the water. So the two options are “only in front” and “both position”
Speak to you all in a week, Arnaud
On Fri, 14 Feb 2025 at 14:19, Arnaud Spiwack <[5]arnaud.spiwack@tweag.io> wrote:
There's a little bit of a debate going on in the Github thread on the topic of syntax. I'll give this one one last push. If the authors decide that they are ok with specifying the keywords before and after the module name, then we can accept immediately, as there's no voice against this. Otherwise I'll recapitulate everybody's argument here and call for a quick vote.
On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack <[6]arnaud.spiwack@tweag.io> wrote:
For the record, the syntactic alternatives can be found in [§8.5 Syntactic alternatives]([7]https://github.com/well-typed/ghc-proposals/blob/wip/l evel-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternati ves)
Malte seems to be uncomfortable with the fact that the proposed syntax is
import slice Foo import quote Bar
Even when ImportQualifiedPost, which enables the syntax
import Foo qualified [as …]
is enabled.
The proposal offers alternative syntaxes like
import Foo slice Import Bar quote
or (to sound more English)
import Foo for slice import Bar for quote
Richard Eisenberg, in the thread, suggests that the motivation for ImportQualifiedPost doesn't apply to slice/quote because he believes that there's going to be one block of import slice, one block of import (nothing), one block of import quote, and they aren't going to be mixed together. Them being more visually distinguished by starting with the keyword is an asset in this view. Many seem convinced
My understanding of Malte's point is that this is not intuitive enough that it can be left implicit in the proposal, and he'd like the proposal to at least state explicitly that it ignores ImportQualifiedPost.
Malte, let me know if I misrepresent your point of view (or anybody else's).
On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones <[8]simon.peytonjones@gmail.com> wrote:
I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
OK -- but I suspect that most of us have lost context.
Would you like to post (on the Github) a message explaining: * what the syntactic alternatives are * what you recommend
That will help to focus the discussion
Thanks!
Simon
On Fri, 7 Feb 2025 at 12:16, Malte Ott <[9]malte.ott@maralorn.de> wrote:
I do not object to accepting the proposal, but I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
I know we all dread wasting our time with syntax discussions but lets at least think about it for 5 minutes.
Best, Malte
On 2025-02-07 15:48, Arnaud Spiwack wrote: > Ok, we have enough of a quorum at this point. If everybody else voted 1 > extension this would come at a rough draw. It can't be a strong enough > push to overrule the preference of the authors. > > I'll give it a handful more day, say until next Wednesday 12th > February. If someone has a strong objection, please voice it very > loudly. Otherwise I'll declare the proposal as accepted in its current > state. > > Best, > Arnaud > > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo > <[1][10]erikd@mega-nerd.com> wrote: > > OK, slightly in favor of two extensions. > > Erik > > Erik de Castro Lopo wrote: > > > Hi, > > > > I have read through the proposal, but there is something I am > still unsure > > of. For the LANGUAGE pragma's is there any utility in using one > separately > > form the other? It seems there isn't. In any one file you would > use either > > one or the other. > > > > Thanks, > > Erik > > > > Arnaud Spiwack wrote: > > > > > Sorry I disappeared for a while. I second Simon's call, let's > vote. Let me > > > repost a link to Simon's pro and cons post > > > > [2][11]https://github.com/ghc-proposals/ghc-proposals/pull/682#issue comm > ent-2609199731 > > > > > > So far, we have the following votes > > > > > > - Simon: 1 extension > > > - Adam: 2 extension (feels quite strongly about it) > > > - Sebastian: 1 extension (on the Github thread, but I'll count > it as a vote > > > anyway) > > > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > > > --- > > > > > > Beyond that we have a single piece of community feedback on the > Github > > > thread. It's from Michael Peyton Jones who is in favour of 2 > extensions, > > > find it here > > > > [3][12]https://github.com/ghc-proposals/ghc-proposals/pull/682#issue comm > ent-2609583126 > > > > > > --- > > > > > > For the record, I hadn't commented about it in my > recommendation, despite > > > my well-known and desperately public distaste for micro > extensions. I have > > > a couple of reasons: > > > - I dislike micro-extensions less now that we are doing the > GHC20XX (the > > > last one was very modest, I'm in favour, by the way, of doing a > much more > > > ambitious language edition soon, otherwise my distaste will come > back with > > > a vengeance) > > > - While I consider every proposal with several extensions in it > with > > > suspicion, the authors did argue for their second extension, I > found the > > > argument mildly convincing, and thought it wasn't worth fighting > against. > > > > > > Now, even like this my preference is mildly for one extension. > Adam says > > > that it's easier to implement warnings with both the new syntax > on and > > > implicit stage persistence left turned on, than to implement > errors when > > > implicit stage persistence is turned off. It may be so, but I > don't think > > > we can avoid implementing the errors anyway, so I don't feel > that it's a > > > particularly compelling argument. I don't feel strongly. But > that's > > > presumably where my vote goes. > > > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > <[4][13]simon.peytonjones@gmail.com> > > > wrote: > > > > > > > Yes: all members of the steering committee, please vote. > Evaluating > > > > proposals is what we all signed up to do! > > > > > > > > Thanks > > > > > > > > Simon > > > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry > <[5][14]adam@well-typed.com> wrote: > > > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for > two > > > >> extensions. As I commented on the GitHub thread: > > > >> > > > >> > We shouldn't unnecessarily conflate a syntactic extension > > > >> (ExplicitLevelImports) with a semantic one > (NoImplicitStagePersistence) > > > >> just because the common case is to want both and we want to > keep the > > > >> number of extensions lower. > > > >> > > > >> If there are reasons why having two extensions is actually > problematic, > > > >> I'd like to hear them. > > > >> > > > >> Also, at the risk of opening another avenue of discussion, we > also need > > > >> to resolve the syntax question (see > > > >> > > > >> > [6][15]https://github.com/ghc-proposals/ghc-proposals/pull/682#discu ssio > n_r1849123243). > > > >> > > > >> I don't have a very strong opinion here, but given that some > people do, > > > >> perhaps we should make ImportQualifiedPost affect splice > imports so we > > > >> have > > > >> > > > >> import splice qualified A -- By default > > > >> import A splice qualified -- Under ImportQualifiedPost > > > >> > > > >> In any case, please do vote! It would be good to get this > proposal done. > > > >> > > > >> Cheers, > > > >> > > > >> Adam > > > >> > > > >> > > > >> > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > > >> > Arnaud > > > >> > > > > >> > OK, following my call and some further iteration, the > proposal is much > > > >> > improved. See here > > > >> > > <[7][16]https://github.com/ghc-proposals/ghc-proposals/pull/682>. > Please > > > >> read > > > >> > the new "Proposed Change Specification" which has had a > large rewrite. > > > >> > > > > >> > I vote to accept. > > > >> > > > > >> > BUT there is one point that the committee must resolve: > *one extension > > > >> > of two?* It's just a judgement call and I lay out the > choices in this > > > >> > post > > > >> > < > > > >> > [8][17]https://github.com/ghc-proposals/ghc-proposals/pull/682#issue comm > ent-2609199731>. > > > >> I doubt that we'll get much community feedback. I suggest > that we just > > > >> vote. I vote for one, not two. As does Sebastian. > > > >> > > > > >> > Over to you Arnaud. Let's get this one done. Matthew is > busy > > > >> > implementing it for a customer and it has been on our to-do > list for > > > >> > some time now. (Partly my fault.) > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > > >> > <[9][18]simon.peytonjones@gmail.com > <mailto:[10][19]simon.peytonjones@gmail.com>> > > > >> wrote: > > > >> > > > > >> > Matthew and I had a good conversation. Some notes here > > > >> > < > > > >> > [11][20]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQ R58R > Phk5MslruY7yXD0/edit?usp=sharing > > > >> >. > > > >> > > > > >> > He's going to work on a revision to the proposal which > I'll iterate > > > >> > with him. > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > > >> > <[12][21]arnaud.spiwack@tweag.io > <mailto:[13][22]arnaud.spiwack@tweag.io>> wrote: > > > >> > > > > >> > Then, let's wait until your call with Matthew and > decide how to > > > >> > act then. > > > >> > > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > > >> > <[14][23]simon.peytonjones@gmail.com > > > >> > <mailto:[15][24]simon.peytonjones@gmail.com>> wrote: > > > >> > > > > >> > Arnaud > > > >> > > > > >> > I have responded with a lot of feedback on the > Github thread > > > >> > < > > > >> > [16][25]https://github.com/ghc-proposals/ghc-proposals/pull/682#pull requ > estreview-2562175116 > > > >> >. > > > >> > > > > >> > TL:DR: I like the direction of travel but have > too many > > > >> > questions of detail to be ready to accept it > just yet. > > > >> > > > > >> > I have arranged a call with Matthew. > > > >> > > > > >> > Simon > > > >> > > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > > > >> > <[17][26]arnaud.spiwack@tweag.io > <mailto:[18][27]arnaud.spiwack@tweag.io>> > > > >> > wrote: > > > >> > > > > >> > > > > >> > Mathew Pickering, Rodrigo Mesquita, and our > own Adam > > > >> > Gundry put forward a new proposal for the > perenial > > > >> > problem of dependencies and Template > Haskell > > > >> > > [19][28]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > >> > < > > > >> [20][29]https://github.com/ghc-proposals/ghc-proposals/pull/682> > > > >> > > > > >> > I've got to be honest, I'm not fully > convinced by the > > > >> > proposal. More on that in a minute, but it > learns a > > > >> > lesson from previous attempts at the same > problem by > > > >> > solving the absolute minimal problem, but > this leads to > > > >> > a somewhat fork-like situation for which it > isn't clear > > > >> > whether it will be resolved in the future. > That being > > > >> > said, it solves a real problem which has > plagued GHC > > > >> > compilation forever. And I'm inclined to > believe that we > > > >> > can't really do much better. > > > >> > > > > >> > But I'm getting ahead of myself. The > problem is that > > > >> > when you have -XTemplateHaskell in a file, > all the > > > >> > dependencies' compiled code must suddenly > be available > > > >> > for typechecking. This breaks `-fno-code` > and wounds > > > >> > recompilation avoidance. This is probably > the main > > > >> > reason why it's a widely held belief that > Template > > > >> > Haskell is slow: you use Template Haskell > in a few > > > >> > modules, and suddenly your IDE is much less > responsive > > > >> > and you recompile more files. Yay? > > > >> > > > > >> > Anyway, the general gist of the solution is > clear: we > > > >> > must be able to specify that we don't want > to import a > > > >> > module for Template Haskell (there is > subtleties in this > > > >> > too as you will want a little more control > than that for > > > >> > cross-compilation reasons which I'm not > competent about > > > >> > to comment on). But the devil is in the > many details. > > > >> > There's this thing called implicit > cross-stage > > > >> > persistence which says that anything you > import > > > >> > not-for-template-haskell is going to be > available in > > > >> > quotes and splices anyway. Sigh… So you > have to turn > > > >> > this off. This is what the proposal does. > And pretty > > > >> > much only. > > > >> > > > > >> > 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. > > > >> > > > > >> > For these situations, the proposal kind of > advertises > > > >> > using `-XImplicitStagePersistence`. Which > does seem like > > > >> > a fork-like situation to me. Not cool. Yet… > yet Template > > > >> > Haskell is a big messy ball of yarn, and I > don't think > > > >> > it's fair to ask of any proposal to > entangle it > > > >> > completely. The failure of past attempts > seem to support > > > >> > this case. And I believe the authors are > correct when > > > >> > they claim that this proposal, in practice, > covers a > > > >> > vast majority of the uses of Template > Haskell out there. > > > >> > So maybe we can see that as a new > foundation for > > > >> > Template Haskell. I'm not thrilled about > it, but it's > > > >> > probably the most reasonable way forward. > > > >> > > > > >> > The real problem with this sort of proposal > is that then > > > >> > I get to write way too long an email to the > committee. > > > >> > Hopefully this didn't deter you. Read the > proposal, and > > > >> > let's vote. > > > >> > > > > >> > -- > > > >> > Arnaud Spiwack > > > >> > Director, Research at > [21][30]https://moduscreate.com > > > >> > <[22][31]https://moduscreate.com> and > [23][32]https://tweag.io > > > >> > <[24][33]https://tweag.io>. > > > >> > > > >> > > > >> -- > > > >> Adam Gundry, Haskell Consultant > > > >> Well-Typed LLP, [25][34]https://www.well-typed.com/ > > > >> > > > >> Registered in England & Wales, OC335890 > > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > > >> > > > >> _______________________________________________ > > > >> ghc-steering-committee mailing list > > > >> [26][35]ghc-steering-committee@haskell.org > > > >> > [27][36]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri ng-c > ommittee > > > >> > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > [28][37]ghc-steering-committee@haskell.org > > > > > [29][38]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri ng-c > ommittee > > > > > > > > > > > > > -- > > > Arnaud Spiwack > > > Director, Research at [30][39]https://moduscreate.com and > [31][40]https://tweag.io. > > > > > > -- > > > -------------------------------------------------------------------- > -- > > Erik de Castro Lopo > > [32][41]http://www.mega-nerd.com/ > > > > -- > -------------------------------------------------------------------- > -- > Erik de Castro Lopo > [33][42]http://www.mega-nerd.com/ > _______________________________________________ > ghc-steering-committee mailing list > [34][43]ghc-steering-committee@haskell.org > [35][44]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri ng-c > ommittee > > -- > > Arnaud Spiwack > Director, Research at [36][45]https://moduscreate.com and > [37][46]https://tweag.io. > > References > > 1. mailto:[47]erikd@mega-nerd.com > 2. [48]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom ment-2609199731 > 3. [49]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom ment-2609583126 > 4. mailto:[50]simon.peytonjones@gmail.com > 5. mailto:[51]adam@well-typed.com > 6. [52]https://github.com/ghc-proposals/ghc-proposals/pull/682#discussi on_r1849123243 > 7. [53]https://github.com/ghc-proposals/ghc-proposals/pull/682 > 8. [54]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom ment-2609199731 > 9. mailto:[55]simon.peytonjones@gmail.com > 10. mailto:[56]simon.peytonjones@gmail.com > 11. [57]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R Phk5MslruY7yXD0/edit?usp=sharing > 12. mailto:[58]arnaud.spiwack@tweag.io > 13. mailto:[59]arnaud.spiwack@tweag.io > 14. mailto:[60]simon.peytonjones@gmail.com > 15. mailto:[61]simon.peytonjones@gmail.com > 16. [62]https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ estreview-2562175116 > 17. mailto:[63]arnaud.spiwack@tweag.io > 18. mailto:[64]arnaud.spiwack@tweag.io > 19. [65]https://github.com/ghc-proposals/ghc-proposals/pull/682 > 20. [66]https://github.com/ghc-proposals/ghc-proposals/pull/682 > 21. [67]https://moduscreate.com/ > 22. [68]https://moduscreate.com/ > 23. [69]https://tweag.io/ > 24. [70]https://tweag.io/ > 25. [71]https://www.well-typed.com/ > 26. mailto:[72]ghc-steering-committee@haskell.org > 27. [73]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > 28. mailto:[74]ghc-steering-committee@haskell.org > 29. [75]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > 30. [76]https://moduscreate.com/ > 31. [77]https://tweag.io/ > 32. [78]http://www.mega-nerd.com/ > 33. [79]http://www.mega-nerd.com/ > 34. mailto:[80]ghc-steering-committee@haskell.org > 35. [81]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > 36. [82]https://moduscreate.com/ > 37. [83]https://tweag.io/
> _______________________________________________ > ghc-steering-committee mailing list > [84]ghc-steering-committee@haskell.org > [85]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
_______________________________________________ ghc-steering-committee mailing list [86]ghc-steering-committee@haskell.org [87]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
_______________________________________________ ghc-steering-committee mailing list [88]ghc-steering-committee@haskell.org [89]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
-- Arnaud Spiwack Director, Research at [90]https://moduscreate.com and [91]https://tweag.io.
--
Arnaud Spiwack Director, Research at [92]https://moduscreate.com and [93]https://tweag.io.
--
Arnaud Spiwack Director, Research at [94]https://moduscreate.com and [95]https://tweag.io.
-- Arnaud Spiwack Director, Research at [96]https://moduscreate.com and [97]https://tweag.io.
References
1. mailto:simon.peytonjones@gmail.com 2. mailto:arnaud.spiwack@tweag.io 3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558... 4. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436... 5. mailto:arnaud.spiwack@tweag.io 6. mailto:arnaud.spiwack@tweag.io 7. https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/prop... 8. mailto:simon.peytonjones@gmail.com 9. mailto:malte.ott@maralorn.de 10. mailto:erikd@mega-nerd.com 11. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm 12. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm 13. mailto:simon.peytonjones@gmail.com 14. mailto:adam@well-typed.com 15. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio 16. https://github.com/ghc-proposals/ghc-proposals/pull/682 17. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm 18. mailto:simon.peytonjones@gmail.com 19. mailto:simon.peytonjones@gmail.com 20. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R 21. mailto:arnaud.spiwack@tweag.io 22. mailto:arnaud.spiwack@tweag.io 23. mailto:simon.peytonjones@gmail.com 24. mailto:simon.peytonjones@gmail.com 25. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ 26. mailto:arnaud.spiwack@tweag.io 27. mailto:arnaud.spiwack@tweag.io 28. https://github.com/ghc-proposals/ghc-proposals/pull/682 29. https://github.com/ghc-proposals/ghc-proposals/pull/682 30. https://moduscreate.com/ 31. https://moduscreate.com/ 32. https://tweag.io/ 33. https://tweag.io/ 34. https://www.well-typed.com/ 35. mailto:ghc-steering-committee@haskell.org 36. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c 37. mailto:ghc-steering-committee@haskell.org 38. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c 39. https://moduscreate.com/ 40. https://tweag.io/ 41. http://www.mega-nerd.com/ 42. http://www.mega-nerd.com/ 43. mailto:ghc-steering-committee@haskell.org 44. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c 45. https://moduscreate.com/ 46. https://tweag.io/ 47. mailto:erikd@mega-nerd.com 48. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 49. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... 50. mailto:simon.peytonjones@gmail.com 51. mailto:adam@well-typed.com 52. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... 53. https://github.com/ghc-proposals/ghc-proposals/pull/682 54. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 55. mailto:simon.peytonjones@gmail.com 56. mailto:simon.peytonjones@gmail.com 57. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... 58. mailto:arnaud.spiwack@tweag.io 59. mailto:arnaud.spiwack@tweag.io 60. mailto:simon.peytonjones@gmail.com 61. mailto:simon.peytonjones@gmail.com 62. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... 63. mailto:arnaud.spiwack@tweag.io 64. mailto:arnaud.spiwack@tweag.io 65. https://github.com/ghc-proposals/ghc-proposals/pull/682 66. https://github.com/ghc-proposals/ghc-proposals/pull/682 67. https://moduscreate.com/ 68. https://moduscreate.com/ 69. https://tweag.io/ 70. https://tweag.io/ 71. https://www.well-typed.com/ 72. mailto:ghc-steering-committee@haskell.org 73. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 74. mailto:ghc-steering-committee@haskell.org 75. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 76. https://moduscreate.com/ 77. https://tweag.io/ 78. http://www.mega-nerd.com/ 79. http://www.mega-nerd.com/ 80. mailto:ghc-steering-committee@haskell.org 81. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 82. https://moduscreate.com/ 83. https://tweag.io/ 84. mailto:ghc-steering-committee@haskell.org 85. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 86. mailto:ghc-steering-committee@haskell.org 87. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 88. mailto:ghc-steering-committee@haskell.org 89. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 90. https://moduscreate.com/ 91. https://tweag.io/ 92. https://moduscreate.com/ 93. https://tweag.io/ 94. https://moduscreate.com/ 95. https://tweag.io/ 96. https://moduscreate.com/ 97. https://tweag.io/
My dream would be to rename ImportQualifiedPost to ImportAnnotationsPost or something similar and then treat splice exactly as qualified. Seeing that that’s much too much trouble I would consider doing that but not changing the extension name.
(aside: with ImportQualifiedPost turned, both the `qualified` keyword before and the `qualified` keyword after are accepted). --- Nobody seems to have an opinion. Owing to various illnesses traversing my households (and my lungs…) this week, I let that slide a bit longer than I wanted. But anyway. I'll interpret silence as assent, and mark the proposal as accepted. We've waited too long already. On Mon, 3 Mar 2025 at 19:03, Malte Ott <malte.ott@maralorn.de> wrote:
I for my part are kinda dissatisfied by both options. And I am very much sympathetic to the position that a committee shouldn’t settle alternatives by allowing all of them. That being said I am still in favor of leaving the proposal like it is now, which is (B).
My dream would be to rename ImportQualifiedPost to ImportAnnotationsPost or something similar and then treat splice exactly as qualified. Seeing that that’s much too much trouble I would consider doing that but not changing the extension name.
I can also see the reasoning that we should just go with (A) now without blocking the proposal any longer because it will always be possible to convert it to (B) later.
Best Malte
On 2025-03-03 15:52, Arnaud Spiwack wrote:
There may have been delivery issues last week to the committee mailing list. Did everybody get this email by Simon and mine below?
On Fri, 21 Feb 2025 at 17:23, Simon Peyton Jones <[1]simon.peytonjones@gmail.com> wrote:
Syntax is always troublesome, and best resolved by a vote. I think you are asking us to vote on: * (A) splice/quote keywords only before the module name * (B) splice/quote keywords either before or after the module name
I vote (A). My opinion is not a strong one. Let's see what other committee members think. RSVP
Simon
On Fri, 21 Feb 2025 at 07:17, Arnaud Spiwack <[2]arnaud.spiwack@tweag.io> wrote:
So, let me recap the situation.
The authors favourite syntax is `import splice A` `import quote B`
But some community members in the thread (most vocally Matt Parsons, e.g. here [3] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment -2651558160 ) feel that there should be more options, that is that all of `import splice A` / `import A splice` `import quote B` / `import A quote`
Be available, lest people prefer the right-hand positions and do a proposal to add an extra extension later.
The authors are ok (but evidently not ecstatic [4] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment -2671436455 ) with allowing both positions for their keyword. It turns out not to be too big of a hassle to implement. Which I propose to be the resolution. Very non-committal on our part, but because it isn't costly, we might as well.
This hasn't been a very busy thread, so… let me backtrack: I'll be on holiday next week, so I'll accept the changes as I'm back, this means that you have one week to disagree. Now, this hasn't been a very busy thread so I expect nobody has strong opinions. But, let me propose a protocol. If (and only if) someone is of the strong opinion that only in front is a much better solution. Let them state “I strongly think that `import splice A` should be the only syntax`. One of us says that, let each of you vote, I'll tally the vote when I'm back.
PS: I'm excluding only `import A splice` as an option because the authors don't want that and it would require an overwhelming majority to force that on the authors, which evidently doesn't exist, so let's not muddy the water. So the two options are “only in front” and “both position”
Speak to you all in a week, Arnaud
On Fri, 14 Feb 2025 at 14:19, Arnaud Spiwack <[5]arnaud.spiwack@tweag.io> wrote:
There's a little bit of a debate going on in the Github thread on the topic of syntax. I'll give this one one last push. If the authors decide that they are ok with specifying the keywords before and after the module name, then we can accept immediately, as there's no voice against this. Otherwise I'll recapitulate everybody's argument here and call for a quick vote.
On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack <[6]arnaud.spiwack@tweag.io> wrote:
For the record, the syntactic alternatives can be found in [§8.5 Syntactic alternatives]([7] https://github.com/well-typed/ghc-proposals/blob/wip/l
evel-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternati
ves)
Malte seems to be uncomfortable with the fact that the proposed syntax is
import slice Foo import quote Bar
Even when ImportQualifiedPost, which enables the syntax
import Foo qualified [as …]
is enabled.
The proposal offers alternative syntaxes like
import Foo slice Import Bar quote
or (to sound more English)
import Foo for slice import Bar for quote
Richard Eisenberg, in the thread, suggests that the motivation for ImportQualifiedPost doesn't apply to slice/quote because he believes that there's going to be one block of import slice, one block of import (nothing), one block of import quote, and they aren't going to be mixed together. Them being more visually distinguished by starting with the keyword is an asset in this view. Many seem convinced
My understanding of Malte's point is that this is not intuitive enough that it can be left implicit in the proposal, and he'd like the proposal to at least state explicitly that it ignores ImportQualifiedPost.
Malte, let me know if I misrepresent your point of view (or anybody else's).
On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones <[8]simon.peytonjones@gmail.com> wrote:
I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
OK -- but I suspect that most of us have lost context.
Would you like to post (on the Github) a message explaining: * what the syntactic alternatives are * what you recommend
That will help to focus the discussion
Thanks!
Simon
On Fri, 7 Feb 2025 at 12:16, Malte Ott <[9]malte.ott@maralorn.de> wrote:
I do not object to accepting the proposal, but I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread.
I know we all dread wasting our time with syntax discussions but lets at least think about it for 5 minutes.
Best, Malte
On 2025-02-07 15:48, Arnaud Spiwack wrote: > Ok, we have enough of a quorum at this point. If everybody else voted 1 > extension this would come at a rough draw. It can't be a strong enough > push to overrule the preference of the authors. > > I'll give it a handful more day, say until next Wednesday 12th > February. If someone has a strong objection, please voice it very > loudly. Otherwise I'll declare the proposal as accepted in its current > state. > > Best, > Arnaud > > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo > <[1][10]erikd@mega-nerd.com> wrote: > > OK, slightly in favor of two extensions. > > Erik > > Erik de Castro Lopo wrote: > > > Hi, > > > > I have read through the proposal, but there is something I am > still unsure > > of. For the LANGUAGE pragma's is there any utility in using one > separately > > form the other? It seems there isn't. In any one file you would > use either > > one or the other. > > > > Thanks, > > Erik > > > > Arnaud Spiwack wrote: > > > > > Sorry I disappeared for a while. I second Simon's call, let's > vote. Let me > > > repost a link to Simon's pro and cons post > > > > [2][11] https://github.com/ghc-proposals/ghc-proposals/pull/682#issue comm > ent-2609199731 > > > > > > So far, we have the following votes > > > > > > - Simon: 1 extension > > > - Adam: 2 extension (feels quite strongly about it) > > > - Sebastian: 1 extension (on the Github thread, but I'll count > it as a vote > > > anyway) > > > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > > > --- > > > > > > Beyond that we have a single piece of community feedback on the > Github > > > thread. It's from Michael Peyton Jones who is in favour of 2 > extensions, > > > find it here > > > > [3][12] https://github.com/ghc-proposals/ghc-proposals/pull/682#issue comm > ent-2609583126 > > > > > > --- > > > > > > For the record, I hadn't commented about it in my > recommendation, despite > > > my well-known and desperately public distaste for micro > extensions. I have > > > a couple of reasons: > > > - I dislike micro-extensions less now that we are doing the > GHC20XX (the > > > last one was very modest, I'm in favour, by the way, of doing a > much more > > > ambitious language edition soon, otherwise my distaste will come > back with > > > a vengeance) > > > - While I consider every proposal with several extensions in it > with > > > suspicion, the authors did argue for their second extension, I > found the > > > argument mildly convincing, and thought it wasn't worth fighting > against. > > > > > > Now, even like this my preference is mildly for one extension. > Adam says > > > that it's easier to implement warnings with both the new syntax > on and > > > implicit stage persistence left turned on, than to implement > errors when > > > implicit stage persistence is turned off. It may be so, but I > don't think > > > we can avoid implementing the errors anyway, so I don't feel > that it's a > > > particularly compelling argument. I don't feel strongly. But > that's > > > presumably where my vote goes. > > > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > <[4][13]simon.peytonjones@gmail.com> > > > wrote: > > > > > > > Yes: all members of the steering committee, please vote. > Evaluating > > > > proposals is what we all signed up to do! > > > > > > > > Thanks > > > > > > > > Simon > > > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry > <[5][14]adam@well-typed.com> wrote: > > > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for > two > > > >> extensions. As I commented on the GitHub thread: > > > >> > > > >> > We shouldn't unnecessarily conflate a syntactic extension > > > >> (ExplicitLevelImports) with a semantic one > (NoImplicitStagePersistence) > > > >> just because the common case is to want both and we want to > keep the > > > >> number of extensions lower. > > > >> > > > >> If there are reasons why having two extensions is actually > problematic, > > > >> I'd like to hear them. > > > >> > > > >> Also, at the risk of opening another avenue of discussion, we > also need > > > >> to resolve the syntax question (see > > > >> > > > >> > [6][15] https://github.com/ghc-proposals/ghc-proposals/pull/682#discu ssio > n_r1849123243). > > > >> > > > >> I don't have a very strong opinion here, but given that some > people do, > > > >> perhaps we should make ImportQualifiedPost affect splice > imports so we > > > >> have > > > >> > > > >> import splice qualified A -- By default > > > >> import A splice qualified -- Under ImportQualifiedPost > > > >> > > > >> In any case, please do vote! It would be good to get this > proposal done. > > > >> > > > >> Cheers, > > > >> > > > >> Adam > > > >> > > > >> > > > >> > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > > >> > Arnaud > > > >> > > > > >> > OK, following my call and some further iteration, the > proposal is much > > > >> > improved. See here > > > >> > > <[7][16]https://github.com/ghc-proposals/ghc-proposals/pull/682>. > Please > > > >> read > > > >> > the new "Proposed Change Specification" which has had a > large rewrite. > > > >> > > > > >> > I vote to accept. > > > >> > > > > >> > BUT there is one point that the committee must resolve: > *one extension > > > >> > of two?* It's just a judgement call and I lay out the > choices in this > > > >> > post > > > >> > < > > > >> > [8][17] https://github.com/ghc-proposals/ghc-proposals/pull/682#issue comm > ent-2609199731>. > > > >> I doubt that we'll get much community feedback. I suggest > that we just > > > >> vote. I vote for one, not two. As does Sebastian. > > > >> > > > > >> > Over to you Arnaud. Let's get this one done. Matthew is > busy > > > >> > implementing it for a customer and it has been on our to-do > list for > > > >> > some time now. (Partly my fault.) > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > > >> > <[9][18]simon.peytonjones@gmail.com > <mailto:[10][19]simon.peytonjones@gmail.com>> > > > >> wrote: > > > >> > > > > >> > Matthew and I had a good conversation. Some notes here > > > >> > < > > > >> > [11][20] https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQ R58R > Phk5MslruY7yXD0/edit?usp=sharing > > > >> >. > > > >> > > > > >> > He's going to work on a revision to the proposal which > I'll iterate > > > >> > with him. > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > > >> > <[12][21]arnaud.spiwack@tweag.io > <mailto:[13][22]arnaud.spiwack@tweag.io>> wrote: > > > >> > > > > >> > Then, let's wait until your call with Matthew and > decide how to > > > >> > act then. > > > >> > > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > > >> > <[14][23]simon.peytonjones@gmail.com > > > >> > <mailto:[15][24]simon.peytonjones@gmail.com>> wrote: > > > >> > > > > >> > Arnaud > > > >> > > > > >> > I have responded with a lot of feedback on the > Github thread > > > >> > < > > > >> > [16][25] https://github.com/ghc-proposals/ghc-proposals/pull/682#pull requ > estreview-2562175116 > > > >> >. > > > >> > > > > >> > TL:DR: I like the direction of travel but have > too many > > > >> > questions of detail to be ready to accept it > just yet. > > > >> > > > > >> > I have arranged a call with Matthew. > > > >> > > > > >> > Simon > > > >> > > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack > > > >> > <[17][26]arnaud.spiwack@tweag.io > <mailto:[18][27]arnaud.spiwack@tweag.io>> > > > >> > wrote: > > > >> > > > > >> > > > > >> > Mathew Pickering, Rodrigo Mesquita, and our > own Adam > > > >> > Gundry put forward a new proposal for the > perenial > > > >> > problem of dependencies and Template > Haskell > > > >> > > [19][28]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > >> > < > > > >> [20][29]https://github.com/ghc-proposals/ghc-proposals/pull/682> > > > >> > > > > >> > I've got to be honest, I'm not fully > convinced by the > > > >> > proposal. More on that in a minute, but it > learns a > > > >> > lesson from previous attempts at the same > problem by > > > >> > solving the absolute minimal problem, but > this leads to > > > >> > a somewhat fork-like situation for which it > isn't clear > > > >> > whether it will be resolved in the future. > That being > > > >> > said, it solves a real problem which has > plagued GHC > > > >> > compilation forever. And I'm inclined to > believe that we > > > >> > can't really do much better. > > > >> > > > > >> > But I'm getting ahead of myself. The > problem is that > > > >> > when you have -XTemplateHaskell in a file, > all the > > > >> > dependencies' compiled code must suddenly > be available > > > >> > for typechecking. This breaks `-fno-code` > and wounds > > > >> > recompilation avoidance. This is probably > the main > > > >> > reason why it's a widely held belief that > Template > > > >> > Haskell is slow: you use Template Haskell > in a few > > > >> > modules, and suddenly your IDE is much less > responsive > > > >> > and you recompile more files. Yay? > > > >> > > > > >> > Anyway, the general gist of the solution is > clear: we > > > >> > must be able to specify that we don't want > to import a > > > >> > module for Template Haskell (there is > subtleties in this > > > >> > too as you will want a little more control > than that for > > > >> > cross-compilation reasons which I'm not > competent about > > > >> > to comment on). But the devil is in the > many details. > > > >> > There's this thing called implicit > cross-stage > > > >> > persistence which says that anything you > import > > > >> > not-for-template-haskell is going to be > available in > > > >> > quotes and splices anyway. Sigh… So you > have to turn > > > >> > this off. This is what the proposal does. > And pretty > > > >> > much only. > > > >> > > > > >> > 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. > > > >> > > > > >> > For these situations, the proposal kind of > advertises > > > >> > using `-XImplicitStagePersistence`. Which > does seem like > > > >> > a fork-like situation to me. Not cool. Yet… > yet Template > > > >> > Haskell is a big messy ball of yarn, and I > don't think > > > >> > it's fair to ask of any proposal to > entangle it > > > >> > completely. The failure of past attempts > seem to support > > > >> > this case. And I believe the authors are > correct when > > > >> > they claim that this proposal, in practice, > covers a > > > >> > vast majority of the uses of Template > Haskell out there. > > > >> > So maybe we can see that as a new > foundation for > > > >> > Template Haskell. I'm not thrilled about > it, but it's > > > >> > probably the most reasonable way forward. > > > >> > > > > >> > The real problem with this sort of proposal > is that then > > > >> > I get to write way too long an email to the > committee. > > > >> > Hopefully this didn't deter you. Read the > proposal, and > > > >> > let's vote. > > > >> > > > > >> > -- > > > >> > Arnaud Spiwack > > > >> > Director, Research at > [21][30]https://moduscreate.com > > > >> > <[22][31]https://moduscreate.com> and > [23][32]https://tweag.io > > > >> > <[24][33]https://tweag.io>. > > > >> > > > >> > > > >> -- > > > >> Adam Gundry, Haskell Consultant > > > >> Well-Typed LLP, [25][34]https://www.well-typed.com/ > > > >> > > > >> Registered in England & Wales, OC335890 > > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > > >> > > > >> _______________________________________________ > > > >> ghc-steering-committee mailing list > > > >> [26][35]ghc-steering-committee@haskell.org > > > >> > [27][36] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri ng-c > ommittee > > > >> > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > [28][37]ghc-steering-committee@haskell.org > > > > > [29][38] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri ng-c > ommittee > > > > > > > > > > > > > -- > > > Arnaud Spiwack > > > Director, Research at [30][39]https://moduscreate.com and > [31][40]https://tweag.io. > > > > > > -- > > > -------------------------------------------------------------------- > -- > > Erik de Castro Lopo > > [32][41]http://www.mega-nerd.com/ > > > > -- > -------------------------------------------------------------------- > -- > Erik de Castro Lopo > [33][42]http://www.mega-nerd.com/ > _______________________________________________ > ghc-steering-committee mailing list > [34][43]ghc-steering-committee@haskell.org > [35][44] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri ng-c > ommittee > > -- > > Arnaud Spiwack > Director, Research at [36][45]https://moduscreate.com and > [37][46]https://tweag.io. > > References > > 1. mailto:[47]erikd@mega-nerd.com > 2. [48] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom ment-2609199731 > 3. [49] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom ment-2609583126 > 4. mailto:[50]simon.peytonjones@gmail.com > 5. mailto:[51]adam@well-typed.com > 6. [52] https://github.com/ghc-proposals/ghc-proposals/pull/682#discussi on_r1849123243 > 7. [53]https://github.com/ghc-proposals/ghc-proposals/pull/682 > 8. [54] https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom ment-2609199731 > 9. mailto:[55]simon.peytonjones@gmail.com > 10. mailto:[56]simon.peytonjones@gmail.com > 11. [57] https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R Phk5MslruY7yXD0/edit?usp=sharing > 12. mailto:[58]arnaud.spiwack@tweag.io > 13. mailto:[59]arnaud.spiwack@tweag.io > 14. mailto:[60]simon.peytonjones@gmail.com > 15. mailto:[61]simon.peytonjones@gmail.com > 16. [62] https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ estreview-2562175116 > 17. mailto:[63]arnaud.spiwack@tweag.io > 18. mailto:[64]arnaud.spiwack@tweag.io > 19. [65]https://github.com/ghc-proposals/ghc-proposals/pull/682 > 20. [66]https://github.com/ghc-proposals/ghc-proposals/pull/682 > 21. [67]https://moduscreate.com/ > 22. [68]https://moduscreate.com/ > 23. [69]https://tweag.io/ > 24. [70]https://tweag.io/ > 25. [71]https://www.well-typed.com/ > 26. mailto:[72]ghc-steering-committee@haskell.org > 27. [73] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > 28. mailto:[74]ghc-steering-committee@haskell.org > 29. [75] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > 30. [76]https://moduscreate.com/ > 31. [77]https://tweag.io/ > 32. [78]http://www.mega-nerd.com/ > 33. [79]http://www.mega-nerd.com/ > 34. mailto:[80]ghc-steering-committee@haskell.org > 35. [81] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > 36. [82]https://moduscreate.com/ > 37. [83]https://tweag.io/
> _______________________________________________ > ghc-steering-committee mailing list > [84]ghc-steering-committee@haskell.org > [85] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
_______________________________________________ ghc-steering-committee mailing list [86]ghc-steering-committee@haskell.org [87] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
_______________________________________________ ghc-steering-committee mailing list [88]ghc-steering-committee@haskell.org [89] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
-- Arnaud Spiwack Director, Research at [90]https://moduscreate.com and [91]https://tweag.io.
--
Arnaud Spiwack Director, Research at [92]https://moduscreate.com and [93]https://tweag.io.
--
Arnaud Spiwack Director, Research at [94]https://moduscreate.com and [95]https://tweag.io.
-- Arnaud Spiwack Director, Research at [96]https://moduscreate.com and [97]https://tweag.io.
References
1. mailto:simon.peytonjones@gmail.com 2. mailto:arnaud.spiwack@tweag.io 3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558... 4. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436... 5. mailto:arnaud.spiwack@tweag.io 6. mailto:arnaud.spiwack@tweag.io 7. https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/prop... 8. mailto:simon.peytonjones@gmail.com 9. mailto:malte.ott@maralorn.de 10. mailto:erikd@mega-nerd.com 11. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm 12. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm 13. mailto:simon.peytonjones@gmail.com 14. mailto:adam@well-typed.com 15. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio 16. https://github.com/ghc-proposals/ghc-proposals/pull/682 17. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm 18. mailto:simon.peytonjones@gmail.com 19. mailto:simon.peytonjones@gmail.com 20. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R 21. mailto:arnaud.spiwack@tweag.io 22. mailto:arnaud.spiwack@tweag.io 23. mailto:simon.peytonjones@gmail.com 24. mailto:simon.peytonjones@gmail.com 25. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ 26. mailto:arnaud.spiwack@tweag.io 27. mailto:arnaud.spiwack@tweag.io 28. https://github.com/ghc-proposals/ghc-proposals/pull/682 29. https://github.com/ghc-proposals/ghc-proposals/pull/682 30. https://moduscreate.com/ 31. https://moduscreate.com/ 32. https://tweag.io/ 33. https://tweag.io/ 34. https://www.well-typed.com/ 35. mailto:ghc-steering-committee@haskell.org 36. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c 37. mailto:ghc-steering-committee@haskell.org 38. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c 39. https://moduscreate.com/ 40. https://tweag.io/ 41. http://www.mega-nerd.com/ 42. http://www.mega-nerd.com/ 43. mailto:ghc-steering-committee@haskell.org 44. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c 45. https://moduscreate.com/ 46. https://tweag.io/ 47. mailto:erikd@mega-nerd.com 48. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 49. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... 50. mailto:simon.peytonjones@gmail.com 51. mailto:adam@well-typed.com 52. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... 53. https://github.com/ghc-proposals/ghc-proposals/pull/682 54. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 55. mailto:simon.peytonjones@gmail.com 56. mailto:simon.peytonjones@gmail.com 57. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... 58. mailto:arnaud.spiwack@tweag.io 59. mailto:arnaud.spiwack@tweag.io 60. mailto:simon.peytonjones@gmail.com 61. mailto:simon.peytonjones@gmail.com 62. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... 63. mailto:arnaud.spiwack@tweag.io 64. mailto:arnaud.spiwack@tweag.io 65. https://github.com/ghc-proposals/ghc-proposals/pull/682 66. https://github.com/ghc-proposals/ghc-proposals/pull/682 67. https://moduscreate.com/ 68. https://moduscreate.com/ 69. https://tweag.io/ 70. https://tweag.io/ 71. https://www.well-typed.com/ 72. mailto:ghc-steering-committee@haskell.org 73. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 74. mailto:ghc-steering-committee@haskell.org 75. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 76. https://moduscreate.com/ 77. https://tweag.io/ 78. http://www.mega-nerd.com/ 79. http://www.mega-nerd.com/ 80. mailto:ghc-steering-committee@haskell.org 81. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 82. https://moduscreate.com/ 83. https://tweag.io/ 84. mailto:ghc-steering-committee@haskell.org 85. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 86. mailto:ghc-steering-committee@haskell.org 87. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 88. mailto:ghc-steering-committee@haskell.org 89. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 90. https://moduscreate.com/ 91. https://tweag.io/ 92. https://moduscreate.com/ 93. https://tweag.io/ 94. https://moduscreate.com/ 95. https://tweag.io/ 96. https://moduscreate.com/ 97. https://tweag.io/
-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.
On 2025-03-06 21:55, Arnaud Spiwack wrote:
My dream would be to rename ImportQualifiedPost to ImportAnnotationsPost or something similar and then treat splice exactly as qualified. Seeing that that’s much too much trouble I would consider doing that but not changing the extension name.
(aside: with ImportQualifiedPost turned, both the `qualified` keyword before and the `qualified` keyword after are accepted).
Oh, thank you. And I see now that that it has to be that way since we enabled it with GHC2021. This makes me less sceptical about the proposed solution. Great, let’s accept it. Best Malte
I've just discovered that there were a bunch of messages to the mailing list regarding this proposal that were somehow not delivered to me. So apologies for my apparent silence on the syntax question! Regardless, I've marked this proposal as accepted at Arnaud's request (https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2703780...). Cheers, Adam On 09/01/2025 06:31, Arnaud Spiwack wrote:
Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682 <https://github.com/ghc-proposals/ghc-proposals/pull/682>
I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better.
But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay?
Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only.
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.
For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward.
The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote.
-- Arnaud Spiwack Director, Research at https://moduscreate.com <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
participants (9)
-
Adam Gundry -
Arnaud Spiwack -
Erik de Castro Lopo -
Malte Ott -
Matthías Páll Gissurarson -
Moritz Angermann -
Sebastian Graf -
Simon Marlow -
Simon Peyton Jones