[Haskell-cafe] what is f=f (not) doing ?

[Lennart Augustsson]

But this was a very particular case when a thread starts evaluating a node
and then comes back to the same node again.
The general case is (of course) undecidable.

On 9/23/07, Bulat Ziganshin <bulat.ziganshin at gmail.com> wrote:
>
> Hello Lennart,
>
> Sunday, September 23, 2007, 2:05:46 PM, you wrote:
>
> i bet that general case contains too much conditions to check. program
> may be unblocked by other thread, by OS signal, by I/O operation
> completion, by C thread. how for example RTS can check that we have
> started I/O operation with completion callback which will call abort()
> function?
>
> > I agree. This situation is totally detectable.
>
> > On 9/23/07, Neil Mitchell <ndmitchell at gmail.com> wrote:
> > Hi
>
> >> I'm not sure, but since it would require the detection of an evaluation
> >> that does not terminate,it comes down to the halting problem, which is
> >> not generally solvable. Maybe the experts can confirm my intuition?
>
> > I think your intuition is off. This isn't the problem of detecting
> > that a computation might not halt, its a question of detecting after
> > the fact a very restricted case of non-termination has occurred. I
> > think it should be possible to assign threads etc to these things, but
> > may make the code run slower in the common case.
>
> > Thanks
>
> > Neil
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> >  http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> >
>
>
> --
> Best regards,
> Bulat                            mailto:Bulat.Ziganshin at gmail.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070923/fd926687/attachment.htm