[ghc-steering-committee] Our process and BIG ideas

[Richard Eisenberg]

I fully agree that proposals for large new features can reference an accompanying paper.

However, I'm leery of unconditional approval of something as large as the linear types proposal. GHC is a very large, complex system, and no one can anticipate all the interactions that a proposal may have with existing features. It's quite possible that something which seems like a good idea has a disastrous interaction with some other part of the compiler/language definition.

Instead, I would favor a conditional approval that would turn to rejection only if further experience (gained through a [partial] implementation) reveals a theoretical sticking point. I use "theoretical" here to mean that the rejection wouldn't be based on poor code quality or an implementation challenge, per se, but by running into a scenario where we are unable to specify the correct behavior of the system.

In truth, even an approval that we described as unconditional would really be as in the paragraph above -- we simply can't do better. So I guess I'm favoring calling such an approval as conditional, just to be clear to proposers what we mean.

Richard

> On Nov 12, 2017, at 10:07 PM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> 
> In the light of the linear types proposal PR, SimonPJ’s comment
> 
>  https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomment-343457821
> 
> and some uncertainty about the proposal process that has been communicated to me via a side channel, it might be worthwhile clarifying our expectations for large complex proposals. (I know, we basically punted on these questions in our initial discussion on the process with the intention to revisit after we gained some experience. It seems this time has come.)
> 
> Firstly, we usually require proposals to be self-contained. This makes a lot of sense for small to medium-sized proposals to limit the time needed by the committee to hunt down all the required information. However, in a case, such as the linear types work, where there is a highly polished text in the form of a research paper (or similar), it seems reasonable to refer to that existing work — not only because type rules are a lot nicer to read when rendered by LaTeX instead of Markdown.
> 
> Concretely, I’d like us to give some guidance wrt to this issue to proposal authors and document that at https://github.com/ghc-proposals/ghc-proposals#ghc-proposals
> 
> Secondly, Simon, you seem to suggest that a large proposal like this wouldn’t be either accepted or rejected, but put into a kind a limbo state of further evaluation as seen fit. I agree that instead of outright rejection of a proposal that we consider flawed but not hopeless, we might request further elaboration and resubmission as we have done in the past. However, if a proposal passes muster, I think, we should accept it unconditionally, even if it is a large change. (If, say, at the end, the implementation is not up to scratch, then it is up to the code reviewers to reject the patches, but I don’t think, it is this committee’s job anymore.)
> 
> In any case, I think, it is important make the process as clear as possible to authors, so they know what they are in for.
> 
> What do you all think?
> 
> Cheers,
> Manuel
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee