
Overall, I am a bit weary of publishing a list of "requirements" for a proposal, mostly because anything we publish could probably be interpreted in different ways, and I think---for me---it is much more important that we collectively think the proposal is a good idea, than there being a check-list that has been completely checked-off.
Yes – but the more clarity we give the more likely we are to get good proposals, and to avoid misunderstandings. I think some effort is justified here.
S
From: ghc-steering-committee [mailto:ghc-steering-committee-bounces@haskell.org] On Behalf Of Iavor Diatchki
Sent: 28 November 2017 18:18
To: ghc-steering-committee@haskell.org
Subject: Re: [ghc-steering-committee] What do we need from the linear-types proposal?
I suspect we are in agreement here. What I was trying to capture is the fact that in my experience papers tend to contain both more and less than what I'd expect to find in a GHC proposal.
They contain more, in that they may address important issues such as proofs of soundness, or other important properties, much more extended motivation, comparisons to other research, etc.. I don't think these belong in a proposal, but I think it is a big plus for a proposal to refer to a published papers addressing such issues.
I think, however, sometimes (often?) papers also tend to aim at a fairly general explanation of concepts, that is not specific to a particular language. I think that GHC proposal should contain this extra detail, and be aimed at how the feature would be added to Haskell in particular (and even more concretely, to GHC). This involves discussing concrete syntax, interactions with other language features, and a lot of examples, so that a Haskell user can get a feel of what the new feature might feel like.
Overall, I am a bit weary of publishing a list of "requirements" for a proposal, mostly because anything we publish could probably be interpreted in different ways, and I think---for me---it is much more important that we collectively think the proposal is a good idea, than there being a check-list that has been completely checked-off.
-Iavor
On Tue, Nov 28, 2017 at 2:25 AM Simon Peyton Jones
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