global type inference
| 5.4 Separate Compilation | |Depending on the Haskell implementation used, separate compilation of |mutually recursive modules may require that imported modules contain |additional information so that they may be referenced before they are |compiled. Explicit type signatures for all exported values may be |necessary to deal with mutual recursion. The precise details of |separate compilation are not defined by this report. Goodness folks, that's not exactly a tight spec. Is a Haskell implementation required to support mutually recursive modules that do not have explicit type signatures? The quoted text makes it clear that implementations are not required to support this when doing separate compilation, but does that just mean that Haskell implemenations that don't support it when doing separate compilation must provide a way of getting non-separate compilation (i.e. some kind of "compile all these modules together" option), or does it mean that they are not required to support it at all? If I write a Haskell program that contains mutually recursive modules without explicit type signatures, can I be sure that it will be portable to all Haskell implementations? Also, what is the situation in this regard with respect to the existing Haskell implementations? -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
Re: global type inference
I think the report has it about right. * A conforming implementation of Haskell 1.4 must support mutually recursive modules. That is, a collection of individually legal mutually recursive modules is a legal Haskell program. * The Report recognises that implementations available in the forseeeable future are likely to require the programmer to supply extra type information to support separate compilation of mutually recursive modules. For example, the implementation may require exported functions to be equipped with type signatures. Why muddle implementation with language design? Pick a design that we know everyone can implement -- e.g., exported functions must have type declarations -- and stick to that. When the state of implementations improve, the specification for Haskell 1.5 can change accordingly. -- P
Re: global type inference
| Why muddle implementation with language design? Pick a design that | we know everyone can implement -- e.g., exported functions must have | type declarations -- and stick to that. When the state of implementations | improve, the specification for Haskell 1.5 can change accordingly. -- P Actually, we don't know that everyone can implement the design you suggest. To make sense of the type signature you have to do a completely separate scope analysis of the source code of the imported module, so that you know what "T", say, in the type signature of an exported function means. GHC will do that but it doesn't yet. Currently you have to fiddle with GHC-specific interface files. I don't know what Hugs does, nor hbc. That is why I suggested the form of words I did. If you like, we could be more specific, but then there won't be any conforming implementations for a while! This isn't muddling implemenation with language design. The language design says mutual recursion is OK. A particular implementation supporting separate compilation will typically require a variety of "help", such as a Makefile with accurate dependencies. Requiring type signatures, or interface files, or whatever is just another implementation specific thing to support separate compilation. Simon
Re: global type inference
This isn't muddling implemenation with language design. The language design says mutual recursion is OK. A particular implementation supporting separate compilation will typically require a variety of "help", such as a Makefile with accurate dependencies. Requiring type signatures, or interface files, or whatever is just another implementation specific thing to support separate compilation. The language design should at least say what is a legal Haskell file, and what is not. As much as possible, it should lay out exactly what I need to do to write a program that will work on any Haskell compiler that conforms to the definition. It seems to me that the language definition should go further than it does on this point, though perhaps reasonable people may disagree. -- P
