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

[Malte Ott]

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 at 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 at tweag.io
>      > <mailto:[3]arnaud.spiwack at 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 at haskell.org
>      [6]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-co
>      mmittee
> 
> References
> 
>    1. mailto:adam at well-typed.com
>    2. mailto:arnaud.spiwack at tweag.io
>    3. mailto:arnaud.spiwack at tweag.io
>    4. https://www.well-typed.com/
>    5. mailto:ghc-steering-committee at haskell.org
>    6. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee