List layouts

Hi!

I want to propose a new GHC extension called ListLayouts. It's basically a do-notation for pure lists and was initially meant to offer an alternative to the current do-notation monad "exploits" as seen in libraries like e.g. blaze-html, but it is of course a lot more general.

What it'd look like in practice shows this little example:

{-# LANGUAGE ListLayouts #-}

import Data.Monoid

main :: IO ()
main = mapM_ putStrLn $++
  "These are list layouts."
  "Let me know what you think. :)"

allFalse :: All
allFalse = mconcat $++
  All True
  let f = All True
      t = All False
  t
  f

This simply translates to (a : let b = c in (d : ... )) etc. I already started working on this extension and the above example already works:

» nils@n-sch.de. ../inplace/bin/ghc-stage2 LISTLAYOUT-TEST.hs --interactive
GHCi, version 7.5.20111229: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main             ( LISTLAYOUT-TEST.hs, interpreted )
Ok, modules loaded: Main.
*Main> allFalse
All {getAll = False}
*Main> :main
These are list layouts.
Let me know what you think. :)
*Main>

ListLayouts currently support two statements, regular expressions (i.e. list elements) and let bindings. It could be thought to add the .. notation thing and maybe even comprehension notations, e.g.:

ex = $++
  1
  2..5
  x  | x <- [6..], x <= 10
  11 | False

This should result in the list [1,2,3,4,5,6,7,8,9,10]. Adding these features to the current existing code should be pretty much straight forward.

In my opinion this extension would fit in nicely, as it is kind of the counterpart to monad comprehensions (which practically add list notation to monads). It shouldn't be necessary to make it any more general (e.g. use monoids, semigroups or any other, potentially new, type class instead of lists) since almost every list-like datatype has it's own fromList function (Data.Map.fromList, Data.Set.fromList, Data.Monoid.mconcat etc.) and using functions instead of class instances is a lot more convenient in most cases, too.

So please let me know what you think about this idea and whether or not you would be willing to add this extension to GHC. I would, of course, be willing to do all the coding.

Trac metadata

Trac field	Value
Version	7.2.1
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture