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

[Simon Peyton Jones]

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/20220418/21f65134/attachment.html>