Opened 5 years ago

Closed 5 years ago

#3377 closed feature request (fixed)

[Patch] Support Python-style tuple sections

Reported by: batterseapower Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.10.4
Keywords: Cc: ben@…, ndmitchell@…, batterseapower@…, pumpkingod@…, MartijnVanSteenbergen
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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.

Attachments (2)

TupleSections-compiler.patch (34.5 KB) - added by batterseapower 5 years ago.
TupleSections-testsuite.patch (12.0 KB) - added by batterseapower 5 years ago.

Download all attachments as: .zip

Change History (13)

Changed 5 years ago by batterseapower

Changed 5 years ago by batterseapower

comment:1 Changed 5 years ago by simonpj

  • Difficulty set to Unknown

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

comment:2 Changed 5 years ago by 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.)

comment:3 Changed 5 years ago by 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!

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by 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.

comment:6 Changed 5 years ago by BenMoseley

  • Cc ben@… added

comment:7 Changed 5 years ago by pumpkin

  • Cc pumpkingod@… added

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by MartijnVanSteenbergen

  • Cc MartijnVanSteenbergen added

comment:10 Changed 5 years ago by simonpj

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

Simon

comment:11 Changed 5 years ago by simonpj

  • Resolution set to fixed
  • Status changed from new to closed

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
Note: See TracTickets for help on using tickets.