[Haskell-cafe] list comprehansion performance has hug different

Junior White efiish at gmail.com
Wed Jan 30 13:02:15 CET 2013


On Wed, Jan 30, 2013 at 5:51 PM, Doaitse Swierstra <doaitse at swierstra.net>wrote:

> From the conclusion that both programs compute the same result it can be
> concluded that  the fact that you have made use of a list comprehension has
> forced  you to make a choice which should not matter, i.e. the order in
> which to place the generators. This should be apparent from your code.
>
> My approach is such a situation is to "define your own generator"
> (assuming here that isSafe needs both its parameters):
>
> pl `x` ql = [ (p,q) | p <-pl, q <- ql]
>
> queens3 n =  map reverse $ queens' n
>     where queens' 0       = [[]]
>
>           queens' k       = [q:qs | (qs, q) <- queens' (k-1) `x` [1..n],
> isSafe q qs]
>           isSafe   try qs = not (try `elem` qs || sameDiag try qs)
>
>           sameDiag try qs = any (\(colDist,q) -> abs (try - q) == colDist)
> $ zip [1..] qs
>
> Of course you can make more refined versions of `x`, which perform all
> kinds of fair enumeration, but that is not the main point here. It is the
> fact that the parameters to `x` are only evaluated once which matters here.
>

Thanks for your reply!  I must learn more to fully understand what's going
on inside the list comprehension.
But when I frist learn Haskell, it says sequence doesn't matter, but now it
is a big matter, can compiler do some thing for us? I think this behavior
is not friendly to newbies like me, I will take a very long time to work
through it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130130/622d35c5/attachment.htm>


More information about the Haskell-Cafe mailing list