Re: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept

7 Feb 2025

      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  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