[ghc-steering-committee] Proposal: Or patterns (#43)
Simon Peyton Jones
simonpj at microsoft.com
Tue Nov 7 19:04:53 UTC 2017
1. The syntax conflict with the view pattern proposal is unfortunate---I really like this idea, and I wrote up basically the exact same thing in my dissertation a long time ago, where I called it "guarded patterns". Very handy I think.
Yes… I too wondered about ||, although then we’d run into trouble with definitions of the function (||). It seems hard to not-accept a proposal because it conflicts with another un-submitted one. But that’s just a question of specifying which wins in the ambiguous case
p1 || p2 = e
I like the fact that || is a bit noisier; we are using | for guards already.
We should only allow it infix.
Would someone like to submit the view-pattern proposal?
For the second one, I can see two options:
A) do not allow or patterns if any of the patterns contain constraint
B) come up with a mechanism to compute the intersection of constraints
I prefer (C): require exactly the same constraints bound in both patterns. Same as we require exactly the same variables bound. We could loosen up later.
From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Iavor Diatchki
Sent: 07 November 2017 18:03
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Proposal: Or patterns (#43)
Hello,
I think that in principle the or-pattern patter idea is fine, but I am a bit wary of accepting it as is for two reasons:
1. The syntax conflict with the view pattern proposal is unfortunate---I really like this idea, and I wrote up basically the exact same thing in my dissertation a long time ago, where I called it "guarded patterns". Very handy I think.
2. The story about pattern contexts seems unclear (i.e., extistentials and GADTs).
To work around the first one, how about we use double bar (i.e., ||) to separate the Or pattern? The single bar does feel more natural though...
For the second one, I can see two options:
A) do not allow or patterns if any of the patterns contain constraint
B) come up with a mechanism to compute the intersection of constraints. For this I can see a few options:
B.1) Fancy intersection, where the different branches of the or-patterns may define additional evidence bindings (be it dictionaries or coercions).
B.2) Simple intersection, where we only pick constraints from the contexts that match exactly.
-Iavor
On Fri, Nov 3, 2017 at 6:19 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,
from a procedural point of view, that’s fine: We can certainly ask for
improvements to a proposal, and there is even a “Needs revision” label
for it.
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<mailto: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-<mailto:ghc-steering-committee->
> > > bounces at haskell.org<mailto:bounces at haskell.org>] On Behalf Of Manuel M T Chakravarty
> > > Sent: 01 November 2017 23:58
> > > To: ghc-steering-committee at haskell.org<mailto: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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fb.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=vVnLieNrA5efYx9jbB%2BXtb%2FYWdKpO01CQMD2dj6Cwsg%3D&reserved=0>%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-
> > > or-
> > > patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=0I1KlIPm7n54A5ECKT91vmrrLLtKyLoeS9uD5dfzTG0%3D&reserved=0>%7Cc41b6be72ad54503
> > > 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177
> > > 4805951860<tel:(480)%20595-1860>&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D&
> > > reserved=0
> > > (PR thread)
> > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> > > b.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fb.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=vVnLieNrA5efYx9jbB%2BXtb%2FYWdKpO01CQMD2dj6Cwsg%3D&reserved=0>%2Fghc-proposals%2Fghc-
> > > proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=0I1KlIPm7n54A5ECKT91vmrrLLtKyLoeS9uD5dfzTG0%3D&reserved=0>%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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fb.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=vVnLieNrA5efYx9jbB%2BXtb%2FYWdKpO01CQMD2dj6Cwsg%3D&reserved=0>%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-
> > > or-patterns.rst%23interaction-with-
> > > guards&data=02%7C01%7Csimonpj%40microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=0I1KlIPm7n54A5ECKT91vmrrLLtKyLoeS9uD5dfzTG0%3D&reserved=0>%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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Floper.apple.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=wCHBivwlq4sPM%2BVxMQIIwCzfjGwLKUf7c3xTgXUXtvg%3D&reserved=0>%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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=0I1KlIPm7n54A5ECKT91vmrrLLtKyLoeS9uD5dfzTG0%3D&reserved=0>%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<mailto: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<mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
--
Joachim Breitner
mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=TyqRhlHt83F%2BCpZzF5kNM%2BI4YFj3GbLOGq5pNskVrbw%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto: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/20171107/5690e56c/attachment-0001.html>
More information about the ghc-steering-committee
mailing list