[ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept

Wed Jun 1 09:53:00 UTC 2022

Dear all,

I feel blocked here. I don't know how to make progress. Part of the goal of
this proposal is to elicit debate, and so far it has failed to.

Simon PJ says that the principles “bind us completely in future”. But I'd
argue that we still advertise them as desirable. Things we want to get
better at in the future. So a proposal saying “it makes GHC better at
the Contiguous
Scoping Principle” is well-justified enough. Is it what we want? That's the
question.

On Fri, Apr 22, 2022 at 8:37 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> Any other opinion? Only a few of us have participated in this thread: Tom,
> Joachim, Vlad, Eric, Chris, and Baldur, I'd love to hear from you. Do these
> principles make sense to you, or should they be rephrased? Do you agree
> with all of them?
>
> On Mon, Apr 18, 2022 at 9:51 AM Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I'm OK with them provided we do not get into later discussions like "this
>> proposal violates the X principle, so we should reject it".  The principles
>> doc says only "Proposals following these principles are more likely to be
>> accepted" which is fine.  I just don't want them to bind us completely in
>> future.
>>
>> I agree that having the principles gives a us a language and framework
>> for debate, and so is useful.
>>
>> Simon
>>
>> On Fri, 15 Apr 2022 at 15:01, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> Dear all,
>>>
>>> There has been no discussion of the principles so far. May I ask you
>>> what you think of the principles introduced by the proposal (I recommend
>>> reading the diff of `principles.rst` in raw form, the visual diff doesn't
>>> seem to work properly for me).
>>>
>>> Here is what I said about them in my initial email
>>>
>>> The proposal adds new principles to the `principles.rst` files which
>>>> inform the changes proposed, of these, I have the following comments:
>>>> - The Visibility Orthogonality Principle doesn't seem to have a very
>>>> clear definition. It may be a sign that it's not something that is so
>>>> important
>>>> - The Explicit Binding Principle says that we need to be able to
>>>> enforce that all type variables have a binding site. I think it's a bit
>>>> strong: I would like Haskell to let me write a binding site for every type
>>>> variable, but not necessarily to error out when that doesn't happen. That
>>>> being said, I'm happy with warnings to help me along the way, but I don't
>>>> think that this Explicit Binding Principle should be phrased in a way that
>>>> requires adding extensions to control this behaviour.
>>>> - The Contiguous Scoping Principle, which states that a binder binds
>>>> in one contiguous region sounds dubious to me. I don't see a particular
>>>> reason for this to be.
>>>>
>>>
>>> I think that the Explicit Binding Principle has implicitly been
>>> discussed in the thread about warnings above. There are other principles
>>> that Richard proposes, which I all find I agree with.
>>>
>>> Best,
>>> Arnaud
>>>
>>> On Tue, Apr 5, 2022 at 3:43 PM Simon Marlow <marlowsd at gmail.com> wrote:
>>>
>>>> That all sounds reasonable to me. I suggest:
>>>>
>>>> * Let's mention in the proposal that ExtendedForAllScope exists for
>>>> legacy reasons and that we intend to recommend TypeAbstractions as the
>>>> canonical way to bind type variables in the future (is that the right
>>>> wording? we're not ready to actually recommend it yet?).
>>>> * When this is implemented, let's have wording to the same effect in
>>>> the manual. Someone writing new code would want to know which way is likely
>>>> to be the more future-proof alternative.
>>>>
>>>> > Complicating this story is that some users (including me, at times)
>>>> wish for GHC to do less for us: we would prefer not to have implicit
>>>> foralls or to permit pattern-signature bindings. However, I suppose this
>>>> desire could be accommodated by warnings and -Werror instead of language
>>>> extensions.
>>>>
>>>> Definitely - warnings and/or HLint for stylistic choices is the right
>>>> way to do it.
>>>>
>>>> Cheers
>>>> Simon
>>>>
>>>> On Mon, 4 Apr 2022 at 21:15, Richard Eisenberg <lists at richarde.dev>
>>>> wrote:
>>>>
>>>>> Thanks for reminding us of that definition in our review criteria --
>>>>> it's helpful.
>>>>>
>>>>> I would say that every extension in this proposal fits the standard,
>>>>> except for ExtendedForAllScope. That is, I would be happy for the following
>>>>> extensions (as described in this proposal) to be part of a standard:
>>>>>  - PatternSignatures
>>>>>  - PatternSignatureBinds
>>>>>  - MethodTypeVariables (though John Ericson makes a comment on GitHub
>>>>> which suggests that this, too, may want revision -- I'm not fully convinced
>>>>> yet)
>>>>>  - ImplicitForAll
>>>>>  - TypeAbstractions
>>>>> (and ExtendedLet, but that's not being debated at the moment)
>>>>>
>>>>> Complicating this story is that some users (including me, at times)
>>>>> wish for GHC to do less for us: we would prefer not to have implicit
>>>>> foralls or to permit pattern-signature bindings. However, I suppose this
>>>>> desire could be accommodated by warnings and -Werror instead of language
>>>>> extensions.
>>>>>
>>>>> That logic might suggest revisiting #285 (which introduced
>>>>> NoImplicitForAll and NoPatternSignatureBinds), instead wishing for these to
>>>>> become warnings, rather than language extensions. (NB: #285 is accepted,
>>>>> but not implemented.)
>>>>>
>>>>> Regarding GHCXXXX: Yes, I think we would end up removing
>>>>> ExtendedForAllScope from it -- or at least I would advocate for doing so.
>>>>> Indeed, when we considered ScopedTypeVariables as a candidate for GHCXXXX,
>>>>> I was worried about getting stuck with it, and I believe it was important
>>>>> to me that we had the option to remove, later.
>>>>>
>>>>> Richard
>>>>>
>>>>> On Apr 4, 2022, at 3:38 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>>>>>
>>>>> On Mon, 4 Apr 2022 at 18:17, Richard Eisenberg <lists at richarde.dev>
>>>>> wrote:
>>>>>
>>>>>> Thanks for kicking off this conversation, Arnaud!
>>>>>>
>>>>>> To be clear in this thread: I'm fine delaying the discussion of
>>>>>> section 6-8 until later.
>>>>>>
>>>>>> Arnaud brings up my new principles in his initial email. Do please
>>>>>> consider these principles as part of the deliberations, as they will become
>>>>>> principles that we, as a committee, will have adopted.
>>>>>>
>>>>>> About extensions: We, as a community and as a committee, have not
>>>>>> come to terms with the two possible interpretations of extensions. I would
>>>>>> like to say that, ideally, extensions are candidates for eventual
>>>>>> inclusion. However, that is neither the current practice nor our trendline.
>>>>>> Examples:
>>>>>>  - any flags included in Haskell98 (including, for example,
>>>>>> MonomorphismRestriction). These are definitely settings that one can choose
>>>>>> per module. If they were candidates for inclusion, they wouldn't exist
>>>>>> (because they're already included!).
>>>>>>  - RebindableSyntax (though this is not one to mimic)
>>>>>>  - MagicHash. My interpretation is that this extension is meant to
>>>>>> allow users to explicitly opt into low-level code.
>>>>>>  - Recently accepted #285
>>>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/285>, which
>>>>>> introduces two new -XNo... extensions (both also included in #448).
>>>>>> As a practical matter, then, extensions are means of customization.
>>>>>> We might imagine a debate where we try to change this, and then come up
>>>>>> with a way to get from where we are to that changed future.
>>>>>>
>>>>>
>>>>> I think we actually did come to some agreement on the interpretation
>>>>> of extensions, it's in our review criteria under "does not create a
>>>>> language fork":
>>>>> https://github.com/ghc-proposals/ghc-proposals#review-criteria . Yes
>>>>> there are plenty of extensions that don't fit this criteria, but they tend
>>>>> to be either special-purpose extensions for things like low-level
>>>>> programming, building DSLs, or for backwards compatibility, rather than
>>>>> extensions we would expect people to routinely enable.
>>>>>
>>>>> Does that apply in this case? Well, perhaps the extensions are not
>>>>> technically incompatible, but they're "at odds" as Arnaud puts it.
>>>>>
>>>>> Another way to frame the original question might be: which of these
>>>>> extensions do we expect to include in GHC2023 (or GHC2024 or whatever it
>>>>> ends up being)? GHC2021 already has ScopedTypeVariables. We did decide (if
>>>>> I recall correctly) that we might remove things from future GHCXXXX sets,
>>>>> so are we going to remove ExtendedForAllScope and add TypeAbstractions from
>>>>> some future GHCXXXX, or just add TypeAbstractions?
>>>>>
>>>>> I'm not expressing a preference one way or the other, just that we
>>>>> should decide where this is going.
>>>>>
>>>>> Cheers
>>>>> Simon
>>>>>
>>>>> Very specifically answering Simon M's concern: I see
>>>>>> ExtendedForAllScope as a dead end, yes. It's included as a way of
>>>>>> supporting the gobs and gobs and gobs of code that use today's
>>>>>> ScopedTypeVariables, but at t=∞, we should get rid of it. Note that an optional
>>>>>> extra
>>>>>> <https://github.com/goldfirere/ghc-proposals/blob/type-variables/proposals/0448-type-variable-scoping.rst#58alternatives> introduces
>>>>>> a @(..) syntax that makes TypeAbstractions significantly less repetitive,
>>>>>> and thus about as easy to use as ExtendedForAllScope (which, recall,
>>>>>> requires an explicit forall where there might otherwise be none).
>>>>>>
>>>>>> Richard
>>>>>>
>>>>>> PS: I'm on holiday starting tomorrow and so may not respond for about
>>>>>> two weeks. Back in action on the 15th, but expect a few days of digging out.
>>>>>> _______________________________________________
>>>>>> 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/20220601/abbd805d/attachment.html>