On Mon, 2002-03-18 at 13:51, Simon Marlow wrote: > Ok, here's my explanation. [...]
I see...
Yet, it doesn't explain why the problem disappears if you close stdin
before calling executeFile, like this:
callIO :: (ProcessStatus -> String)
-> IO ()
-> IO ()
callIO fm io = do
maybepid <- forkProcess
case maybepid of
Nothing ->
hClose stdin >> -- ** here **
io >> -- executeFile
exitWith ExitSuccess
Just pid -> do
(Just ps) <- getProcessStatus True True pid
if ps == Exited ExitSuccess
then return ()
else failIO (fm ps)
Since evaluation of the arguments of executefile causes stdin to be read
lazily, shouldn't closing stdin cause them to be cut short? It looks
like closing stdin caused it to be read completely, first. Something
like this isn't mentioned in the Library Report.
> ____ _ _
> | _ \ ___ _ __ ( ) |_ _ _ ___ ___
> | | | |/ _ \| '_ \|/| __| | | | / __|/ _ \
> | |_| | (_) | | | | | |_ | |_| \__ \ __/
> |____/ \___/|_| |_| \__| \__,_|___/\___|
> _ ___ _____
> | | __ _ _____ _ |_ _| / / _ \
> | |/ _` |_ / | | | | | / / | | |
> | | (_| |/ /| |_| | | | / /| |_| |
> |_|\__,_/___|\__, | |___/_/ \___/
> |___/
But rejecting lazy IO would throw away a lot of elegance. I wonder if it
would be possible to allow it in many cases, while guaranteeing
referential transparency.
For files, this could be accomplished by locking them, making use of OS
features (such as lockf(2)). You could define an IO action like "mapIn
:: FilePath -> IO String", which would bring a file to the realm of the
process, making it inaccessible to the outside world (other processes).
Likewise, it might be possible to define a set of process operations
which avoid mistakes like mine.
But it seems like quite some thought is necessary in order to determine
unter which circumstances it is possible to incorporate external things
in the lazy-functional world...
Volker
signature.asc
Description: This is a digitally signed message part
