Josef,
| > You might get a better understanding of this if you try to find a value
| > for the cutoff parameter that will allow the following program to load:
| >
| > newtype Fix f = In (f (Fix f))
| > deriving Show
| >
| > newtype Nat = MkNat (Fix Maybe)
| > deriving Show
| >
| > (Hugs limits the -c value to a maximum of 1024, but that should
| be enough
| > to persuade you ...)
| >
| Thanks for the example. I'm not quite convinced though.
| ...
| ... So one might try Show (f (Fix f)). This still
| doesn't work with hugs (it complains about the cutoff again) but it works
| with ghc.
I'm afraid you're going to have to be much more precise.
- You focused on deriving Show for Fix in your message. That is
not the source of the problem; the hard part is in deriving Show
for Nat, and hence for Fix Maybe.
- You say it worked for ghc, but I couldn't repeat that, so either
we're using a different "it", a different "ghc", or a different
set of command line flags? I used the latest ghc without special
command line args on the following variant of the program:
module Foo where
newtype Fix f = In (f (Fix f))
deriving Show
Adding in the extra definition for Nat seemed pointless if I couldn't
get this to work. And let's be clear: ghc is right not to allow this
because it isn't legal Haskell 98 code.
- You say it didn't work for Hugs, but it worked fine for me. If you
load the module Foo above with Hugs in +98 mode, then it just gives
an error message that is Hugs' analogue of the error produced by ghc.
If you run Hugs in -98 mode, without the Haskell 98 restrictions,
then it derives Show (f (Fix f)) => Show (Fix f), which is also a
reasonable response. In neither case did I get the cutoff error
that you reported.
| So, the question remains; is there really a need for iterating when
| deriving Show? Or am I missing something obvious here?
To derive any instance of a class, you need to know what will go on
the left of the => sign in the generated instance. That context can
be expressed as a fixed point, details of which I will not provide,
and such fixed points are usually calculated by iterating until the
desired fixed point is reached ... in finitely many steps, or so one
might hope. But here, the computation fails to reach a fixed point.
It doesn't matter whether you iterate, recurse, or anything else; if
your goal is to find a fixed point where none exists, then you'll end
up disappointed.
All the best,
Mark
