move post-processing inside hint

[gelisam]

If the user does not mention Prelude in ~/.hawk/prelude.hs, import it unqualified. If the user imports the Prelude unqualified, import it unqualified. If the user imports the Prelude qualified, import it with the same qualifier.

[gelisam]

We can't have an unqualified Prelude yet, as it would conflict with ByteString's many existing bindings, such as map :: (Char -> Char) -> ByteString -> ByteString. And we can't make ByteString qualified either, because hint complains that ByteString is not in scope. I think this is due to the fact that we ask hint to evaluate a value of type ByteString -> IO (); that type must somehow get inserted unqualified into the expression to be evaluated.

[gelisam]

New branch, "qualify_bytestring", with a proof-of-concept in which I move all the post-processing inside hint so that we only ask it to evaluate values of type IO ().

What do you guys think, is this the way forward? Should I continue working on this branch to bring back the features I have temporarily removed, or should we try to fix hint instead?

[melrief]

I think yours is a clever solution @gelisam. I used a similar solution when I had the problem with the output. When I started hsp, the expression to evaluate had type ByteString -> Rows a. hint wasn't able to recognise a, so I encapsulated the output writer (printRows and printRow) in the user expression and the type became ByteString -> IO (). Now you had a similar problem with the input, that was ByteString, and you encapsulate an input reader based on the options inside the user expression and the type became IO ().

I think we should stick with your solution, IO () for two reasons: i) there is no easy solution to the hint problem, even if we enforce the import of only the type ii) in this way, in future we could give to the user the possibility to change both the input reader and the output writer. For now we are working with lazy streams of ByteString but in future the user could have two options to specify that, for example, he prefers to work with Text or String instead of ByteString. The expression to evaluate will still have type IO (), so no changes to the hawk core, but it will work with different types:

> hawk --input-reader System.IO.getContents --output-writer System.IO.putStrLn "show . map (\w -> (head w,length w)) . group . sort . concatMap words . lines"

The example whould give you a vague idea of what I have in mind. Imagine if we give the possibility to the user to define:

• its own input reader, that is the function that reads from stdin or file
• its own output writers, like currently we have printRow or printRows

[gelisam]

For more clarity of discussion, this issue (#40) now refers to the sub-task in which I moved all the post-processing inside of hint.

"import Prelude by default" is now issue #50.

[gelisam]

the refactoring has introduced a few regressions, but I will create new bugs for them instead of cluttering this thread. closing.