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

[Alejandro Serrano Mena]

 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 at 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 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
>>
> _______________________________________________
> 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/20210401/ed13d855/attachment.html>