[Patch] Support Python-style tuple sections

[batterseapower]

Support Python-style tuple sections:

>>> (, True, "Hello", ) 1 "World"
(1, True, "Hello", "World")

The attached patches implement this syntax for both boxed and unboxed tuples, and include tests and documentation.

[simonpj]

Thanks for this. It seems to me to be a simple and consistent generalisation of Haskell's existing notion of "sections" and I can see that it'd be useful sometimes.

Does anyone else have an opinion?

Simon

[isaacdupree]

yeah, I remember trying to do this a few years ago and being disappointed that it didn't work. So I think it's a good idea. (except that adding syntax always has hazards. Will somebody want list-literals with sections like this? Er admittedly I've never actually wanted that, so maybe not.)

[batterseapower]

I proposed list sections to Neil in an email, and I reproduce his reply here:

I tried to think of why the list section wouldn't be useful. The
reason I decided is that for lists we have the singleton list (we lack
the singleton tuple) and list concatenation (there is no tuple concat,
but it could be added). Using these you can often encode list
sections:

map (:1)

So I think thats the reason no one needs list sections.

Thanks

Neil

Seems reasonable to me!

[NeilMitchell]

It should be noted that Python style tuple sections are slightly different, in Python (1,) is the 1-element tuple. This patch doesn't implement that, but instead the reasonably sensible generalisation: (a,,c,) ==> \b d -> (a,b,c,d)

I really like this feature, I often do map ((,) 1) xs or map (\x -> (1,x)) xs, both of which are a bit too clunky. This feature would fix both of them.

[nominolo]

I like the idea as well, but I wonder if proposing a new LANGUAGE to a wider audience (libraries@ or haskell-cafe@) might give better feedback.

[simonmar]

This was controversial when it was brought up for Haskell'. I can't find any discussion online, but the committee  straw poll shows that the majority were against it. This doesn't necessarily mean that people disliked the extension: it's more likely because in Haskell prime we were/are more concerned with standardising existing extensions than inventing new ones.

Personally, I'd like to see this go into GHC. I don't think it does any harm, it's easy to explain, and it's often very useful.

[simonpj]

I agree. I'm going to put this in. Just working on the patch now.

Simon

[simonpj]

OK, it's done. Thanks to Max for doing the first version.

Wed Jul 22 23:38:59 PDT 2009  simonpj@microsoft.com
  * Add tuple sections as a new feature
  Ignore-this: d42a26fc1efff112b852b5c1135c1746
  
  This patch adds tuple sections, so that
  
  	(x,,z)  means   \y -> (x,y,z)
  
  Thanks for Max Bolingbroke for doing the hard work.
  
  In the end, instead of using two constructors in HsSyn, I used
  just one (still called ExplicitTuple) whose arguments can be
  	Present (LHsExpr id)
  or	Missing PostTcType
  
  While I was at it, I did a bit of refactoring too.
  

    M ./compiler/deSugar/Coverage.lhs -6 +10
    M ./compiler/deSugar/DsArrows.lhs -10 +5
    M ./compiler/deSugar/DsExpr.lhs -10 +20
    M ./compiler/deSugar/DsListComp.lhs -2 +2
    M ./compiler/deSugar/DsMeta.hs -2 +4
    M ./compiler/deSugar/DsUtils.lhs -19 +13
    M ./compiler/deSugar/Match.lhs -15 +18
    M ./compiler/hsSyn/Convert.lhs -1 +1
    M ./compiler/hsSyn/HsExpr.lhs -23 +38
    M ./compiler/hsSyn/HsUtils.lhs -5 +17
    M ./compiler/main/DynFlags.hs +2
    M ./compiler/parser/Parser.y.pp -10 +27
    M ./compiler/parser/RdrHsSyn.lhs -3 +4
    M ./compiler/rename/RnExpr.lhs -5 +17
    M ./compiler/rename/RnSource.lhs -1
    M ./compiler/typecheck/TcExpr.lhs -17 +27
    M ./compiler/typecheck/TcGenDeriv.lhs -8 +6
    M ./compiler/typecheck/TcHsSyn.lhs -10 +8
    M ./compiler/typecheck/TcTyClsDecls.lhs -1 +1
    M ./compiler/types/Generics.lhs -4 +4
    M ./compiler/types/TypeRep.lhs +1
    M ./docs/users_guide/glasgow_exts.xml +38