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

[Erik de Castro Lopo]

Like Moritz, I am not a huge fan of TH, but do recognize its usefulness.
Any improvement to TH that impriove its clarity has my support.

+1

Cheers,
Erik


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 <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 <arnaud.spiwack at tweag.io
> > > <mailto: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, 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 at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >


-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/