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

[Sebastian Graf]

Hi,

I vote to accept this proposal.

I would have liked to see a clear specification of what gets compiled when
with -XImplicitStagePersistence, but I see that this isn't strictly
necessary to describe the extension in terms of the Haskell-the-language,
plus it's quite complicated. I attempted to do so at the end of this post
<https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2448500943>
.

I don't agree that -XNoImplicitStagePersistence is a fork. After all, users
are not forced to use `-XNoImplicitStagePersistence` just because one of
its imports uses it.

Cheers,
Sebastian

Am Fr., 10. Jan. 2025 um 12:20 Uhr schrieb Moritz Angermann <
moritz.angermann at gmail.com>:

> 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
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20250113/e57a136f/attachment.html>