为什么在 fmap 方法参数之后评估 getArgs？答案

【问题标题】：Why is getArgs evaluated after fmap method argument?为什么在 fmap 方法参数之后评估 getArgs？
【发布时间】：2019-01-04 10:47:23
【问题描述】：

为什么getArgs 在fmap 的方法参数之后被评估？

main::IO()
main=do
    fpath<-fmap head getArgs
    putStrLn fpath

我得到错误： Exception: Prelude.head: empty list 似乎它适用于尚未计算的东西。

我首先假设这可能是关于懒惰的另一条规则，我不知道是 Haskell 的新手，所以我尝试了：
a<-fmap head getLine # 没问题
a<-fmap head (readFile [filename]) # 再次没问题

那么为什么getArgs 是特殊的，之后才被评估？

【问题讨论】：

getArgs 不会以任何特殊方式进行评估。它只是返回一个空列表。你真的是带着一些论点来启动你的程序吗？请注意，从文档中，返回的列表不包括程序名称，而只包括命令行参数。
如果你得到一个关于getArgs返回的列表为空的异常，那几乎可以肯定是因为它是为空的，而不是因为评估顺序。当 head 应用于尚未评估的参数时，将在该点评估该参数 - 它不会只是声称该参数是一个空列表，而实际上它可能不是。懒惰不是这样运作的。
在 Haskell 中，不直接评估参数（不是从左到右，或者至少不是作为一般规则）。它是惰性求值的。

【解决方案1】：

如果head 在空列表上中断，则意味着getArgs 确实已经评估，因为值[] 是由head 生成并匹配的。

很可能你从ghci 运行你的程序，它可以产生这样的效果。由于head 不安全，您应该检查列表中是否存在至少一个参数。

【讨论】：

我确实从 ghci 运行它，我希望系统会提示我输入参数
“很可能你是从 ghci 运行你的程序的，它会产生这样的效果。”你这是什么意思？
@sepp2k 如果你有一个加载到交互式环境中的haskell 程序，并手动调用main，它将不接收任何参数（因为实际上没有提供任何参数）。你can provide those arguments using :main.