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

21 Feb 2025

      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 
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 
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  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
...
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
On 2025-02-07 15:48, Arnaud Spiwack wrote:
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.