
it would be good if the proposal contains enough information to get a feeling for the core idea of the proposal, both how it might be used, and about how it might be implemented, without referring to external papers.
I don’t really agree with this. Papers tend to be the result of a great deal of focused attention and multiple iterations. It’s hard (and indeed wasteful) to duplicate that effort in a proposal. Better just to point to it. (On the rare occasions where there is a paper that squarely addresses the topic of the proposal.)
But yes, more examples (not duplicate examples) are always good.
Simon
From: Iavor Diatchki [mailto:iavor.diatchki@gmail.com]
Sent: 28 November 2017 02:16
To: Richard Eisenberg
On Nov 27, 2017, at 9:58 AM, Simon Peyton Jones
mailto:simonpj@microsoft.com> wrote: * If a proposal requires a change to Core, that change should be described rather precisely.
In Greek or in Haskell? Less tersely: does a formalization in a paper suffice? Or should the proposal write out the new Haskell definition? These are closely related, but not the same. (For example, formalizations don't include the AppTy/TyConApp/FunTy distinction that is important for performance.) My own view is that Greek is enough. Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee