New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ExtraCommas (was: Trailing and leading commas in sub-export lists) #87

Open
wants to merge 11 commits into
base: master
from

Conversation

Projects
None yet
@parsonsmatt

parsonsmatt commented Oct 30, 2017

Rendered.

@andrewthad

This comment has been minimized.

Contributor

andrewthad commented Oct 30, 2017

The code block are currently really messed up, making the proposal difficult to read.

@parsonsmatt

This comment has been minimized.

parsonsmatt commented Oct 30, 2017

Thanks for pointing that out 😄

@andrewthad

This comment has been minimized.

Contributor

andrewthad commented Oct 30, 2017

I'm +1 on this proposal, although it probably should require a language pragma. One thing this would help me with is that I'll often have something like this:

module Foo
  ( -- * Types
    Foo
  , Bar
    -- * Functions
  , mkFoo
  ) where

If I decide that I want to flip the order of Foo and Bar in the export list, I have to fiddle with the commas. The proposal would help ease this (incredibly minor) inconvenience.

@isovector

This comment has been minimized.

isovector commented Oct 30, 2017

Does this affect constraint tuples and lists as well? I'd prefer for the same comma semantics across the board if possible.

@andrewthad

This comment has been minimized.

Contributor

andrewthad commented Oct 31, 2017

@isovector I'm not totally sure about this, but constraint tuples might be totally out of the question. Supporting normal tuples, at both the type and the value level, would be bad, since in the presence of the TupleSections extension, it would make partially applied tuples ambiguous. I'm not totally sure about this, but I think that constraint tuples, defined in GHC.Classes, are the same thing as type-level tuples, which would make them extending this extension to them problematic because it would required that it be extended to type-level tuples as well.

@parsonsmatt

This comment has been minimized.

parsonsmatt commented Oct 31, 2017

@hvr noted that this has been discussed previously in the Phabricator ticket. I'm going to copy what he posted there:

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.

@isovector It would appear that allowing this for constraints was talked about favorably.

@mgsloan

This comment has been minimized.

mgsloan commented Oct 31, 2017

Agreed with @isovector , nearly all usages of commas and semicolons should be consistent with this decision. The reasoning about CPP here is good, but extends equally well to other delimited sequences in Haskell. Beyond just CPP, it is extremely convenient for code manipulation. Things can be written such that they can be copied / reordered without corner cases for the starts or ends. This is pretty common practice in the JavaScript codebases I've worked on (I know, perhaps emulating JavaScript is not the best way to argue in favor of this, but this is really convenient in practice).

It's curious to me that, in a way, we already have this for case statements, do-notation (without curlies), value / type applications, pattern constructor arguments, etc, because they are delimited by whitespace, and it is allowed to be trailing and leading. So, I think it would be uniform for all sequence like things to allow trailing and leading delimiters

Tuples can be the rare exception, due to TupleSections. It would be way too confusing to have these two extensions give different meanings to the same syntax. I think this is fine, I don't think would find much use there anyway. If you are CPP-ing your tuples, or planning on your tuples being frequently extended or re-ordered, you probably shouldn't be using tuples.

So, in summary I totally agree with the proposal quoted above by @parsonsmatt . At once, it'd be a shame if trying to do the big change meant that nothing gets merged here. Perhaps we could just try it out in the context of extra commas in exports? Would rather avoid the proliferation of extensions, though..

@tfausak tfausak referenced this pull request Oct 31, 2017

Merged

Issue 79 #122

@mohsen3

This comment has been minimized.

mohsen3 commented Nov 1, 2017

With {-# LANGUAGE TupleSections #-} enabled, (,1,) is the same as \x y -> (x, 1, y). Why [,1,] should have a totally different meaning rather than \x y -> [x, 1, y]? I personally prefer a more consistent syntax rather than a convenient one.

@parsonsmatt

This comment has been minimized.

parsonsmatt commented Nov 6, 2017

With {-# LANGUAGE TupleSections #-} enabled, (,1,) is the same as \x y -> (x, 1, y). Why [,1,] should have a totally different meaning rather than \x y -> [x, 1, y]? I personally prefer a more consistent syntax rather than a convenient one.

This is a great point. The proposal, as it stands, is only concerned with (at least) export sublists. Including import sublists (for trailing/leading commas) and import/export lists (for leading commas) seems to have high support, and would make the language both more convenient and more consistent (given that import/export lists already support trailing commas).

Adding leading/trailing comma support to other list forms is not part of this specific proposal.

@hvr

This comment has been minimized.

hvr commented Nov 6, 2017

import/export lists (for leading commas) seems to have high support

in that case, let me state that I won't support this proposal unless it also covers the rest of the ExtraCommas extension (not the least so we don't end up with lots of super granular ExtraCommasExportsImport, ExtraCommasLists, ExtraCommasConstraints, ExtraCommasFixityDecls etc language pragmas) which as far as I'm concerned was already considered greenlighted back in 2014, so the only thing missing from my POV is an ExtraCommas patch we can review/discuss/fine-tune ;-)

Btw, if it's only TupleSections that are in the way, maybe we should consider deprecating TupleSections ... ;-)

@nomeata

This comment has been minimized.

Contributor

nomeata commented Nov 6, 2017

Btw, if it's only TupleSections that are in the way, maybe we should consider deprecating TupleSections ... ;-)

There might not be precedence, but we could discuss whether we allow incompatible language extensions. After all, they are opt-in and for experimentation, so I giving the users an exclusive choice between ExtraCommas (which then apply consistently and pervasively) and TupleSections might not be too bad.

I am, however, concerned about (,) as the non-section prefix-form of the tuple constructor.

@mgsloan

This comment has been minimized.

mgsloan commented Nov 6, 2017

Hmm, making TupleSections exclusive with ExtraCommas seems fairly reasonable. There is at least some precedent for choice of extension changing the meaning of code. For example, DeriveAnyClass vs GeneralizedNewtypeDeriving gives different meaning to deriving clauses (btw in practice this is really quite annoying and I often need to remove DeriveAnyClass). I'd prefer avoiding it, because now I need to know which one is enabled when looking at a fragment of code. Say I jump into the middle of a module, now I might need to scroll to the top or open the cabal file to figure out what it really means.

I am, however, concerned about (,) as the non-section prefix-form of the tuple constructor.
 1

I think it's fine to allow special interpretations when there are only commas and no elements. It is particularly obvious that these are different if there is a rule that you can either have a leading comma or a trailing comma, but not both. When these are used, it means there is a single comma coming after each element, or a single comma after each element. If there are no elements, then there are no commas.

Maybe I shouldn't paint the bikeshed on this, but how about allowing [,,] to mean (\x y z -> [x, y, z])? Perhaps not with this extension, but would be more consistent.

Style guides suggest trailing commas for multi-line enumerations
the previous wording sounded as if `(a,b,c,)` was recommended, which is not the case for the majority of the cited style guides.
@gbaz

This comment has been minimized.

gbaz commented Nov 10, 2017

TupleSections are super convenient and I'd hate to lose them to get this. I think we should choose to have ExtraCommas apply to everything but tuples and leave tuples extra special.

In my mind this makes perfect sense because an n-tuple is absolutely different than an n+1-tuple or an n-1 tuple, but a list of n elements is effectively the same as a list of n+1 or n-1 elements. (typewise)

@nomeata

This comment has been minimized.

Contributor

nomeata commented Nov 10, 2017

In my mind this makes perfect sense because an n-tuple is absolutely different than an n+1-tuple or an n-1 tuple, but a list of n elements is effectively the same as a list of n+1 or n-1 elements. (typewise)

That is a pretty convincing argument.

@aaronchall

This comment has been minimized.

aaronchall commented Feb 20, 2018

It would seem that the Haskell room on Stack Overflow supports this proposal as well: https://chat.stackoverflow.com/transcript/message/41311833#41311833

@parsonsmatt

This comment has been minimized.

parsonsmatt commented Feb 20, 2018

Ah, I knew there was something lurking in my todo list!

Alright, so based on the conversation here, we have:

  • Some support and opposition for the proposal in it's current state
  • Strong support for the proposal in an extended state (eg, making the comma rule work in many more places)

I will try to revise this proposal to include the extra cases for this soon.

@nomeata

This comment has been minimized.

Contributor

nomeata commented Apr 9, 2018

I will try to revise this proposal to include the extra cases for this soon.

Marking this proposal as such.

@parsonsmatt

This comment has been minimized.

parsonsmatt commented Apr 17, 2018

@hvr I'm curious about your opposition to a leading and trailing comma, eg: [, 1, 2, ]. Would you be willing to expand on that? It seems like a relatively innocuous thing to me, and explicitly forbidding it would require complicating the grammar somewhat.

@parsonsmatt

This comment has been minimized.

parsonsmatt commented Apr 17, 2018

@simonpj has one remaining unresolved question:

  1. What about repeated commas in the middle of a list?

I think that we should not allow repeated commas in the middle of the list.

@galenhuntington

This comment has been minimized.

galenhuntington commented Jun 24, 2018

I'm +1 on this idea, and in fact considered the feature useful enough that I wrote a pre-processor to support extra commas in my code. My solution to the conflict with TupleSections is that there has to be a newline between the final comma and the closing delimiter, as that was the primary use case of extra commas (for me), and I hope no one would put a newline in a tuple section like that. However, perhaps such a whitespace distinction wouldn't be acceptable for GHC.

@nomeata

This comment has been minimized.

Contributor

nomeata commented Aug 6, 2018

Let's keep looking for solutions, perhaps something indentation based to get rid of commas entirely?

(Brainstorming) How about this: Every comma-separated list may alternatively be written with as a bullet-prefixed list, using the unicode bullet (•). This is pretty, does clearly not clash with (,) and TupleSections, so it would uniformly apply to tuples, and it fits the bill of working perfectly with CPP and line-based editing.

Here are some examples from this thread and the proposal:

module Foo
  ( -- * Types
  • Foo
  • Bar
    -- * Functions
  • mkFoo
  ) where

module Foo (
  Foo(
#ifdef TESTING
    • Foo
#endif
#if USE_PATTERN_SYNONYMS
    • Pat1
    • Pat2
#endif
)

names = [
  • "foo"
  • "bar"
  • "baz
  ]

Yes, it’s only available to people who figure out how to enter unicode character … but otherwise it’s so pretty and elegant!

@parsonsmatt

This comment has been minimized.

parsonsmatt commented Aug 6, 2018

I like the bullet list idea but I detest Unicode syntax

@nomeata

This comment has been minimized.

Contributor

nomeata commented Aug 6, 2018

I like the bullet list idea but I detest Unicode syntax

Pick your poison – ASCII is just too limited for syntax innovations

@cartazio

This comment has been minimized.

cartazio commented Aug 6, 2018

@howtonotwin

This comment has been minimized.

Contributor

howtonotwin commented Aug 6, 2018

How about ;;? I’m taking this from sh, which has the syntax

case "$(cmd)" in
  [Yy]*) yes ;;
  [Nn]*) no ;;
esac

Compared to the Unicode bullet, this has the advantage of being ASCII. I also think it makes more sense inline: (a;; b;; c;; d;; ;; ;;) vs. (• a • b • c • d • •). Speaking of, should TupleSections be allowed if we use bullets/double-semicolons? The syntax seems to accommodate it.

In sh, the final ;; isn’t necessary, but I’ve never seen a script without it (it took looking at the spec for me to find that out). If we adopt it into Haskell and allow TupleSections, then I believe it’s necessary to require it.

module Foo
  ( -- * Types
    Foo;;
    Bar;;
    -- * Functions
    mkFoo;;
  ) where

module Foo (
  Foo(
#ifdef TESTING
    Foo;;
#endif
#if USE_PATTERN_SYNONYMS
    Pat1;;
    Pat2;;
#endif
  );;
)

names = [
  "foo";;
  "bar";;
  "baz";;
  ]

data Foo = Foo { foo :: Foo;;
                 bar :: Foo;;
                 baz :: Foo;;
               }
@tejon

This comment has been minimized.

tejon commented Aug 6, 2018

The bullet format looks great, but I too am highly nonplussed by the prospect of this being a Unicode-only feature. Despite the hate, is there actually any syntactic ambiguity with semicolons? They're already reserved, and I think (but have not proven) that the context is strictly differentiable from curlybrace-style line endings.

So, how about the bullet style with semicolon as the non-unicode alias?

module Foo
  ( -- * Types
  ; Foo
  ; Bar
    -- * Functions
  ; mkFoo
  ) where

module Foo (
  ; Foo(
#ifdef TESTING
    ; Foo
#endif
#if USE_PATTERN_SYNONYMS
    ; Pat1
    ; Pat2
#endif
    )
  )

names = [
  ; "foo"
  ; "bar"
  ; "baz
  ]
@goldfirere

This comment has been minimized.

Contributor

goldfirere commented Aug 7, 2018

Might I rephrase the idea around semicolons as this:

  1. In all the list forms mentioned in the original proposal, along with tuples, elements can be separated by either commas or semicolons.
  2. Commas and semicolons may not be mixed in a single list.
  3. Each comma has semantic meaning; these are never redundant.
  4. Semicolons may be repeated with no effect; they may also appear at the beginning and end of a list with no effect.

Commentary:

  • This new proposal treats tuples just like all other lists.
  • The name of a tuple remains, e.g., (,,). There is no conflict here.
  • Rule (3) allows for (but does not specify) tuple sections. It also allows for further tuple-section-like extensions.
  • Rule (3) implies that the current rule allowing for redundant commas in export lists would be deprecated (though we could make an exception).
  • I believe that the new uses of semicolons would be distinct from existing ones.
  • Redundant semicolons are currently allowed in do blocks, but not necessarily other blocks. (I tried GADTs; didn't try others.) This extends the idea of redundant semicolons.

Unless I've missed something, this all seems like having one's cake and eating it too. Yummy!

(Note: this post is meant to re-articulate ideas above; forgive me if this isn't what you had in mind.)

@nomeata

This comment has been minimized.

Contributor

nomeata commented Aug 7, 2018

That might likely work (although my sense of aesthetics is not pleased).

I assume that as you phrase the proposal, all ; are real semi-colons, and not layout-induced ones, right? Is there maybe a way of phrasing it so that one can, in some natural way, use layout for such lists?

@int-index

This comment has been minimized.

Contributor

int-index commented Aug 7, 2018

If the rule is that commas are never redundant, but semicolons can be, and one could choose which one to use for lists, tuple, export lists, etc, it seems suggestive that one should be able to also have comma-separated statements in do-notation and comma-separated fields in data declarations. If we can't incorporate these into the grammar as well, I'd say the rule is too ad-hoc.

@potato4444

This comment has been minimized.

potato4444 commented Aug 7, 2018

Wouldn't semicolons in tuples conflict with the currently proposed syntax for or patterns?

I wouldn't mind not having semicolons there for tuple patterns, but it would be inconsistent with everything else. (Also I'm not sure whether that would be a problem for the parser or not because I believe there are places that are ambiguous whether we are in a pattern or expression)

@winterland1989

This comment has been minimized.

winterland1989 commented Aug 7, 2018

Sorry, but I'd want to add a vote against this ; ) Reason:

  • Add to tuples will bring inconsistency with sections, otherwise, bring inconsistency with tuples.
  • Export list issue can be easily worked around. (not even sure if CPP on exports list is a good idea, why don't CPP the definition?).
  • Add extra cases in parser.
  • Need fixing education materials.

The benefit-cost ratio is just not enough to buy me, and I really want to keep Haskell as simple as it is.

BTW. Where are the haskell98 vintage folks?

@tejon

This comment has been minimized.

tejon commented Aug 7, 2018

not even sure if CPP on exports list is a good idea, why don't CPP the definition?

I recently did both at once!

@DanBurton

This comment has been minimized.

DanBurton commented Aug 7, 2018

not even sure if CPP on exports list is a good idea, why don't CPP the definition?

I recently did both at once!

@tejon, in that particular example, I believe you could instead put the CPP around an import:

#if MIN_VERSION_base(4, 11, 0)
import           Data.Functor             ((<&>))
#endif

And that would allow you to avoid the CPP on exports.

I think "don't use CPP on the export list" might be a guideline worth considering. Apologies that this is tangential to the proposal.

@mindreader

This comment has been minimized.

mindreader commented Aug 9, 2018

Rather than making them completely incompatible or make unpleasant allowances for each other, would it be possible to make this extension check whether TupleSections is enabled and simply disable its tuple aspects? And then just put a small blurb about it in the docs for each extension.

I would guess 99% of the time I wouldn't be using trailing commas on tuples anyways as I'm so much more excited about lists, import / export lists and records. And tuple sections are apparently way important to some people. This way everyone can get what they want.

@nomeata

This comment has been minimized.

Contributor

nomeata commented Aug 9, 2018

It is a possibility, but I find it violates the principle of least surprise if the meaning of (a,b,) changes in various ways. Before doing that, I’d rather just make it an error to use TupleSection and ExtraCommas together, and make people choose (on a per-module basis, so it’s not too bad, I guess).

@gridaphobe

This comment has been minimized.

gridaphobe commented Aug 9, 2018

Is there maybe a way of phrasing it so that one can, in some natural way, use layout for such lists?

I would find this much preferable to using semicolons just because they're free and somewhat similar to commas. Also, using layout to delimit list items sounds quite nice on its own!

@nomeata

This comment has been minimized.

Contributor

nomeata commented Aug 9, 2018

Also, using layout to delimit list items sounds quite nice on its own!

So what would that take? Probably just a layout herald (similar to do) that indicates that all following indent lines are to be interpreted as list items. I don’t have a good idea for what that would be, but let’s call it these for now.

The grammar would be extended with

lexp → do { stmts } | these { items }
items → exp ; items | ; items | (similar to stmts, including empty items)

And these would be added to the list of keywords that enable layout.

An expression these { e1 ; … : e2 } is understood to be e1 , … , e2 in all contexts where a comma-separated list make sense. Then we could write

module Foo
  ( these
  -- * Types
  Foo
  Bar
  -- * Functions
  mkFoo
  ) where

module Foo (
  Foo( these
#ifdef TESTING
    Foo
#endif
#if USE_PATTERN_SYNONYMS
    Pat1
    Pat2
#endif
  )
)

names = [ these
  "foo"
  "bar"
  "baz
  ]

They can be nested and mixed with commas, i.e. [ e1, e2, these {e3; e4; these {e5 ; e6} }, e7] is the same as [e1, e2, e3, e4, e5, e6, e7]

Of course the these herald is very ugly… And ideas?

(I still prefer •, though :-))

@tejon

This comment has been minimized.

tejon commented Aug 10, 2018

Oh, I rather like these, and I think I have a good paint swatch. Why stop at "similar to do"?

module Foo ( do |
  -- * Types
  Foo
  Bar
  -- * Functions
  mkFoo
  ) where

module Foo (
  Foo( do |
#ifdef TESTING
    Foo
#endif
#if USE_PATTERN_SYNONYMS
    Pat1
    Pat2
#endif
    )
  )

names = [ do |
  "foo"
  "bar"
  "baz
  ]

No new reserved syntax! This should be unambiguous if I am correct that:

  • no do block can ever be empty
  • in every relevant context, | ends a block if it is legal
  • there is no way do or | might be rebound (e.g. there can't be a quasiquoter named do)

It bears resemblance to comprehensions, quasiquoters, and rebindable syntax; but I think it's unique and obvious enough to avoid human confusion.

It plays nice with the nested format, too: [ e1, e2, do | {e3; e4; do | {e5 ; e6} }, e7]

-XCommaDo?

@harpocrates

This comment has been minimized.

harpocrates commented Aug 10, 2018

I'd like to voice my opposition to pretty much all of the ideas here except for the initial proposal (about which I feel neutral).

  • Syntax is a precious commodity - we shouldn’t waste it on things that can already be expressed in similar ways. Not having enough syntax at our disposal has historically led to some sub-par (read: potentially ambiguous) grammar choices (ex: bang patterns, type applications).
  • Too much syntax introduces a cognitive burden on the reader of code. I like to be able to quickly mentally parse the code I’m reading so that I can focus on figuring out what it is doing. The more syntactic gimmicks we add in, the tougher this gets.
  • I’m worried about bad parse error messages (esp. since things like semicolons show up all over the place already).
@int-index

This comment has been minimized.

Contributor

int-index commented Aug 10, 2018

I like the these suggestion, but without requiring outer [ ]. It would also allow people to stop abusing Writer to get do-notation for monoids, and instead write (with -XArgumentBlocks)

mconcat these
  Aaa
  mconcat these
    Fff
    Ggg
  Ccc
  Ddd
@BardurArantsson

This comment has been minimized.

BardurArantsson commented Aug 10, 2018

@nomeata

I’d rather just make it an error to use TupleSection and ExtraCommas together, and make people choose (on a per-module basis, so it’s not too bad, I guess).

This is the correct answer. It's a simple rule with no surprises for the unwary. It also completely avoids any discussion about unicode, new context-specific keywords, layout rules, etc. It's also in line with syntax from various other languages.

@parsonsmatt How about just specifying that and putting this to the committe? If it gets rejected then we'll at least know that that is not seen as an option by the committe.

@mgsloan

This comment has been minimized.

mgsloan commented Aug 10, 2018

The discussion here has changed my view a bit, I agree with @BardurArantsson that ExtraCommas should apply to all syntax that uses commas, and that the TupleSections and ExtraCommas combination should be disallowed. It seems quite straightforward and reuses expectations popularized by other languages.

One thing that is important to consider with each of these proposed syntaxes is "what happens when you copy in some code not intended for use with the extension?" (and a bit less importantly, vice versa). If copying code from a module with TupleSections to a module with ExtraCommas, it seems likely that you'd get a type error. Worst case, you could get different behavior for the copied code. That is not a great property.

One potential way to mitigate this issue would be to make it an error to write (x,) and (,x) with ExtraCommas on, and the error would mention that it looks like a tuple section. I'd guess that the majority of tuple sections usage is for pairs, and so I think this would help a lot of the potential confusion and behavior change when copying code around.

I must admit, this opinion is partially motivated by a dislike of TupleSections. It can be difficult to notice an extra comma, the syntax is not explicit enough for my taste. I do occasionally use them, but typically limited to (x, ), with an added space to try to make it more visually obvious.

I suspect that ship has sailed, It would be nice to have a tuple section syntax that was similarly concise but a bit more explicit. Actually, it'd be nice if section syntax in general was more explicit.

@simonmar

This comment has been minimized.

simonmar commented Aug 11, 2018

Having two mutually exclusive extensions would be a really bad idea. The ultimate goal for any extension is to be a part of a future language standard, so if we have two mutually exclusive extensions it guarantees that at least one of them is doomed. We should design extensions that are compatible, unless we're absolutely sure that we want to subsume or deprecate another extension, or we want to experiment with incompatible alternatives.

@aaronchall

This comment has been minimized.

aaronchall commented Aug 12, 2018

or we want to experiment with incompatible alternatives

I think that's the idea.

Strong support for the proposal in an extended state (eg, making the comma rule work in many more places)

Please include myself in that.

Coming from Python, I have found the optional trailing comma to be a very nice feature.

Python is constantly growing in popularity, and it has (wisely) adopted ideas from Haskell (such as list comprehensions). And I think users would say that adopting great features really improves the language.

As a new user, I find the prefixed comma jarring.

I'm excited to try this out when it becomes available.

@cartazio

This comment has been minimized.

cartazio commented Aug 12, 2018

@ChShersh

This comment has been minimized.

ChShersh commented Aug 13, 2018

Maybe it's possible to reduce scope of the proposal? I see that it focuses mostly on exports. But I would really appreciate minor changes to grammar of imports.

I'm working on Source Plugin smuggler that removes unused imports automatically. And I find it quite annoying that the following code is a valid Haskell code:

import Data.Bool (Bool,)

but this is no longer valid:

import Data.Bool (Bool (True,))

It would be really great if trailing commas were allowed inside data types in import lists as well!

There's an open GHC ticket about this problem:

@nomeata

This comment has been minimized.

Contributor

nomeata commented Aug 13, 2018

Yeah, that was the original proposal… and then feature creep happened.

But here is a work-around:

import Data.Bool (Bool (True), Bool (False), )

@bravit bravit added the Proposal label Nov 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment