[ghc-steering-committee] Please review #641: Wildcard binders in type declarations

[Simon Peyton Jones]

If forced to voice an opinion I am still slightly in favor of the proposal.
Mainly because we have an implementor here who is motivated to implement
this,
thus the implementation cost seems less problematic.


It's best to imagine that implementation is free.  (If the implementation
is too costly, no one will do it, and the entire proposal becomes moot.)
What matters is the *maintenance *cost.  In ten years time when all the
current enthusiasts have moved on, our future selves will be working on the
implementation.

Here the additional complexity is not great.  But neither is the benefit.

Also let us remember the TH breakage.  That is a real cost, imposed on our
users.

I was originally pretty much on the fence, leaning to reject.  But the more
we discuss it, the more convinced I become that we should park this until
someone actually wants it.

Simon

On Sat, 30 Mar 2024 at 21:39, Malte Ott <malte.ott at maralorn.de> wrote:

>
> On 22/03/2024 18:19, Simon Peyton Jones wrote:
> >      >From my understanding the biggest argument against this is the
> >     change in
> >     template-haskell?
> >
> >
> > Not specifically.  My reservation is that
> >
> >   * it's an unforced change,
> >   * with no user demand
> >   * but some real user impact (you mention TH)
> >   * and some implementation cost (modest but very non-zero)
> >   * aiming to anticipate as-yet-unknown future requirements
> >
> > That's not a combination I like.  Pain now for possible (but uncertain)
> > gain in the future.
> >
> > I don't object to making types and terms behave similarly -- indeed I
> > have invested lots of time working with Richard, Vlad, Andrei and others
> > on proposals and MRs that move in this direction.  I'm just very
> > unconvinced about *this *proposal.
> >
> > One minor point.  In patterns we allow this:
> > f ((,) @Int @[a] x y) = ...
> > Here the type arguments are not type variables but full-blown types, and
> > of course nested parens etc come "for free".  But this proposal concerns
> > data type declarations in which we definitely don't want fulll-blown
> > types. So it's more than a "terms and types should be the same"
> > discussion.
> >
> > Simon
>
> I see. I admit that I don’t feel expert enough to know if this design will
> turn
> out to be optimal.
>
> If forced to voice an opinion I am still slightly in favor of the proposal.
> Mainly because we have an implementor here who is motivated to implement
> this,
> thus the implementation cost seems less problematic.
>
> Best,
> Malte
> _______________________________________________
> 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/20240330/b818cadc/attachment.html>