On 05/17/2013 06:32 PM, Johan Tibell wrote:

On Fri, May 17, 2013 at 9:17 AM, Garrett Mitchener < garrett.mitchener@gmail.com> wrote:

...

Anyway, this is a "paper cut" in the language that has been bugging me for a while, and since there's now a call for suggestions for Haskell 2014, I thought I'd ask about it.

I've also thought about this issue and I agree with Garrett, allowing that trailing comma (or semicolon) would help readability*. If it doesn't work with tuples, perhaps we could at least do it with lists and records?

Multiline tuples don't seem all that common, so +1 on that from me.

On Fri, May 17, 2013 at 02:04:44PM -0400, Edward Kmett wrote:

My main concern is its a really weird corner case for the grammar to remember for tuple sections and it does have very weird grammar specification issues.

Tuple sections could look like (True, _) rather than (True,) Does anyone know how common tuple sections are, incidentally? They've been around since GHC 6.12, so it would be interesting to know if people are actually using them.

I really have no objection to it for the other cases. It'd make export lists cleaner,

Actually, you are already allowed an extra trailing comma in import and export lists.

maybe a few other cases, but how often can you really say you can meaningfully comment out one field of a tuple have have the surrounding code make any sense?

It happens occasionally, especially when simplifying code while debugging. Commenting out list items is much more common, though. I'd be in favour of allowing a trailing or leading comma anywhere that comma is used as a separator. TupleSections would need to be changed or removed, though. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

I use them sometimes, but would do that much more if they didn't require adding an extension. Roman * Edward Kmett [2013-05-17 15:24:27-0400]

I personally use tuple sections a fair bit, though admittedly mostly for simple (,a) or (a,) cases.

On Fri, May 17, 2013 at 3:01 PM, Ian Lynagh wrote:

...

On Fri, May 17, 2013 at 02:04:44PM -0400, Edward Kmett wrote:

...

My main concern is its a really weird corner case for the grammar to remember for tuple sections and it does have very weird grammar specification issues.

Tuple sections could look like (True, _) rather than (True,)

Does anyone know how common tuple sections are, incidentally? They've been around since GHC 6.12, so it would be interesting to know if people are actually using them.

...

I really have no objection to it for the other cases. It'd make export lists cleaner,

Actually, you are already allowed an extra trailing comma in import and export lists.

...

maybe a few other cases, but how often can you really say you can meaningfully comment out one field of a tuple have have the surrounding code make any sense?

It happens occasionally, especially when simplifying code while debugging.

Commenting out list items is much more common, though.

I'd be in favour of allowing a trailing or leading comma anywhere that comma is used as a separator. TupleSections would need to be changed or removed, though.

Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

On Tue, Aug 13, 2013 at 09:47:49PM +0100, Simon Marlow wrote:

On 17/05/13 20:01, Ian Lynagh wrote:

...

I'd be in favour of allowing a trailing or leading comma anywhere that comma is used as a separator. TupleSections would need to be changed or removed, though.

The type constructors for tuples look like (,,,), so they would have to be a special case.

Ugh, true.

I'd much rather leave tuples out of it: the precise number of commas in a tuple is significant.

It would be rather unpleasant to have [1,2,3,] :: [Int] (1,2,3,) :: Int -> (Int, Int, Int, Int) Thanks Ian

I think Tilmann's way is the right way (because it is very clear when a comma is missing since they align, unlike trailing commas), although the original proposal is the popular way. I would rather get rid of commas altogether (make them optional actually) and just have a newline + consistent indentation signal a new list item: coffee-script does that. On Fri, May 17, 2013 at 11:23 AM, Tillmann Rendel < rendel@informatik.uni-marburg.de> wrote:

Hi,

Garrett Mitchener wrote:

...

There's a weird idiom that I see all the time in Haskell code where coders put commas at the beginning of lines:

data Thing = Thing { x :: Int ,y :: Int ,z :: Int ,foo :: String } ...

items = [ "red" ,"blue" ,"green" ]

(I don't think this is valid Haskell. The closing } and ] should be more indented).

I like to put commas at the beginning of lines, because there, I can make them line up and it is visually clear that they are all at the same nesting level. I like how the commas look a bit like bullet points. For example, I would write:

items = [ "red" , "blue" , "green" ]

Could we extend Garett's proposal to also allow prefixing the first element of a list with a comma, to support this style:

items = [ , "red" , "blue" , "green" ]

Allowing an optional extra comma both at the beginning and at the end would allow programmers the choice where they want to put their commas.

Tillmann

______________________________**_________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-primehttp://www.haskell.org/mailman/listinfo/haskell-prime

Greg Weber wrote: I would rather get rid of commas altogether (make them optional actually) and just have a newline + consistent indentation signal a new list item: coffee-script does that.

That would go well together with allowing extra commas, because in explicit block syntax, we can have extra semicolons. Ben Millwood wrote:

This looks a bit too much like a GADT to my eyes:

data Point = MkPoint x :: Rational y :: Rational

I fear that this is confusing, because so far, layout is always introduced by a keyword. But here, layout is introduced by an identifier. I suspect this is also what makes problems below for update syntax etc.

But I suppose pattern-matching, update syntax and so forth would probably still have to use explicit braces and commas. That inconsistency is probably a bit unpleasant.

I feel that record (definition | matching | literals | update) should all use the same syntax.

I'd say import and export lists at least are probably fine with a layout-based rule.

What about list literals? items = new-keyword-here "red" "blue" "green" Again, I don't see how that can work out without introducing a keyword. Maybe reusing "data" would work: items = data "red" "blue" "green" :) Tillmann