RE: group keyword with TransformListComp

I agree it's undesirable. It would be great if someone could lead a discussion leading to a better alternative. Perhaps the same process that we use for libraries would be appropriate here. http://www.haskell.org/haskellwiki/Library_submissions Namely: make a proposal, give an expiry date, lead discussion. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Neil Mitchell | Sent: 29 June 2009 20:59 | To: Max Bolingbroke | Cc: glasgow-haskell-users@haskell.org | Subject: Re: group keyword with TransformListComp | | Hi, | | The question of syntax is always something that provokes intense | discussion. My interest (and concern) with the choice of syntax in | this case is three-fold: | | 1) I want HLint to turn on as many Haskell extensions as possible when | parsing, with the trade off that they don't break a massive number of | existing programs. For each extension I have weighed up the number of | programs that will get broken (because the extension steals previously | valid syntax), vs the number that will be parsed (how popular the | extension is). I've erred on the side of enabling extensions, so am | happy to accept changes in meaning for a!b and $(a). Almost all | extensions get turned on, with the exception of TransformListComp, | which even breaks the source code to HLint itself - something no other | extension does. It seems the syntax stolen is far too much, especially | when compared to other extensions. | | 2) I want to use TransformListComp in HLint. In particular, I have a | nested pile of group/sort surrounding a list comp that would be | perfect for TransformListComp. However, as it stands, I can't even | enable the extension without that file breaking. I could qualify all | the uses of group, but that seems too much hassle. I'd really like to | enable the extension (without modification), and then start converting | each group-like list-comp one at a time. | | 3) We'll never be able to make TransformListComp enabled in future | versions of Haskell' since we break too many programs. It's an | extension that is destined forever to remain only an extension. That | seems like a lonely life for an extension. | | Thanks | | Neil | | On Sat, Jun 27, 2009 at 11:52 AM, Max Bolingbroke wrote: | > Hi, | > | > I agree this is annoying. It was hard to find syntax which was both | > meaningful and currently unused, so we settled on this instead. As | > Simon says, suggestions are welcome! | > | > Note that group *should* be parsed as a special id, so you can still | > import D.L qualified and then use dot notation to access the function. | > | > Cheers, | > Max | > | > | > 2009/6/21 Neil Mitchell : | >> Hi, | >> | >> The TransformListComp extension makes group a keyword. Unfortunately | >> group is a useful function, and is even in Data.List. Thus, | >> Data.List.group and TransformListComp are incompatible. This seems a | >> very painful concession to give up a nice function name for a new | >> extension. Is this intentional? Here's an example: | >> | >>> $ cat GroupKeyword.hs | >>> {-# LANGUAGE TransformListComp #-} | >>> module GroupKeyword where | >>> | >>> a = map head $ group $ sort [1..100] | >>> $ ghci GroupKeyword.hs | >>> GHCi, version 6.10.2: http://www.haskell.org/ghc/  :? for help | >>> Loading package ghc-prim ... linking ... done. | >>> Loading package integer ... linking ... done. | >>> Loading package base ... linking ... done. | >>> [1 of 1] Compiling GroupKeyword     ( GroupKeyword.hs, interpreted ) | >>> | >>> GroupKeyword.hs:4:15: parse error on input `group' | >>> Failed, modules loaded: none. | >>> Prelude> | >> | >> There are some places I'd like to use TransformListComp, but I often | >> want to use group in the same module. | >> | >> Thanks | >> | >> Neil | >> | > | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users