- ghc-steering-committee

Status
by Joachim Breitner 23 Jun '18

23 Jun '18

Hi committee, high time for another status mail. Please look through this and see if anything is pending on you, of otherwise needs your attention. Since the last status update, we * were asked to review these proposals: #112 UnliftedArray# (Shepherd: Simon Marlow) #81 ExtraCommas (Shepherd: Chris) #121 Array resizing primitives (Shepherd: Simon Marlow) #129 TypeApplication and literals (Shepherd: Joachim) #125 Type annotated quoters (Shepherd: Manuel) #111 Linear types (Shepherd: Richard) #28 bundling patterns with type synonyms (Shepherd: Chris) #134 Deprecating Exports (Shepherd: Joachim) #146 Remove TypeOperators => NoStarIsType (Shepherd: Ben) * got a recommendation from shepherds about: #81 ExtraCommas (recommendation: accept) #99 forall {k} (recommendation: accept) #129 TypeApplication and literals (recommendation: accept) #112 UnliftedArray# (recommendation: accept) #121 Array resizing primitives (recommendation: accept) #134 Deprecating Exports (recommendation: accept) #43 Or patterns round two (recommendation: accept) #28 bundling patterns with type synonyms (recommendation: accept) * decided about the following proposals - Constraint vs. Type (accept) - Embrace Type in Type (accept) - PatternSignatures (reject) - Mutable constructor fields (needs revision) #112 UnliftedArray# (accept) #129 TypeApplication and literals (reject) #120 Deriving Via (accept) #103 Treat kind and type vars dientical (accept) #121 Array resizing primitives (accept) #96 Binding existential type variables (reject) We currently have to act on the following 13 proposals, which is one less than last round. Remove TypeOperators => NoStarIsType "migration" https://github.com/ghc-proposals/ghc-proposals/pull/146 Shepherd: Ben Status: Waiting for recommendation. Deprecating Exports https://github.com/ghc-proposals/ghc-proposals/pull/134 Shepherd: Joachim Recommendation: accept Status: Discussion ongoing Type annotated quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Shepherd: Manuel Status: Waiting for recommendation. Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Status: Waiting for recommendation. Linear types https://github.com/ghc-proposals/ghc-proposals/pull/111 Shepherd: Richard Status: Waiting for recommendation. Define Kinds Without Promotion https://github.com/ghc-proposals/ghc-proposals/pull/106 Shepherd: Ryan Status: Still waiting for recommendation. forall {k}, https://github.com/ghc-proposals/ghc-proposals/pull/99 Shepherd: Iavor Status: Ongoing discussion ExtraCommas https://github.com/ghc-proposals/ghc-proposals/pull/87 Shepherd: Chris Recommendation: accept Status: Ongoing discussion, met with some reservation. Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Discussion needs to happen Top-level kinds signatures https://github.com/ghc-proposals/ghc-proposals/pull/54 Shepherd: Roman Leshchinskiy Status: Waiting for recommendation. Or-Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Recommendation: accept Status: Round 2 being discussed Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Status: This is still lingering since last July! Bundling patterns with synonyms https://github.com/ghc-proposals/ghc-proposals/pull/28 Shepherd: Chris Recommendation: accept Status: Ongoing discussion, met with some resistance. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Proposal: Binding existential type variables (#96)
by Roman Leshchinskiy 23 Jun '18

23 Jun '18

Hi everyone, The proposal is to add a way to name existential type variables in pattern matches: https://github.com/ghc-proposals/ghc-proposals/pull/96. Suppose we have a constructor with an existential: data T where MkT :: forall a. Show a => a -> T Under the proposal, we could then bind that existential in a match against MkT: f :: T -> String f (MkT @a x) = show (x :: a) Note that this reuses the syntax for visible type application. Only the forms @a (where 'a' is a variable) and @_ are permitted. In the discussion the following major questions have been raised. 1. What about universally quantified type variables, such as 'a' in the following definition: data U a where MkU :: forall a b. Show a => b -> T a Do we need to mention 'a' in a pattern match against MkU? The answer (now reflected in the proposal) is no - universally quantified type variables can't be bound in this way. The pattern would look like this: g :: U a -> String g (MkU @b x) = show (x :: b) The bulk of the discussion was about this question. 2. What exactly is an existential? The above examples are clear but what about: type family Id a where Id a = a data T a where MkT :: forall a. a -> T (Id a) This is an existential under the current rules but given this, the distinction between existentials and universals might be not entirely intuitive. 3. What about pattern synonyms? The proposal now clarifies that they are treated exactly the same as data constructors. My recommendation is to reject the proposal as is but to encourage the authors to come up with a different syntax. The reason is that the proposal "steals" the syntax for explicit type application in patterns but it seems to me that type application in patterns makes perfect sense! I don't see why I shouldn't be eventually able to write something like: data C a = C a h (C @Int n) = n and have the compiler infer h :: C Int -> Int. Having @type mean something other than type application in pattern seems highly confusing to me and kills a possibly useful future feature. I believe a lot of the confusion with respect to point 1 above happened precisely because the proposal blurs the difference between type application and binding in patterns. As to syntax, perhaps using 'type' or 'forall' as type binders instead of '@' would work. Thanks, Roman

5 6

Please Review: Remove TypeOperators => NoStarIsType "migration" (#146), Shepherd: Ben Gamari
by Joachim Breitner 22 Jun '18

22 Jun '18

Dear Committee, this is your secretary speaking: Remove TypeOperators => NoStarIsType "migration" #146 by Oleg Grenrus was proposed. https://github.com/ghc-proposals/ghc-proposals/pull/28 I propose Ben Gamari as the shepherd, in case the decision needs to be coordinated with the 8.6 release. Ben, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Proposal: Or patterns #43 (Round 2)
by Manuel M T Chakravarty 19 Jun '18

19 Jun '18

We now have a revised version of the ”Or pattern” proposal #43 to consider: (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-pa… (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 You may remember that we discuss this a while back https://mail.haskell.org/pipermail/ghc-steering-committee/2017-November/000… and finally decided to bounce it back to the authors with the following recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-3581893… We previously decided that we are inclined to accept this proposal if the authors change the points that we highlighted. Judging from the conversation of SimonPJ and Richard with the author on the GitHub thread, it appears to me that most of the issues have been addressed. However, Simon’s point • "Patterns that bind existentials, dictionaries, or equalities are rejected by the type checker". I disagree. Earlier I suggested "no variable bound by an or-pattern can have a type that mentions an existential variable bound by the or-pattern". That is much more friendly because you can still match against an existential constructor; you just can’t bind an existential variable. from <https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-3689334… <https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-3689334…>> still doesn’t seem to be addressed, or am I misunderstanding? Overall, I propose to accept the proposal, possibly requiring that the above point be addressed. What do you all think? Cheers, Manuel

4 5

Proposal: Or patterns (#43)
by Manuel M T Chakravarty 18 Jun '18

18 Jun '18

Folks, I am sorry for taking a long time to get us going on this proposal. The ”Or pattern” proposal is about an extension to pattern matching: (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-pa… (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 Its basic idea is simple: allow multiple alternative patterns for each alternative during pattern matching. Unfortunately, the interaction with guards and some other languages features makes it significantly less straight forward than one might initially think. I propose to accept this proposal provided we can agree to use the ”first semantics” (aka single-match semantics) — see https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-pa… My reason for insisting on the first semantics is that it is a simple extension of the existing pattern semantics in the Report, whereas the second semantics requires a more profound, non-local change. This, in particular, also makes it easier to understand the implications of the first semantics. (Also, OCaml has made that same choice.) However, even with the first semantics, I still have one concern about this proposal. The story about the interaction with existential types is currently only partial and there is no discussion of the interaction with GADTs. It might be reasonable to ask for a complete specification of the interaction with these features before making a final determination on this proposal. Nevertheless, this proposal is quite elaborate and quite some work has gone into it. Hence, I think, we owe it the authors of the proposal to at least make a preliminary determination at this point. (In particular, if it is not going to fly regardless of how GADTs are handled, we should say so now.) Cheers, Manuel PS: It is worth noting that Swift solved the problem of deciding between the first and second semantics by choosing a syntax that avoids the ambiguity: <https://developer.apple.com/library/content/documentation/Swift/Conceptual/…>. It is difficult to adapt this syntax to Haskell. If it where possible, I think, this would be the best solution.

6 14

Kinds without promotion (#106)
by Iavor Diatchki 13 Jun '18

13 Jun '18

Hello, it's been a couple of months since this was submitted to the committee, so I'd be interested to get some feedback. In summary, this proposal introduces a mechanism for defining new kinds without having to promote a datatype, thus avoiding pollution of the value level name space with unused constructors. This is not a particularly new idea, and folks have been asking for it for at least 6 years now (e.g., see #6024). A few of our projects at work make use of a lot of type-level indexing (using GATs, etc.) and while things mostly work pretty well, the clunkiness of having to promote datatypes when you just want to define a new kind is something that keeps popping up over and over again, which is why I was motivated to submit the proposal. Thoughts? -Iavor

1 0

Need more Trac tickets
by Richard Eisenberg 02 Jun '18

02 Jun '18

Hi all, Ryan Scott very helpfully this morning labeled the Trac tickets that have grown from proposals. However, there remain a good many proposals without corresponding Trac tickets. I propose that we make it a shepherd's responsibility to make sure that a Trac ticket is created upon the acceptance of a proposal. Specifically: a shepherd should encourage the proposer to make the Trac ticket, and if this fails to happen, then for the shepherd to do it himself. (Why have the proposer do it? 1. To lessen the burden on the shepherd. 2. To subtly encourage the proposer to ponder the possibility of implementing.) What do we think? We'll still have to make tickets for those accepted proposals but with not tickets... Richard

2 5

Array resizing primitives (#121), proposal: accept with modifications
by Simon Marlow 02 Jun '18

02 Jun '18

I propose that we accept https://github.com/ghc- proposals/ghc-proposals/pull/121 With one modification (below). In summary, this proposal suggests adding primitives for resizing (shrinking or expanding) primitives mutable arrays of pointers. See the proposal for motivation. There would be two primitives per array type: shrinkArray# :: MutableArray# s a -> Int# -> State# s -> State# s resizeArray# :: MutableArray# s a -> Int# -> a -> State# s -> (# State# s, MutableArray# s a #) (these mirror the existing shrink and resize primitives we have for ByteArray#, with the same rationale) The biggest downside is that we currently have sizeOfMutableArray# :: MutableArray# s a -> Int # which would need to be replaced by a stateful operation getSizeOfMutableArray# :: MutableArray# s a -> State# s -> (# State# s, Int# #) So we would need to deprecate the old primops, update any code we have that uses them, and clearly indicate the unsafety in the docs. But this has knock-on effects in Data.Primitive: sizeofMutableArray :: MutableArray s a -> Int this would need to be deprecated and replaced by a PrimMonad operation. The pure version would be unsafe in the sense that it could return the wrong size, and a future indexing operation relying on the incorrect size could access an out-of-bounds element. Suggested modifications: * Remove the ArrayArray# primitives, add UniftedArray# primitives instead (see https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0021-u… ) Cheers Simon On 1 May 2018 at 13:12, Joachim Breitner <mail(a)joachim-breitner.de> wrote: > Dear Committee, > > this is your secretary speaking: > > Array resizing primitives have been proposed by David Feuer: > https://github.com/ghc-proposals/ghc-proposals/pull/121 > > I propose Simon Marlow as the shepherd. > > Simon, please reach consensus as described in > https://github.com/ghc-proposals/ghc-proposals#committee-process > > I suggest you make a recommendation, in a new e-mail thread with the > proposal number in the subject, about the decision, maybe point out > debatable points, and assume that anyone who stays quiet agrees with > you. > > Thanks, > -- > Joachim Breitner > mail(a)joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee(a)haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > >

3 2

Treat kind and type vars identically with `forall` #103
by Simon Peyton Jones 22 May '18

22 May '18

Dear GHC steering committee I strongly propose that we accept Treat kind and type vars identically with `forall` #103 https://github.com/ghc-proposals/ghc-proposals/pull/103 It makes our design much more simple and uniform - both in the specification and in the implementation. The current setup is a terrible dogs breakfast. Moreover, I propose that we adopt it without a 3-release wait after #83 - see under Alternatives. Any programs that are rejected by #103 can be fixed by adding some extra forall k's. And that change will be accepted NOW if you add -XTypeInType. Simon

4 7

Deriving via (#120), Recommendation: accept
by Joachim Breitner 22 May '18

22 May '18

Dear Committee, this is your secretary speaking: Deriving via was proposed, by Ryan, Icelandjack and Andres, https://github.com/ghc-proposals/ghc-proposals/pull/120 rendered at https://github.com/Icelandjack/ghc-proposals/blob/patch-3/proposals/0000-de… I’ll shepherd that myself. The proposal adds a new deriving strategy that works like GND, but explicitly names the other, representationally equal type whose instance should be copied. The proposal comes with a paper and an implementation, has been met with great enthusiasm in the community, and I expect that our users will do many great things with it, and all that with relatively little theoretical and implemntational overhead. I therefore wholeheartedly recomment that we accept this proposal. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 4