Closed gelisam closed 11 years ago
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.
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?
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:
printRow
or printRows
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.
the refactoring has introduced a few regressions, but I will create new bugs for them instead of cluttering this thread. closing.
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.