[list-ops] Make foldl' call unambiguous.#1298
Conversation
IsaacG
commented
May 16, 2026
```
/solution/test/Tests.hs:80:9: error: [GHC-87543]
Ambiguous occurrence ‘foldl'’.
It could refer to
either ‘Prelude.foldl'’,
imported from ‘Prelude’ at test/Tests.hs:(8,1)-(16,5)
(and originally defined in ‘ghc-internal-9.1003.0:GHC.Internal.Data.Foldable’),
or ‘ListOps.foldl'’,
imported from ‘ListOps’ at test/Tests.hs:22:7-12.
|
80 | foldl' (flip (:)) [] "asdf" `shouldBe` "fdsa"
| ^^^^^^
```
|
This PR touches files which potentially affect the outcome of the tests of an exercise. This will cause all students' solutions to affected exercises to be re-tested. If this PR does not affect the result of the test (or, for example, adds an edge case that is not worth rerunning all tests for), please add the following to the merge-commit message which will stops student's tests from re-running. Please copy-paste to avoid typos. For more information, refer to the documentation. If you are unsure whether to add the message or not, please ping |
MatthijsBlom
left a comment
There was a problem hiding this comment.
I think a [no important files changed] would be fitting.
Prior to base-4.20.0.0 (bundled with GHC 9.10), foldl' was not re-exported by the Prelude. But from base-4.20.0.0 onward it is, hence the error that the proposed change fixes.
All other names defined in ListOps were already exported by the Prelude. This conflict was solved by hiding these while importing the Prelude. Rather than disambiguating all its uses, add foldl' to this import list.
The solution stub file should be patched as well.
I completely agree. That needs to be in the merge message when the track maintainer merges this PR.
Done. Thanks for the explanation and details! |
|
Both By "the solution stub file" I meant Hiding a nonexistent export gives rise to merely a GHC-61689 -Wdodgy-imports warning, so it looks like this change is backwards-compatible. ...Except apparently the tests have |
Woops. Missed that one. Added now. |
|
Eh. This PR was meant in service of the test runner upgrade. If that lands first, a test rerun ought to pass here. Unrelated, there's a bunch of other PRs in this repo worth a look, too! |
|
I think the tests fail because of Line 58 in 9e4f385 I guess they could be made to pass again by adding |
|
@tofische With the test runner updated, it might be worth rerunning the failed check here |