为什么Haskell中的主function没有任何参数？

Question

我对 Haskell 有点陌生。 我已经完成了一个或两个教程，但我没有太多经验。

Haskell 中的每个 function 都是纯粹的，这就是为什么没有 IO-monad 就不能有任何 I/O。 我不明白的是，为什么程序参数也必须是 IO 动作？ 参数像 function 一样传递给程序。 为什么不能像 function 那样访问参数？

说清楚，我不明白，为什么主要的 function 必须看起来像这样

main :: IO()
main = do
    args <- getArgs
    print args

而不是这个

main :: [String] -> IO()
main args = do
    print args

我看不出有任何原因，而且我在谷歌上找不到答案。

Answer 1

这是一种语言设计选择。 两种方法都不比另一种更好。

Haskell 可以设计为具有任何一种main电源。

当确实需要程序 arguments 时，将它们作为 function arguments 传递给main会更方便。

当不需要程序 arguments 时，将它们传递给main有点麻烦，因为我们需要编写更长的类型，并且需要额外的_来丢弃[String]参数。

此外， getArgs允许人们在程序中的任何位置（在IO内）访问程序 arguments ，虽然将它们传递给main ，但可能不太方便，因为随后将被迫在程序中传递它们，这可能很不方便。

（题外话）对于它的价值，很久以前当我发现在 Java 中我们有void main()而不是int main()时，我和你的反应相似，就像在 C 中一样。 然后我意识到在大多数程序中我总是写return 0; 最后，所以总是要求它是没有意义的。 在 Java 中，这是隐含的默认值，当我们真的需要返回其他内容时，我们使用System.exit() 。 即使这是在以前的语言（在这种情况下为 C）中完成的方式，新的语言也可以选择一种新的方式来提供相同的功能。

Answer 2

我倾向于同意 chi 的回答，没有明显令人信服的理由必须这样做，所以它真的归结为很久以前由一小群人做出的某种主观判断。 不能保证背后会有任何特别令人满意的理由。

这是我想到的一些推理（这可能是原始设计师当时想到的，也可能不是，甚至会同意）。

我们真正喜欢做的是：

main :: Integer -> String -> Set Flag -> IO ()

（对于将 arguments 和 integer、一个字符串和一组标志作为命令行的一些假设程序）

能够编写小型命令行程序，就好像它们只是命令行 arguments 的 function 一样很棒，但这需要操作系统（或至少是 shell）来理解 ZA59B783BA97FCDBB85891DFEDB2E 程序中使用的类型解析它们（以及如果解析失败，或者如果没有足够的 arguments 等，该怎么办）。 这不会发生。

也许我们可以编写一个包装器来做到这一点。 它可以负责将原始字符串命令行 arguments 解析为 Haskell 类型并生成错误消息（如果需要），然后为我们调用main 。 但是等等，我们可以做到这一点！ 我们只需要调用包装器main （并重命名我们之前调用的main ）！

关键是：如果您想将您的程序视为外部输入的简单 function ，那很有意义，但main不是 function 。 main作为一个包装器工作得更好，它处理通过无类型接口接收输入并调用“真的是”你的程序的 function 的丑陋细节。

强制您在设置代码中包含对getArgs的调用，这使得处理命令行 arguments 的工作更加明显，而不仅仅是访问它们，并且可能会促使您编写一些额外的处理代码，而不仅仅是编写main (arg1: arg2: _) = do stuffWith arg1 arg2 。

此外，将我们拥有的界面转换为您想要的界面非常简单：

import System.Environment

main = real_main =<< getArgs

real_main :: [String] -> IO ()
real_main args = print args

所以你可以随心所欲地拥有它！