[ghc-steering-committee] Record dot syntax: vote results

Tue Mar 31 10:40:58 UTC 2020

On Tue, 31 Mar 2020 at 11:08, Simon Peyton Jones via ghc-steering-committee
<ghc-steering-committee at haskell.org> wrote:

> Thanks Joachim.
>
> Everyone: I have extended our choices document with a draft post to the
> Github thread.
>
> https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74/edit?usp=sharing
>
> Can you review it, for both tone and content?  You have edit permission,
> so by all means improve the wording.  Look for omissions.  I want to bring
> the discussion to a close, not re-ignite further debate, but be respectful
> of those who disagree.
>

Before we accept the proposal I think we should have a precise description
of the changes to the syntax. For example, we don't address the question of
whether a field name can be an operator or not. We explicitly left these
questions until later; wouldn't now be the right time to address them?

Also worth bringing up at this point, since we landed on C2a: Note 5 says

One mechanism for handling this is given in the proposal
<https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/proposals/0000-record-dot-syntax.md#2322-parsing-of-field-selections>.
It involves no changes to the lexer, but instead an adjacency test one
production of the parser.

I'm not sure about this as a language design. (1) it's an ad-hoc
side-condition that can't be expressed in the lexical or context-free
grammar (however there's precedent for this kind of thing in the form of
the layout rule of course), and (2) it's quite a costly feature in terms of
implementation effort to add to the language, because your AST needs
complete and accurate source-span information. We can do it in GHC, and
haskell-src-exts can do it nowadays, but earlier versions of
haskell-src-exts before complete SrcSpanInfo was added wouldn't have been
able to implement this rule. Arguably we're only accepting this as a GHC
extension and not a Haskell extension in general, but as we know GHC is the
testbed for future language extensions, so it's a good time to consider
these issues.

The alternative of course is to go with some variant of

   -

      Use the “tight infix” mechanism from this (accepted) GHC proposal
      <https://github.com/ghc-proposals/ghc-proposals/pull/229>

which is also an ad-hoc side-condition sadly, but could be implemented in
the lexer.  Nevertheless, all this needs to be nailed down before the
proposal can be accepted, IMO.

Cheers
Simon

>
> Could you do so this week, by end Friday?   I propose to leave the votes
> recorded there, but when posting I'll move the post from the document
> (deleting it from there) to GitHub.
>
> I'm cc'ing Neil and Shayne, the authors.  Neil, Shayne: I think (and
> desperately hope!) you'll be content with this outcome.  Can you review my
> draft post too?
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org>
> |  On Behalf Of Joachim Breitner
> |  Sent: 30 March 2020 17:48
> |  To: ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  Subject: Re: [ghc-steering-committee] Record dot syntax: vote results
> |
> |  Dear Committe,
> |
> |  thanks all for voting. The ranking of votes is now
> |
> |        C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5
> |
> |  In particular C2a beats every other options by 7:4 or more, and is
> |  therefore the result of this poll.
> |
> |  You can see more statistics at
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cond
> |  orcet.vote
> %2FVote%2FAB23CE70AC%2F&data=02%7C01%7Csimonpj%40microsoft.c
> |
> om%7Ce27e9c8f455b436e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7
> |
> C1%7C0%7C637211837260982595&sdata=LLWCxVjXxyLqcJUZ9iMgB%2B5QYGMuHFzJga
> |  u9agTakiQ%3D&reserved=0
> |
> |  So, does this conclude this saga?
> |
> |  Cheers,
> |  Joachim
> |
> |  --
> |  Joachim Breitner
> |    mail at joachim-breitner.de
> |
> |
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
> |  im-
> |  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com
> %7Ce27e9c8f455b43
> |
> 6e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372118372
> |
> 60982595&sdata=GE%2BBYN7rA7zWgwuKlArv4PR%2Fm3IlmZ7PqWbGpgXUyms%3D&
> |  reserved=0
> |
> |
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
> |  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&data=02%7C01%7Csimonpj%40microsoft.com
> %7Ce27e9c8f455b436e2be
> |
> e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982
> |
> 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved=
> |  0
> _______________________________________________
> 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/20200331/5ca23792/attachment-0001.html>