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

Mon Jan 13 13:30:51 UTC 2025

I vote accept.

The proposal itself is well written, and clarifies the concepts involved
and the issue at hand.

I am on the fence with the syntax itself. I like the one presented in the
proposal, it's very clean. I was a bit worried at first with having to
import the same module multiple times at different levels, but I guess that
cannot really be avoided.
I like Richard's comment on having different sections, a `splice` section,
a level 0 section and `quote` section. I'm also not against the `{-# SPLICE
#-}` syntax if we decide to go down that route, but it's a bit grittier
than the keywords.

On Mon, 13 Jan 2025 at 09:27, Sebastian Graf <sgraf1337 at gmail.com> wrote:

> 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
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

-- 
--  Matthías Páll Gissurarson <http://mpg.is/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20250113/cf0a0f5b/attachment.html>