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@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@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee