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

Fri Apr 15 14:00:32 UTC 2022

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
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220415/f23e3484/attachment.html>