python - 为什么 GHC 测试套件是用 Python 而不是 Haskell 编写的？

Question

我注意到 GHC(一种广泛使用的 Haskell 编译器)有一个用 Python 编写的测试套件，而不是用 Haskell 编写的(正如我天真地期望的那样)。这是什么来历？用不同的语言编写测试套件有什么特别的优势吗？

编辑:根据评论中的建议，我在 /r/haskell 中提出了这个问题.它现在生成了三个答案，我在下面引用了这些答案:

tathougies 说:

The test suite driver seems to be written in Python. Python is a good high-level scripting language.

It's like asking 'why does GHC use Make instead of haskell'? Probably because make is better at running shell programs with external dependency resolution built-in.

The tests themselves seem to be written in Haskell, verifying certain properties of the compiler and catching regressions. If they fail, it looks like the python driver is informed, and then would report the error to the user.

phadej 添加:

FWIW GHC's built system is being rewritten to use shake: the Haskell library.

eacameron 说:

I don't know. But GHC doesn't have the luxury of using Haskell the same way you and I do. It has to bootstrap using a previous version of itself and it wants to avoid dependencies. Python is a pretty light-weight requirement since most systems (except Windows) come with it built in.

Answer 1

commit介绍Python的消息解释了很多:

Revamp the testsuite framework. The previous framework was an experiment that got a little out of control - a whole new language with an interpreter written in Haskell was rather heavyweight and left us with a maintenance problem.

So the new test driver is written in Python. The downside is that you need Python to run the testsuite, but we don't think that's too big a problem since it only affects developers and Python installs pretty easily onto everything these days.

Highlights:

• 790 lines of Python, vs. 5300 lines of Haskell + 720 lines of <strange made-up language>.

• the framework supports running tests in various "ways", which should catch more bugs. By default, each test is run in three ways: normal, -O, and -O -fasm. Additionally, if profiling libraries have been built, another way (-O -prof -auto-all) is added. I plan to also add a 'GHCi' way.

  Running tests multiple ways has already shown up some new bugs!

• documentation is in the README file and is somewhat improved.

• the framework is rather less GHC-specific, and could without much difficulty be coaxed into using other compilers. Most of the GHC-specificness is in a separate configuration file (config/ghc).

Things may need a while to settle down. Expect some unexpected failures.