Hi, You're probably refering to the version where you omit the type signatures of both 'printer' and 'printCatalog'. Here the situation is different because the compiler needs to infer the types and not just check. In the explicitely typed version, 'printCatalog' is used polymorphically, i.e. the 'c' is instantiated to different types during the recursive call. Thus the example needs polymorphic recursion, for which type inference is known to be undecidable. It is therefore reasonable that ghc (as well as hugs) can't compile the code (in fact, I guess type inference will assume that both contexts are equal). Thomas On 7/29/05, Benjamin Franksen wrote:

a connection to the first one? Note, I have a version of the program, where I only get the "Inferred type is less polymorphic than expected" error message and this one also disappears as soon as I use a lambda instead of a top-level function to initialize the record.

Ben

Hi, On 7/30/05, Benjamin Franksen wrote:

On Saturday 30 July 2005 03:54, Thomas Jäger wrote:

...

You're probably refering to the version where you omit the type signatures of both 'printer' and 'printCatalog'. Here the situation is different because the compiler needs to infer the types and not just check. In the explicitely typed version, 'printCatalog' is used polymorphically, i.e. the 'c' is instantiated to different types during the recursive call. Thus the example needs polymorphic recursion, for which type inference is known to be undecidable. It is therefore reasonable that ghc (as well as hugs) can't compile the code (in fact, I guess type inference will assume that both contexts are equal).

Hmm. I am not sure I understand this. I just described the reason why the "inferred type..." error message appears when there are no type signatures given to either 'printer' or 'printCatalog'.

Are you saying, that the second error causes the first one? Thus, everything is caused by 'printer' being recursively defined? Yes, that's what I believe. I'm not sure why it shows the first error message at all; in my experience, strange things happen when ghc continues after an error message that you shouldn't pay too much attention to. Perhaps ghc-6.4 just assumes identical contexts in recursive groups without checking the type signatures.

Are contexts with differing length in a recursive definition ok in Hugs (as in the latest version of ghc) and therefore with Hugs I don't get the first message either? Yes.

Thomas