Test evaluation no longer has everything in scope

[patritzenfeld]

I ran into a problem while fixing the currently planned IOTasks: In those type IO = IOrep is defined and that triggered an error within the interpreter, because both Prelude.IO and this is in scope. Hiding the type in the import of the Task file did not have any effect.

It turns out that for the evaluation of the tests

haskell-template-task/src/Haskell/Template/Task.hs

Line 733 in 4e97004

interpret "TestHarness.run Test.test" (as :: IO (Counts, ShowS))

everything in the loaded modules is in scope, even stuff that is explicitly not exported. So it is currently not possible to have such type synonyms inside the template/solution.

This is quite weird: I do not remember this being any different in the previous year, yet no error occured. My guess is that before #37 there was no mention of the IO type in the test result handling. So, even though this IO synonym was in scope, it did not cause a problem. Now there is explicit mention of IO, so the clash has an effect.

Luckily, this is easy to fix: setTopLevelModules modules is responsible for having everything in scope and can just be removed. Afterwards, you can still import the modules in code as usual, they are just not implicitly available in the above evaluation.

I'm assuming this was a mistake/oversight. But maybe there's an actual corner case why everything has to be in scope, that I did not think of?

[jvoigtlaender]

I also don't knoew whether there was a particular reason for that setTopLevelModules call. Maybe something historic that is not needed anymore?

In any case, if from your experimenting it seems everything works without that call, I'm willing to go with that.

But just for clarity: if the IO mentions from #37 are the problem, would it have also been solved by replacing those with Prelude.IO in all occurrences?

[patritzenfeld]

I briefly tried something like that, but it did not work out (Maybe I missed some occurrence of the type). I'll try it again to make sure it doesn't work.

[patritzenfeld]

I tried qualifying the type name everywhere, but that didn't fix the issue. I'm honestly not sure what else could be the reason this happened now.

[jvoigtlaender]

Okay, go with the solution that works.

[marcellussiegburg]

I also don't know whether there was a particular reason for that setTopLevelModules call.

I think this was solely to ensure that all modules are compiled. So the (semantic) behaviour might only change if there is some (invalid) module that is never imported.

[jvoigtlaender]

Probably that means at least if rigorousValidation is set, there should be a check that explicitly loads all of the modules from the config at once.