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

Tue Jan 14 08:42:43 UTC 2025

Thanks. Indeed, considering -XNoImplicitStagePersistence a fork is
reasonable by that definition.

Although I guess I was having trouble with interpreting "most" and "happy"
in that statement of the first test...
I would think that "most" people do not write Template Haskell splice
functions or quote definitions (well, yet) in which case I don't think
their code would be affected at all and thus would be "happy" to activate
it.

Regardless, I think the benefits of this proposal far outweigh the mildly
forking behavior, which could be further remedied as per Adam's response.

Sebastian

Am Di., 14. Jan. 2025 um 08:42 Uhr schrieb Arnaud Spiwack <
arnaud.spiwack at tweag.io>:

> Sebastian writes:
>
> > 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.
>
> This isn't what we mean by forklike in our guidelines. We mean to avoid
> situations where the same code means different things depending on the
> extensions turned on and/or needing different modules having incompatible
> sets of extensions. Our README reads:
>
> By a "fork" we mean
>
>    - It fails the test "Is this extension something that most people
>    would be happy to enable, even if they don't want to use it?";
>    - And it also fails the test "Do we think there's a reasonable chance
>    this extension will make it into a future language standard?"; that is, the
>    proposal reflects the stylistic preferences of a subset of the Haskell
>    community, rather than a consensus about the direction that (in the
>    committee's judgement) we want to push the whole language.
>
> The idea is that unless we can see a path to a point where everyone has
> the extension turned on, we're left with different groups of people using
> incompatible dialects of the language. A similar problem arises with
> extensions that are mutually incompatible.
>
> I don't think this passes the first test, but it does pass the second
> (though that future is probably quite far!). And I think that the
> proposition that there's no way to make what we want of Template Haskell
> without breaking the first test is reasonable (see also Adam's email
> above). But still, this does create a forky situation for us, which I
> wouldn't be doing my job as a shepherd if I wasn't pointing it out.
> /Arnaud
>
> On Mon, 13 Jan 2025 at 22:31, Matthías Páll Gissurarson <mpg at mpg.is>
> wrote:
>
>> 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/>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20250114/e9845254/attachment.html>