Re: [ghc-steering-committee] DH quantifiers (#102), Recommendation: accept

Joachim is right here. #102 is motivated by putting #81 (the `forall x y z ->` syntax) in context. I see a few possible reactions (after suitable bikeshedding): 1. Reject the syntax. If we do this, I'd love to open a larger conversation of ways forward -- do we want tweaks to the syntax or a wholly new approach? 2. Put this idea on hold, with a plan to accept or reject #81 on its own merits. 3. Accept the proposal, but put implementation on the back burner. This would serve to reserve the syntax, without burdening our users until the features are more fully-formed. 4. Accept the proposal and plan to implement. An advantage of implementing this now (option 4) is that it will ease backward-compatibility problems later. A disadvantage of implementing this now is that further thought may refine our ideas. Option 3 is similar, but both the advantage and disadvantage are at lower volume. Option 2 puts this advantage and disadvantage on mute. Indeed, the only reason I would advocate for going beyond Option 2 is that the idea, in Joachim's words, looks well-thought-through [1]. Thanks, Richard [1]: https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1074&context=compsci_pubs

On Feb 23, 2018, at 10:56 AM, Joachim Breitner wrote:

Hi,

Am Freitag, den 23.02.2018, 15:52 +0000 schrieb Simon Peyton Jones:

...

Why do we need this now? There's lots of new syntax. Is it solving tomorrow's problems, or todays?

Does the proposal subsume #81 (syntax for visible dependent quantification)? That one /does/ have a current motivation.

Perhaps #102 is just a grander version of #81, reserving the syntax but with #81 as the sole current motivation?

when #81 was proposed, Roman (as the shepherd) complained that on its own, the choice of syntax in #81 was not very well motivated just by that proposal. Maybe, if #81 was all there is to do, we’d choose a different syntax! So really, the syntax in #81 is motivated by coming up with a consistent and comprehensive syntax scheme for _all_ variations of the quantifier, and Roman asked Richard to write that up as one proposal, instead of introducing the syntax piece by piece. And that’s now #102.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee