June 2018 - ghc-steering-committee

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 19 Jun '18

19 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 14 Jun '18

14 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 03 Jun '18

03 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 03 Jun '18

03 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