Martin Hofmann | 3 Dec 08:57
Favicon

What causes <<loop>>?

I've already posted this mail on haskell-cafe, but apparently the
subject suggested a too simple question, so I try it here again. I am
picking up a discussion with the same topic from haskell-users on
8th November. 

Thunks with reference on themselves was mentioned as main reason for
<<loop>>.

> A safe recursive definition would be
>   let x = Foo (x+1)
> However, if you leave out the constructor,
>   let x = x + 1
> you get a <<loop>> (or a deadlock).
> 

Are there any other reasons? 

I am trying to debug monadic code which stores state information in a
record maintaining several Data.Maps, but in vain so far. A state is
modified/changed in several steps by a compound function i.e.

	changeA $ changeB $ changeC state

Could this also lead to a deadlock? If so, can I prevent this using CPS?
If the state transformation is the main purpose/computation of the monad
at all, is it better to use CPS? Is code using mtl, records or Data.Map
more prone to <<loop>> or does this not matter at all. How can I
identify self-referencing thunks more easily? Is there any rule of thumb
to prevent <<loop>>? Are there any less obvious newbie mistakes causing
<<loop> then the one above?
(Continue reading)

Janis Voigtlaender | 3 Dec 10:30
Favicon

Re: What causes <<loop>>?

Martin Hofmann wrote:
> I've already posted this mail on haskell-cafe, but apparently the
> subject suggested a too simple question, so I try it here again. I am
> picking up a discussion with the same topic from haskell-users on
> 8th November. 

Note that you have been sending to haskell-cafe again. Your recipient
name says haskell-beginners, but the address is haskell-cafe.

Anyway, <<loop>> really means a loop in evalutation order, not some
statebased deadlock (see below).

> Thunks with reference on themselves was mentioned as main reason for
> <<loop>>.
> 
> 
>>A safe recursive definition would be
>>  let x = Foo (x+1)
>>However, if you leave out the constructor,
>>  let x = x + 1
>>you get a <<loop>> (or a deadlock).
>>
> 
> 
> Are there any other reasons? 
> 
> I am trying to debug monadic code which stores state information in a
> record maintaining several Data.Maps, but in vain so far. A state is
> modified/changed in several steps by a compound function i.e.
> 
(Continue reading)

Janis Voigtlaender | 3 Dec 10:32
Favicon

Re: What causes <<loop>>?

Janis Voigtlaender wrote:
> Martin Hofmann wrote:
> 
>> I've already posted this mail on haskell-cafe, but apparently the
>> subject suggested a too simple question, so I try it here again. I am
>> picking up a discussion with the same topic from haskell-users on
>> 8th November. 
> 
> 
> Note that you have been sending to haskell-cafe again. Your recipient
> name says haskell-beginners, but the address is haskell-cafe.
> 
> Anyway, <<loop>> really means a loop in evalutation order, not some
> statebased deadlock (see below).
> 
>> Thunks with reference on themselves was mentioned as main reason for
>> <<loop>>.
>>
>>
>>> A safe recursive definition would be
>>>  let x = Foo (x+1)
>>> However, if you leave out the constructor,
>>>  let x = x + 1
>>> you get a <<loop>> (or a deadlock).
>>>
>>
>>
>> Are there any other reasons?
>> I am trying to debug monadic code which stores state information in a
>> record maintaining several Data.Maps, but in vain so far. A state is
(Continue reading)

Apfelmus, Heinrich | 3 Dec 11:04
Favicon

Re: What causes <<loop>>?

Martin Hofmann wrote:
> Thunks with reference on themselves was mentioned as main reason for
> <<loop>>.
> 
>> A safe recursive definition would be
>>   let x = Foo (x+1)
>> However, if you leave out the constructor,
>>   let x = x + 1
>> you get a <<loop>> (or a deadlock).
>>
> 
> Are there any other reasons? 

A program that exits with <<loop>> is basically a program that runs
forever. Examples of programs that run forever are

  let x = x + 1 in x

  let f x = f x in f 1

In special cases, the run-time system is able to detect that the program
would run forever, and exits with <<loop>> if that happens.

> Sorry, a lot of questions at once, but I am kind of helpless because I
> can't find any reason of my <<loop>>, so any comments, experience, and
> tips are highly appreciated.

Sometimes, a simple cause is accidentally using the same variable name,
i.e. writing

(Continue reading)


Gmane