[ghc-steering-committee] Proposal: Or patterns (#43)

Mon Jan 8 04:20:30 UTC 2018

Yes, I will do that. Thanks for the reminder.

Cheers,
Manuel

> Am 06.01.2018 um 08:02 schrieb Joachim Breitner <mail at joachim-breitner.de>:
> 
> Hi Manuel,
> 
> not much discussion has happened here. Do you want to tell the authors
> about the changes that we would like to have fleshed out, so that we
> can get a better proposal back? Based on the discussion, I expect that
> a satisfactorially extended proposal to be accepted.
> 
> Cheers,
> Joachim
> 
> Am Freitag, den 03.11.2017, 10:40 +1100 schrieb Manuel M T Chakravarty:
>> You are right, the proposal must be complete before we can accept it.
>> What I would like to suggest is the following:
>> 
>> * If we all agree that *so far* this proposal is acceptable, we
>> bounce it back to the authors saying that if they are able to fill in
>> the gaps (especially, the treatment of GADTs) in a satisfactory
>> manner, we will accept the proposal.
>> 
>> * If we decide to reject the proposal, the authors can save
>> themselves the effort of completing the specification.
>> 
>> I know that this deviates from our usual procedure, but for a rather
>> large piece of work that does show promise, I think, it is worthwhile
>> to show some respect and appreciation for the effort spent.
>> 
>> Cheers,
>> Manuel
>> 
>>> Simon Peyton Jones <simonpj at microsoft.com>:
>>> 
>>> In general I'm ok with this proposal.
>>> 
>>> But I've just added a comment explaining some things that really need fleshing out.
>>> 
>>> 
>>> 
>>> * The proposal should specify that in (p1 | p2) the patterns in p1 and p2 must bind the same set of variables, with the same types. Nothing else makes sense; but it is nowhere specified.
>>> 
>>> * I'm concerned that the specification is incomplete. Certainly when it comes to GADTs there is some muttering about the prototype implementation, but no specification.
>>> 
>>> * For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 should bind the same set of existentials and the same set of type constraints (including class constraints), just as they must bind the same set of variables with the same types. Just write out the typing rules for patterns (which should be part of the proposal) and it'll all become clear!
>>> 
>>> * I'm bothered by the stuff about view patterns, lazy patterns etc in the proposal. The point is: or-patterns has NO interaction with these patterns. We should just say that and stop! By having (quite long) sections about these features, but not (say) about tuple patterns, the implication is that there is something special to say. But there isn't.
>>> 
>>>> 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.
>>> 
>>> Definitely non-backtracking.  The backtracking thing opens up a whole new can of worms.
>>> 
>>>> 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.)
>>> 
>>> I agree with that... but I'd be reluctant to actually accept it into GHC unless it was fully compositional, including GADTs.  So it'd be a conditional acceptance, subject to satisfactory resolution of the GADT question.  I'm not sure how the implementation works out... let's see; probably fine.
>>> 
>>> 
>>> Simon
>>> 
>>>> -----Original Message-----
>>>> From: ghc-steering-committee [mailto:ghc-steering-committee-
>>>> bounces at haskell.org] On Behalf Of Manuel M T Chakravarty
>>>> Sent: 01 November 2017 23:58
>>>> To: ghc-steering-committee at haskell.org
>>>> Subject: [ghc-steering-committee] Proposal: Or patterns (#43)
>>>> 
>>>> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
>>>> b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-
>>>> or-
>>>> patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54503
>>>> 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177
>>>> 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D&
>>>> reserved=0
>>>>   (PR thread)
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
>>>> b.com%2Fghc-proposals%2Fghc-
>>>> proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be
>>>> 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
>>>> C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh
>>>> w%3D&reserved=0
>>>> 
>>>> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
>>>> b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-
>>>> or-patterns.rst%23interaction-with-
>>>> guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08
>>>> d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595
>>>> 1860&sdata=Z5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0
>>>> 
>>>> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve
>>>> loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptu
>>>> al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%2F
>>>> swift%2Fgrammar%2Fswitch-
>>>> statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3
>>>> c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480
>>>> 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reser
>>>> ved=0>. It is difficult to adapt this syntax to Haskell. If it where
>>>> possible, I think, this would be the best solution.
>>>> _______________________________________________
>>>> 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
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee