Allow trailing and leading commas in exports, fixing #12389
Needs RevisionPublic

Authored by parsonsmatt on Oct 29 2017, 1:14 AM.

Details

Reviewers
bgamari
hvr
austin
parsonsmatt created this revision.Oct 29 2017, 1:14 AM

Good work, @parsonsmatt! Just one little nit.

I also wonder if it would be worth documenting this in docs/users-guide/infelicities.rst. Does the Report technically allow leading/trailing commas here?

compiler/parser/Parser.y
812

All of this fst and snd is rather tricky to follow. Perhaps you could just let bind these with sensible names above?

bgamari requested changes to this revision.Oct 29 2017, 7:44 PM
This revision now requires changes to proceed.Oct 29 2017, 7:44 PM
Improved variable names (ticket #12389)

It does look like the report does not allow trailing or leading commas in this part of the export list: https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1000005.2

I am unable to find the infelicities document you mentioned.

parsonsmatt marked an inline comment as done.Oct 29 2017, 8:20 PM
hvr requested changes to this revision.EditedOct 30 2017, 1:00 PM
hvr added a subscriber: hvr.

I'd love to have support for leading commas... but if we're going to do this, we need to guard this behind a language pragma. Btw, are you aware of the past discussions we had about adding support for redundant commas in parts of the language specs? In fact, IIRC even a GHC patch was written in the course of those previous discussion.

This revision now requires changes to proceed.Oct 30 2017, 1:00 PM

I am not aware of those discussions -- would you happen to have a link handy?

hvr added a comment.EditedOct 30 2017, 4:03 PM

I am not aware of those discussions -- would you happen to have a link handy?

So, basically we already had more or less agreed upon (at least that was my perception) a plan around 2014 (the discussions on the topic are however spread a bit; you can find bits in 2013 as well as in 2016 again on different mailing lists, and now again in 2017 obviously) on which Alexander B was working on back then.

https://mail.haskell.org/pipermail/ghc-devs/2014-September/006410.html

There were a few minor bikeshedding details, but other than that the idea was to

Introduce a language extension {-# LANGUAGE ExtraCommas #-} which you can probably google for (I'm a strong proponent of that myself for several reasons; that's my personal basic requirement for any syntax extension relative to the Haskell Report), which would relax/extend the grammar to allow comma-separators in more positions; this would include

  • record-like occurences (declarations, patterns, constructions, etc)
  • module export lists
  • module import lists
  • lists literals (i.e. [], both type-level & term-level)
  • fixity declarations
  • comma-separated enumerations in type-signatures (e.g. (Monad m, Monoid m) => ...)
  • (maybe) pattern guards
  • ...maybe one or two more places that are eluding me right now....

But *not*

  • language pragmas (due to catch-22)
  • Tuples (due to conflict w/ TupleSections)

Personally, I was (or at least I'd be now) a proponent for the smallest extension that allows to support both styles people were asking for (but without allowing mixing them in the same enumeration), i.e. allow

  • [a,b,c]
  • [,a,b,c]
  • [a,b,c,]

But do *not* allow

  • [,a,b,c,]
  • [,]
  • [,,]
  • [a,,b]
  • and so on

For completeness, I'd point out that there's also an OptionalCommas extension possible, which would make commas optional where the parsing would remain unambiguous.

In any case, I'm really looking forward to ExtraCommas getting implemented, as I keep toying with implementing it myself every now and then, especially every time I run into this problem with the [] and {} enumerations... import/export lists too, but that bothers me less than the [] and {} situations for some reason.

austin resigned from this revision.Nov 9 2017, 5:42 PM