[ghc-steering-committee] What do we need from the linear-types proposal?

[Iavor Diatchki]

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 <simonpj at microsoft.com>
wrote:

> 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 at gmail.com]
> *Sent:* 28 November 2017 02:16
> *To:* Richard Eisenberg <rae at cs.brynmawr.edu>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>;
> ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
> *Subject:* Re: [ghc-steering-committee] What do we need from the
> linear-types proposal?
>
>
>
> Hello,
>
>
>
> Coming up with a concrete list of suggestions is hard, but here are a
> couple things that would make it easier for me to understand large
> proposals (e.g., like the linear types one):
>
>
>
>    1. It is good if large proposals are "modular", meaning that you can
> understand them (and perhaps implement them), one piece at a time.  For
> example, adding certain features to the language may enable us to make
> library changes, but that sort of thing can be disused separately.
>
>
>
>    2. I think that 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.   One thing that works well for me is to see lots of
> examples which illustrate various aspects of the design.  Generally, I find
> it much easier to understand and generalize from a set of examples, than a
> set of rules, especially if the rules are not accompanied by an explanation
> of the reasons for choosing them.
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Nov 27, 2017 at 2:04 PM Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
>
> > On Nov 27, 2017, at 9:58 AM, Simon Peyton Jones <simonpj at 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 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/20171128/777af659/attachment.html>