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.