[ghc-steering-committee] Recommendation for #378: support the design for dependent types

Vitaly Bragilevsky bravit111 at gmail.com
Tue Mar 30 13:08:42 UTC 2021


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 at haskell.org>:

> Dear GHC Steering Committee
>
> I’m recommending acceptance of Proposal #378: Support the design for
> dependent types <https://github.com/ghc-proposals/ghc-proposals/pull/378>
>
> 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 <https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell>.
> 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
> <https://github.com/ghc-proposals/ghc-proposals/#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 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/20210330/af7df3f8/attachment.html>


More information about the ghc-steering-committee mailing list