Albert Y. C. Lai wrote:
It is similar to saying, if you use Haskell, you don't have to learn
dependent typing. Ah, but knowing dependent typing informs you of
certain typing issues and how to use the Haskell type system more
successfully. This is despite tutorials on dependent typing talk about
Bryan O'Sullivan wrote:
Your problem may be buffering-related (I haven't read your code to
check), but if so, there's a fair likelihood that it has nothing to do
with the OS. GHC's runtime does its own buffer management on Handles.
It's quite possible that your deadlock lies at that level, rat
Andrea Rossato wrote:
Most likely, the content of s sits in a local buffer and never leaves this
process, following most OS conventions and as others point out. Another
process waiting for it will deadlock.
Yes, I knew it was something related to the underneath OS. I'll have
to study Unix
On Sat, Sep 01, 2007 at 09:12:30PM -0400, Albert Y. C. Lai wrote:
> Andrea Rossato wrote:
> > loop s = do
> > putStrLn s
>
> Most likely, the content of s sits in a local buffer and never leaves this
> process, following most OS conventions and as others point out. Another
> pro
Andrea Rossato wrote:
loop s = do
putStrLn s
Most likely, the content of s sits in a local buffer and never leaves
this process, following most OS conventions and as others point out.
Another process waiting for it will deadlock.
Most similar process deadlock problems are not s
Hi,
there's something I don't get about interaction among OS processes and
Haskell handles/channels.
Suppose I have a very small program that takes a line and prints it
till you write "quit":
main = do
s <- getLine
case s of
"quit" -> putStrLn "quitting" >> return ()
_ -> loop s
wh
