[Haskell-cafe] Implicit concatenation in list comprehensions

Thomas Schilling nominolo at googlemail.com
Tue Jul 21 12:17:30 EDT 2009


I'm not convinced "ugly" is a good reason to add more complexity to
the language syntax.  I am not aware of a good metric to measure the
costs/beneficts of new syntactic constructs.  Part of the costs are
the number of tools that need to be adapted and the extend of their
loss of utility if they are not adopted.  Granted, we don't have that
many tools working on Haskell code, but perhaps the feature-creep is
part of the reason (cf. HaRe).  Sure, the eagerness of new features
added to Haskell (well, GHC mostly) is part reason of Haskell's
success.  Since we don't have an objective measure, all I can do is to
ask people to consider that new syntax is not as cheap as it many seem
to think it is.

2009/7/20 Duncan Coutts <duncan.coutts at worc.ox.ac.uk>:
> On Sun, 2009-07-19 at 23:07 +0100, Thomas Schilling wrote:
>> 2009/7/19 Max Bolingbroke <batterseapower at 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
>
>



-- 
Push the envelope.  Watch it bend.


More information about the Haskell-Cafe mailing list