[ghc-steering-committee] RecordDotSyntax: please express a view

Joachim Breitner mail at joachim-breitner.de
Tue Dec 10 11:40:37 UTC 2019


Hi,

TL;DR: Support acceptance, preference for (.foo) over .foo.

I guess many people are excited, so overall good to get this.

I recently stopped using Haskell for something where readability was
the primary goal for lack of nested access and updates. So yay! :-)

I am a bit unhappy about the “Higher-rank fields” problem. Not that I
use such field often, but it came up in the “Overloaded do” proposal.
Maybe accepting this will increase the chances of a getField variant
that works even in impredicative cases.

I hope pattern matching will follow, but no need to have it in this
proposal.


About the contentious issue of (.foo) vs. .foo, I am squarely in the
(.foo) camp, for all the gut-feeling reasons given elsewhere in
abundance. My main reasons: feels like a syntactic section to me, and
less danger of wat effects for people coming from languages with the

  a.foo
   .bar
   .baz

idiom…


I will not veto the current form, but Eric may be in less of a minority
that he thinks.



The precedence rule

   f a.b.c 10

being

   f (a.b.c) 10

makes sense when one comes from Ocaml or similar languages, or has
thought about record updates for a long time. There is a trace of a
feeling that this is un-Haskellish in the same way as

   f a { b = c } 10

is. But at least we don't allow spaces around the dot, so it is
probably fine.


Cheers,
Joachim






Am Montag, den 09.12.2019, 22:57 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> Dear steering committee
> 
> I'm the shepherd for the RecordDotSyntax proposal.
>   https://github.com/ghc-proposals/ghc-proposals/pull/282
> 
> I recommend acceptance:
> https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691
> 
> Please reads the proposal, and as much of the discussion as you feel able, and respond in the next week or two to indicate your views.
> 
> Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion.
> 
> I'd love every member of the committee to express a view.  This proposal has attracted a lot of interest.
> 
> Thanks
> 
> Simon
> 
> > -----Original Message-----
> > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> > On Behalf Of Joachim Breitner
> > Sent: 28 November 2019 10:11
> > To: ghc-steering-committee at haskell.org
> > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:
> > RecordDotSyntax, Shepherd: Simon PJ
> > 
> > Dear Committee,
> > 
> > this is your secretary speaking:
> > 
> > RecordDotSyntax language extension proposal has been proposed by Neil
> > Mitchell and Shayne Fletcher
> > https://github.com/ghc-proposals/ghc-proposals/pull/282
> > https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-
> > syntax/proposals/0000-record-dot-syntax.md
> > 
> > This is going to be a tricky one. It is partly about whitespace, so it
> > has attracted a _lot_ of community interest, by far the most so far. To
> > navigate that ship, I propose Simon PJ as the shepherd, because he is a
> > excellent moderator and community manager, and because he has the
> > necessary authority to hopefully get a verdict accepted.
> > 
> > Please reach consensus as described in
> > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > I suggest you make a recommendation, in a new e-mail thread with the
> > proposal number in the subject, about the decision, maybe point out
> > debatable points, and assume that anyone who stays quiet agrees with you.
> > 
> > Thanks,
> > Joachim
> > --
> > Joachim Breitner
> >   mail at joachim-breitner.de
> >   http://www.joachim-breitner.de/
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



More information about the ghc-steering-committee mailing list