I agree with Vitaly on this not being a proper proposal. My main objection is that it indirectly brings all of https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell into the proposal, but in a sort of “we can still be wrong” mode. Personally, I’ll be happier to see the wiki page turned into a sort of “proposal roadmap” or something along those lines.

Alejandro

On 30 Mar 2021 at 15:08:42, Vitaly Bragilevsky <bravit111@gmail.com> wrote:
I don't see this proposal as a proper GHC proposal. I don't think we should accept or reject it. We don't have a formal check for committee criteria anyway. Am I in support of introducing DH into GHC? Yes, I am. But then I'll be more inclined to support Richard's objections to any other proposals if they contradict the DH design sketch. I don't need to swear to follow these additional criteria.

Vitaly
 

пн, 29 мар. 2021 г. в 15:17, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org>:

Dear GHC Steering Committee

I’m recommending acceptance of Proposal #378: Support the design for dependent types

As you’ll see, there is a lot of useful context, but the payload is pretty simple

When evaluating new proposals, the GHC committee would consider compatibility with the proposed design sketch of dependent types on the GHC wiki. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features.

Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly.

See also the committee's Review Criteria: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language.

Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just as ever.

Any views?  Let’s try to converge rapidly…. the proposal has been substantially refined by a lot of debate.

Simon

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee