列表理解中的表达式是否被冗余评估？

Question

let strings = ["foo", "bar", "baz"]
in  [filter (== char) (concat strings) | char <- "oa"]

GHC是否在char == 'o'时评估concat strings ，然后在char == 'a'时再次评估concat strings ？ 还是记得concat strings == "foobarbaz"供以后使用？

我意识到我可以通过重构此代码来避免这种不确定性，但是我对代码的编译方式很感兴趣。

Answer 1

GHC的评估可能远远少于9次。 实际上，它是这样做的，并且我们可以证明使用Debug.Trace.trace

module Main (main) where 
import Debug.Trace

x = let strings = ["foo", "bar", "baz"]
    in  [filter (== char) (trace "\nconcat strings\n" (concat strings)) | char <- "oaxyz"]

main = do
    print x

这里针对-O0评估“oaxyz”5次，针对-O1和-O2评估一次：

! 529)-> touch LC.hs ; ghc -O0 -o lc0 LC.hs 
[1 of 1] Compiling Main             ( LC.hs, LC.o )
Linking lc0 ...

(! 530)-> touch LC.hs ; ghc -O1 -o lc1 LC.hs 
[1 of 1] Compiling Main             ( LC.hs, LC.o )
Linking lc1 ...

(! 531)-> ./lc0; ./lc1; ./lc2

concat strings


concat strings


concat strings


concat strings


concat strings

["oo","aa","","","z"]

concat strings

["oo","aa","","","z"]

concat strings

["oo","aa","","","z"]

Answer 2

克里斯在回信中说的都是真的。 虽然您不能完全依赖要共享的表达式，但它是GHC共享它的有效优化，并且通常在启用优化时执行此操作。 然而，你可能不想依赖这个功能，如果你可以通过从lambda中提取concat调用来明确预期的共享，我就是这样。

将Debug.Trace.trace用于此目的是了解事物评估的时间和频率的好方法。

另一种选择是查看生成的核心代码。 对于这个程序：

main = print x

x = let strings = ["foo", "bar", "baz"]
    in  [filter (== char) (concat strings) | char <- "oa"]

让我们编译所有优化，然后查看结果代码：

$ ghc NrEval -fforce-recomp -ddump-simpl -dsuppress-all
[1 of 1] Compiling Main             ( NrEval.hs, NrEval.o )

==================== Tidy Core ====================
Result size of Tidy Core = {terms: 50, types: 54, coercions: 0}

main
main =
  print
    ($fShow[] ($fShow[] $fShowChar))
    (let {
       a_ssN
       a_ssN = unpackCString# "foo" } in
     let {
       a1_ssQ
       a1_ssQ = unpackCString# "bar" } in
     let {
       a2_ssT
       a2_ssT = unpackCString# "baz" } in
     let {
       a3_ssU
       a3_ssU = : a2_ssT ([]) } in
     let {
       a4_ssV
       a4_ssV = : a1_ssQ a3_ssU } in
     let {
       strings_ahk
       strings_ahk = : a_ssN a4_ssV } in
     letrec {
       ds_dsE
       ds_dsE =
         \ ds1_dsF ->
           case ds1_dsF of _ {
             [] -> [];
             : ds3_dsG ds4_dsH ->
               : (filter
                    (\ ds5_dsI -> == $fEqChar ds5_dsI ds3_dsG) (concat strings_ahk))
                 (ds_dsE ds4_dsH)
           }; } in
     ds_dsE (unpackCString# "oa"))

main
main = runMainIO main

我们可以看到，即使没有最佳化的列表理解已经脱到的（内联）应用程序map在ds_dsE 。 但是， concat strings_ahk保留在lambda（ ds1_dsF ）下，这意味着每次对函数进行求值时都会对其进行求值，即两次：一次在ds_dsE调用字符串"oa" ，一次在递归调用ds_dsE ds4_dsH 。

现在，让我们将结果与优化进行比较：

$ ghc NrEval -fforce-recomp -ddump-simpl -dsuppress-all -O
[1 of 1] Compiling Main             ( NrEval.hs, NrEval.o )

==================== Tidy Core ====================
Result size of Tidy Core = {terms: 89, types: 105, coercions: 9}

main9
main9 = unpackCString# "foo"

main8
main8 = unpackCString# "bar"

main7
main7 = unpackCString# "baz"

main6
main6 = : main7 ([])

main5
main5 = : main8 main6

main_strings
main_strings = : main9 main5

main4
main4 =
  \ ds_dsT ds1_dsS ->
    : (letrec {
         go_ato
         go_ato =
           \ ds2_atp ->
             case ds2_atp of _ {
               [] -> [];
               : y_atu ys_atv ->
                 let {
                   z_XtU
                   z_XtU = go_ato ys_atv } in
                 letrec {
                   go1_XtX
                   go1_XtX =
                     \ ds3_XtZ ->
                       case ds3_XtZ of _ {
                         [] -> z_XtU;
                         : y1_Xu6 ys1_Xu8 ->
                           case y1_Xu6 of wild2_atz { C# c1_atB ->
                           case ds_dsT of _ { C# c2_atF ->
                           case eqChar# c1_atB c2_atF of _ {
                             False -> go1_XtX ys1_Xu8;
                             True -> : wild2_atz (go1_XtX ys1_Xu8)
                           }
                           }
                           }
                       }; } in
                  go1_XtX y_atu
              }; } in
       go_ato main_strings)
      ds1_dsS

main3
main3 = unpackFoldrCString# "oa" main4 ([])

main2
main2 = showList__ $fShowChar_$cshowList main3 ([])

main1
main1 = \ eta_B1 -> hPutStr2 stdout main2 True eta_B1

main
main = main1 `cast` ...

main10
main10 = \ eta_Xp -> runMainIO1 (main1 `cast` ...) eta_Xp

main
main = main10 `cast` ...

在这里，我们可以看到发生了很多事情，但是特别是，对concat strings的调用已提升到顶层，并在编译时完全展开，从而导致main_strings指向串联的三元素字符串列表。 当使用go_ato调用main_strings时，这显然是共享的。

Answer 3

它将被评估两次。 GHC不记住 。 像这样列出理解desugar

 [term | x <- xs, y <- ys ...] -- I ignore guards

 do
  x <- xs
  y <- ys
  ...
  return term

与...相同

 flip concatMap xs $ \x -> flip concatMap ys $ \y -> ... [term]

所以，很显然， term将被计算l1 * l2 * l3 ... ln倍，其中li是长度i个名单。