[ghc-steering-committee] Proposal: Or patterns (#43)
Iavor Diatchki
iavor.diatchki at gmail.com
Tue Nov 7 18:03:10 UTC 2017
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>
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>:
> > >
> > > 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 <(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%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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20171107/0f8fd3b4/attachment.html>
More information about the ghc-steering-committee
mailing list