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

7 Feb 2025

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

...
...
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
    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
        mailto:simon.peytonjones@gmail.com> wrote:
Arnaud
I have responded with a lot of feedback on the Github
...
...
...
...
<
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
            >
            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
...
...
...
...
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
...
...
...
...
can't really do much better.
But I'm getting ahead of myself. The problem is
...
...
...
...
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
...
...
...
...
cross-compilation reasons which I'm not competent
about
...
to comment on). But the devil is in the many
...
...
...
...
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
...
...
...
...
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
...
...
...
...
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
...
...
...
...
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
...
...
...
...
I get to write way too long an email to the
committee.
...
Hopefully this didn't deter you. Read the
despite
the
think
problematic,
this
thread
the
that we
that
that for
details.
pretty
think
there.
that then
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.