On Sun, 2009-07-19 at 23:07 +0100, Thomas Schilling wrote:
> 2009/7/19 Max Bolingbroke <batterseapo...@hotmail.com>
> >
> > Dear Cafe,
> >
> > For fun, I spent a few hours yesterday implement support for this
> > syntax in GHC, originally propsed by Koen Claessen:
> >
> > >>> [k, "=", v, " " | (k, v) <- [("foo", "1"), ("bar", "2")]
> > ["foo", "=", "1", " ", "bar", "=", "2", " "]
> 
> Given that this can easily be simulated via:
> 
> >>> [ x | (k, v) <- [("foo", "1"), ("bar", "2")], x <- [k, "=", v, " "]]
> ["foo","=","1"," ","bar","=","2"," "]
> 
> I believe that the added syntax (which every complete tool operating
> on Haskell code would have to support) is not worth its price.

Except that it's ugly compared to the proposed extension. With the
extension you can put things in the same, right place:

renderGhcOptions opts =
     ghcOptExtraPre opts

  -- source search path
  ++ [ "-i"      | not (null (ghcOptSearchPath opts)) ]
  ++ [ "-i", dir | dir <- ghcOptSearchPath opts ]

or using your syntax:

  ++ [ opt | dir <- ghcOptSearchPath opts
           | opt <- [ "-i", dir ] ]

or another not-so-nice alternative:

  ++ concat
     [ [ "-i", dir ] | dir <- ghcOptSearchPath opts ]


When looking down a bunch of these cases, using the extension means we
can put the most important bit --- the flag names and arguments --- in
the same position rather than sometime having to put them at the end in
an extra generator, or having to use extra brackets and a concat.

So yes you can certainly simulate it but it does not read nearly so
well.

Duncan

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

Reply via email to