[ghc-steering-committee] Proposal: Or patterns (#43)
Simon Peyton Jones
simonpj at microsoft.com
Fri Nov 3 08:40:24 UTC 2017
I'm ok with what you propose
S
| -----Original Message-----
| From: Manuel M T Chakravarty [mailto:chak at justtesting.org]
| Sent: 02 November 2017 23:40
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] Proposal: Or patterns (#43)
|
| 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%2Fgit
| > | hu
| > |
| > | b.com%2Fosa1%2Fghc-
| proposals%2Fblob%2For_patterns%2Fproposals%2F0000
| > | -
| > | or-
| > |
| > |
| patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545
| > | 03
| > |
| > |
| 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451
| > | 77
| > |
| 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3
| > | D&
| > | reserved=0
| > | (PR thread)
| > |
| > |
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
| > | hu
| > | b.com%2Fghc-proposals%2Fghc-
| > |
| > |
| proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6
| > | be
| > |
| > |
| 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0
| > | %7
| > |
| C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Sw
| > | mh
| > | 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%2Fgit
| > | hu
| > |
| > | b.com%2Fosa1%2Fghc-
| proposals%2Fblob%2For_patterns%2Fproposals%2F0000
| > | -
| > | or-patterns.rst%23interaction-with-
| > |
| > |
| guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c
| > | 08
| > |
| > |
| d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805
| > | 95
| > |
| > |
| 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%2Fde
| > | ve
| > |
| loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConcep
| > | tu
| > |
| al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%
| > | 2F
| > | swift%2Fgrammar%2Fswitch-
| > |
| > |
| statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030
| > | e3
| > |
| > |
| c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774
| > | 80
| > |
| 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&res
| > | er 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
More information about the ghc-steering-committee
mailing list