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

[Iavor Diatchki]

Hello,

my preference would be to reject this proposal, and turn the "proposed
design for dependent haskell" (the link in Simon's e-mail) into its own
proposal so that we can discuss it, and suggest changes.   It seems really
odd to agree to adhere to a design that we never discussed.

By the way, it's really great to finally see something written down about
the actual design of DH.  I had a quick read, and I have some questions,
which is why I think it makes more sense to have the design as its own
proposal.  In particular, it seems to me like it might be quite possible to
split the DH design into a collection of separate extensions, which might
make it easier to understand, although I don't fully understand the whole
picture, and might be wrong about that.

-Iavor






On Mon, Mar 29, 2021 at 5:17 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> 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/20210329/56b07c95/attachment.html>