GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-01-30T14:54:56Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15575Investigate Haskell rewrite of testsuite driver2024-01-30T14:54:56ZTobias Dammerstdammers@gmail.comInvestigate Haskell rewrite of testsuite driverCurrently, the testsuite driver is written in Python. This is a bit of a liability:
- Having to program in "not Haskell" might scare away potential contributors here
- Even developers who are proficient in Python probably prefer working...Currently, the testsuite driver is written in Python. This is a bit of a liability:
- Having to program in "not Haskell" might scare away potential contributors here
- Even developers who are proficient in Python probably prefer working with Haskell
- Managing Python as a dependency poses an additional burden and complicates deployment, setting up dev environments, CI, etc.; especially on Windows.
- We miss out on the benefits of type checks and typed programming for a substantial bit of infrastructure
- We miss out on a nice dog-fooding opportunity
So in order to judge the scope of this task, and define it better, it would be good to investigate a bit:
- What would it take to get high-level feature parity with the current solution?
- Does the Haskell ecosystem cover the concerns that we would like to address with existing libraries? (Process management, for example)
- Can we come up with a smart and frictionless way of migrating all the existing test cases in a reliable automated fashion?
- What are risks and unknowns?
#15363 is the recent case that sparked this - rather than the proposed patch there, which ports existing Haskell code to Python, we would prefer going in the other direction.
#17933 is another
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Investigate Haskell rewrite of testsuite driver","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"Research needed","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Currently, the testsuite driver is written in Python. This is a bit of a liability:\r\n\r\n- Having to program in \"not Haskell\" might scare away potential contributors here\r\n- Even developers who are proficient in Python probably prefer working with Haskell\r\n- Managing Python as a dependency poses an additional burden and complicates deployment, setting up dev environments, CI, etc.; especially on Windows.\r\n- We miss out on the benefits of type checks and typed programming for a substantial bit of infrastructure\r\n- We miss out on a nice dog-fooding opportunity\r\n\r\nSo in order to judge the scope of this task, and define it better, it would be good to investigate a bit:\r\n\r\n- What would it take to get high-level feature parity with the current solution?\r\n- Does the Haskell ecosystem cover the concerns that we would like to address with existing libraries? (Process management, for example)\r\n- Can we come up with a smart and frictionless way of migrating all the existing test cases in a reliable automated fashion?\r\n- What are risks and unknowns?\r\n\r\n#15363 is the recent case that sparked this - rather than the proposed patch there, which ports existing Haskell code to Python, we would prefer going in the other direction.","type_of_failure":"OtherFailure","blocking":[]} -->Research needed