[ghc-steering-committee] Please review #641: Wildcard binders in type declarations
Simon Peyton Jones
simon.peytonjones at gmail.com
Thu Mar 28 09:29:49 UTC 2024
Can't we fairly easily use pattern synonyms to support the old
constructors? That would avoid breaking any existing programs. (It would
necessarily introduce some partial matches, so a library matching on the
old constructors could fail if exposed to the new syntax, but by
definition existing code won't be using the new syntax.)
Old code would get incomplete pattern match warnings; and would fail
outright if it analysed quoted code that used the new syntax.
It's all just extra complexity! We have so many mission-critical things
to do. I'm arguing against taking out precious time and attention to deal
with a problem that no one is asking us to solve.
Sebastian Graf (in another context) pointed me to YAGNI:
https://martinfowler.com/bliki/Yagni.html The author puts it well.
Simon
On Thu, 28 Mar 2024 at 09:19, Adam Gundry <adam at well-typed.com> wrote:
> On 28/03/2024 08:40, Simon Peyton Jones wrote:
> > > What is the impact on Template Haskell? Is it a breaking API change?
> >
> > yes I think so -- we'd need to elaborate the TH data types.
>
> Can't we fairly easily use pattern synonyms to support the old
> constructors? That would avoid breaking any existing programs. (It would
> necessarily introduce some partial matches, so a library matching on the
> old constructors could fail if exposed to the new syntax, but by
> definition existing code won't be using the new syntax.)
>
> Adam
>
>
> > I don't like unforced breaking changes. That's why I advocate parking
> this.
> >
> > Simon
> >
> > On Thu, 28 Mar 2024 at 08:03, Simon Marlow <marlowsd at gmail.com
> > <mailto:marlowsd at gmail.com>> wrote:
> >
> > What is the impact on Template Haskell? Is it a breaking API change?
> >
> > On Wed, 27 Mar 2024 at 09:15, Simon Peyton Jones
> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> > wrote:
> >
> > Dear Simon, Chris, Eric, Moritz, Matthias
> >
> > You have not responded to my email below.
> >
> > I'll call a vote tomorrow, but I would love to hear your
> > opinions as a member of the GHC SC.
> >
> > Thanks
> >
> > Simon
> >
> > On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones
> > <simon.peytonjones at gmail.com
> > <mailto:simon.peytonjones at gmail.com>> wrote:
> >
> > Dear Steering Committee
> >
> > Vlad proposes to amend proposal #425
> > <
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to
> permit more wildcard binder forms in type declarations:
> > https://github.com/ghc-proposals/ghc-proposals/pull/641
> > <https://github.com/ghc-proposals/ghc-proposals/pull/641>
> >
> > You may find it easiest to look at the rich diff
> > <
> https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5
> >.
> >
> > This is a pretty small generalisation which would allow
> >
> > data T (( (a :: k1) :: k2)) = ...
> >
> > in which the binder has multiple kind signatures and
> > redundant parens. The change is *not driven by user need*,
> > but rather solely by *uniformity*: these same forms are
> > permitted in function definitions:
> >
> > f :: forall (a :: k). blah
> > f @(((a::k1)::k2))) = ...
> >
> > is permitted.
> >
> > It imposes a change on Template Haskell syntax too.
> >
> > The implementation becomes a bit more complicated; more
> > recursive data types, etc. Nothing hard, but more.
> >
> > It's not a big deal either way. Very few people expressed a
> > view on GitHub. My personal view is that the modest (albeit
> > non-zero) gain does not justify the definite (albeit modest)
> > pain. I would leave this until someone actually wants it.
> >
> > Vlad argues for future-proofing, but my experience is that
> > an eye to the future is sensible when you are making changes
> > anyway; but making unforced changes solely for the future
> > risks incurring pain now that, when the future comes, turns
> > out to have been a poor investment. We may have correctly
> > anticipated, or we may not.
> >
> > So my recommendation is to park this until we get a real
> > user demand.
> >
> > It's a perfectly sensible proposal, but adopting it is a
> > judgement call. I'll leave a week for committee responses,
> > and then we can just vote.
> >
> > Simon
> >
> > On Thu, 21 Mar 2024 at 08:07, Adam Gundry
> > <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> >
> > Dear Committee,
> >
> > Vlad proposes to amend proposal #425 to permit more
> > wildcard binder
> > forms in type declarations:
> >
> > https://github.com/ghc-proposals/ghc-proposals/pull/641
> > <https://github.com/ghc-proposals/ghc-proposals/pull/641
> >
> >
> > I'd like to nominate Simon PJ as the shepherd.
> >
> > Please guide us to a conclusion as outlined in
> >
> https://github.com/ghc-proposals/ghc-proposals#committee-process <
> https://github.com/ghc-proposals/ghc-proposals#committee-process>
> >
> > Cheers,
> >
> > Adam
> >
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20240328/cec30cb4/attachment.html>
More information about the ghc-steering-committee
mailing list