On Wed, 26 Apr 2000, Hamilton Richards wrote:
> The Gofer prelude had a function
>
> openfile :: String -> String
>
> which mapped file path names to strings containing the named files' contents.
>
> The Hugs98 Prelude doesn't seem to have anything like that function.
> Instead, it has things like
>
> readFile :: String -> IO String
>
> Why would I want openfile instead of readFile? The problem in which the
> need for openfile arose is this:
>
> I want to load a binary search tree and a list with
> words read from a file, and then perform, interactively,
> several tests comparing the cost of searching the
> tree with that of searching the list. In addition to
> performing the tests interactively, I want to separate
> the cost of searching the list and the tree from the
> cost of constructing them.
>
> In order for the list and the tree to be used in several successive
> command-line evaluations without being reconstructed each time, they must
> be named globally. This is no problem with openfile, but readFile forces
> their names to be local to an IO command.
>
Why is this a problem? After all, the names ARE dependent on IO.
> Can anyone suggest a solution?
>
I do not understand the problem.
Is it something like this you want?
parseTree :: String -> Tree
parseList :: String -> List
buildTree:: IO Tree
buildTree = do f <- readFile "thetree"
return (parseTree f)
buildList:: IO List
buildList = do f <- readFile "thelist"
return (parseList f)
test :: IO()
test = do tree <- buildTree
list <- buildList
dowhateverYouwant_interactive_or_not tree list
dowhateverYouwant_interactive_or_not :: Tree -> List -> IO()
/Lars L
