Loops.

older
darcs patch: Oops... left out one...

Lemmih

20 Mar 2008 20 Mar '08

5:13 p.m.

Hiya, x :: IO () -- This type signature works fine, <<loop>> is printed x :: a -- This type signature blows the stack of jhc x = x main = x Is this a known bug? -- Cheers, Lemmih

Show replies by date

John Meacham

20 Mar 20 Mar

5:39 p.m.

On Thu, Mar 20, 2008 at 06:13:48PM +0100, Lemmih wrote:

...

x :: IO () -- This type signature works fine, <<loop>> is printed x :: a -- This type signature blows the stack of jhc x = x main = x

Is this a known bug?

Well, it's not really a bug as all detection of loops is a bonus, if the optimizer comes across something of exactly 'x = x' it will replace it with error "<<loop>>" but not all loops optimize to that form. x :: forall a . a x = x turns into x :: (a::*) -> a x a = x a in core, so it is not recognized as a loop. I doubt it will be much of a problem in practice, and eta reduction is an anti-optimization in general. John -- John Meacham - ⑆repetae.net⑆john⑈

Samuel Bronson

5:51 p.m.

On 3/20/08, John Meacham wrote:

...

x :: (a::*) -> a x a = x a

in core, so it is not recognized as a loop. I doubt it will be much of a problem in practice, and eta reduction is an anti-optimization in general.

Why isn't that recognized as a loop? Isn't it typically beneficial in the body of a function to replace calls like that with the return value? For example: fix :: (a -> a) -> a fix f = f (fix f)

John Meacham

10:44 p.m.

On Thu, Mar 20, 2008 at 12:51:20PM -0500, Samuel Bronson wrote:

...

On 3/20/08, John Meacham wrote:

...
in core, so it is not recognized as a loop. I doubt it will be much of a problem in practice, and eta reduction is an anti-optimization in general.

Why isn't that recognized as a loop? Isn't it typically beneficial in the body of a function to replace calls like that with the return value? For example:

fix :: (a -> a) -> a fix f = f (fix f)

Oh, it is recognized as recursive*, but not as an infinite loop. When the jhc optimizer comes across something it knows is equivalent to bottom, it replaces it with 'error "<<loop>>"'. ghc does the same thing. it is this replacement that jhc wasn't doing, which is okay since the replacement is really just an optimization jhc will take advantage of when it can find, but doesn't look to hard for. (though, other optimizations likely expose more 'manifest loops'. * though the fact jhc is blowing stack means that perhaps there is a bug whereby it isn't being recognized as recursive. -- John Meacham - ⑆repetae.net⑆john⑈

Lemmih

6:06 p.m.

On Thu, Mar 20, 2008 at 6:39 PM, John Meacham wrote:

...

On Thu, Mar 20, 2008 at 06:13:48PM +0100, Lemmih wrote:

...
x :: IO () -- This type signature works fine, <<loop>> is printed x :: a -- This type signature blows the stack of jhc x = x main = x

Is this a known bug?

Well, it's not really a bug as all detection of loops is a bonus, if the optimizer comes across something of exactly 'x = x' it will replace it with error "<<loop>>" but not all loops optimize to that form.

Blowing the stack is not a bug? -- Cheers, Lemmih

Lemmih

6:16 p.m.

On Thu, Mar 20, 2008 at 7:06 PM, Lemmih wrote:

...

On Thu, Mar 20, 2008 at 6:39 PM, John Meacham wrote:

...
On Thu, Mar 20, 2008 at 06:13:48PM +0100, Lemmih wrote:

...
x :: IO () -- This type signature works fine, <<loop>> is printed x :: a -- This type signature blows the stack of jhc x = x main = x

Is this a known bug?

Well, it's not really a bug as all detection of loops is a bonus, if the optimizer comes across something of exactly 'x = x' it will replace it with error "<<loop>>" but not all loops optimize to that form.

Blowing the stack is not a bug?

Sorry, I see that I wasn't clear. It blows the stack of jhc when compiling the program. -- Cheers, Lemmih

John Meacham

10:29 p.m.

On Thu, Mar 20, 2008 at 07:16:20PM +0100, Lemmih wrote:

...

...
Blowing the stack is not a bug?

Sorry, I see that I wasn't clear. It blows the stack of jhc when compiling the program.

Ah. Do you have any good way of tracking down this sort of error BTW? I hear there is a new ghci debugger, but it didn't seem to help when I tried it but perhaps others have more debug-foo. There are also some programs (chess from nobench is one I think) that just lock up in an infinite loop somewhere in optimization that I have not been able to track down. John -- John Meacham - ⑆repetae.net⑆john⑈

John Meacham

6:17 p.m.

On Thu, Mar 20, 2008 at 07:06:55PM +0100, Lemmih wrote:

...

On Thu, Mar 20, 2008 at 6:39 PM, John Meacham wrote:

...
On Thu, Mar 20, 2008 at 06:13:48PM +0100, Lemmih wrote:

...
x :: IO () -- This type signature works fine, <<loop>> is printed x :: a -- This type signature blows the stack of jhc x = x main = x

Is this a known bug?

Well, it's not really a bug as all detection of loops is a bonus, if the optimizer comes across something of exactly 'x = x' it will replace it with error "<<loop>>" but not all loops optimize to that form.

Blowing the stack is not a bug?

Ah! are you saying 'jhc' blows its stack or the compiled program does? sorry, I misunderstood. yeah, that is a bug then. I have actually run into a few programs that blow stack, perhaps this is the cause. John -- John Meacham - ⑆repetae.net⑆john⑈

6499

Age (days ago)

6499

Last active (days ago)

List overview

Download

7 comments

3 participants

participants (3)

John Meacham
Lemmih
Samuel Bronson

Loops.

tags

participants (3)