Hello. I just move a larger project to ghc-6.6 (from 6.4) http://dfa.imn.htwk-leipzig.de/auto/ (ca. 1000 modules) I had to modify my sources in several places. Perhaps the following list of observations is useful. tools: cabal/ghc work nicely, including building for profiling and haddockumentation. (I'm still missing cabal support for building docs that I want to access not via the file system but via a web server.) when "ghc --make" finds a source file that starts wrongly (e. g. "modul Foo" instead of "module Foo") (might occur from unobserved CVS merge conflicts) it just says <no location info>: file name does not match module name `Main' and it is quite impossible to find out which file is to blame (even "ghc -v" does not give any information?) type system: In some places I found it convenient to write type decls like foo ( x :: a ) ( y :: [ b ] ) = ... because this gave me at least some kind of documentation while I was too lazy to figure out all the type class requirements that I would need for a full signature. This is now impossible (a and b can no longer be declared by the line above?). But on the other hand this is more a question of coding style, not of compilation. Still the above method gave me the easiest way of getting some programs to compile. I cannot just remove all type sigs because then parts of the program might be ambiguous. To disambiguate, I am now forced to be more verbose. (Which may be a good thing.) Sometimes the type class restrictions in my code are larger than the actual program ... Yes, I introduce "constraint collection classes", e.g. http://141.57.11.163/cgi-bin/cvsweb/box/src/Rewriting/Approximation/Genet.hs... I guess I have too much overlapping instances in my code already, and now ghc seems to enforce that this be declared earlier (at the class definition, not usage)? the "coverage condition not satisfied" error message (with functional dependencies) should include a hint that "-fallow-undecidable-instances" might help. library changes: Network.CGI is new, but we have Network.CGI.Compat. Which however refers to Text.XHtml, not Text.Html, so I had to change these imports as well. source encoding: it is annoying that ghc only accepts UTF-8 now. sure I can use "iconv" but I rather not touch my sources at all. with "javac", I can just say "-encoding latin1". Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Another one: library change: the HasBounds class is gone. JCAB Johannes Waldmann wrote:
Hello.
I just move a larger project to ghc-6.6 (from 6.4) http://dfa.imn.htwk-leipzig.de/auto/ (ca. 1000 modules) I had to modify my sources in several places. Perhaps the following list of observations is useful.
tools:
cabal/ghc work nicely, including building for profiling and haddockumentation. (I'm still missing cabal support for building docs that I want to access not via the file system but via a web server.)
when "ghc --make" finds a source file that starts wrongly (e. g. "modul Foo" instead of "module Foo") (might occur from unobserved CVS merge conflicts) it just says
<no location info>: file name does not match module name `Main'
and it is quite impossible to find out which file is to blame (even "ghc -v" does not give any information?)
type system:
In some places I found it convenient to write type decls like
foo ( x :: a ) ( y :: [ b ] ) = ...
because this gave me at least some kind of documentation while I was too lazy to figure out all the type class requirements that I would need for a full signature. This is now impossible (a and b can no longer be declared by the line above?).
But on the other hand this is more a question of coding style, not of compilation. Still the above method gave me the easiest way of getting some programs to compile. I cannot just remove all type sigs because then parts of the program might be ambiguous. To disambiguate, I am now forced to be more verbose. (Which may be a good thing.)
Sometimes the type class restrictions in my code are larger than the actual program ... Yes, I introduce "constraint collection classes", e.g. http://141.57.11.163/cgi-bin/cvsweb/box/src/Rewriting/Approximation/Genet.hs...
I guess I have too much overlapping instances in my code already, and now ghc seems to enforce that this be declared earlier (at the class definition, not usage)?
the "coverage condition not satisfied" error message (with functional dependencies) should include a hint that "-fallow-undecidable-instances" might help.
library changes:
Network.CGI is new, but we have Network.CGI.Compat. Which however refers to Text.XHtml, not Text.Html, so I had to change these imports as well.
source encoding:
it is annoying that ghc only accepts UTF-8 now. sure I can use "iconv" but I rather not touch my sources at all. with "javac", I can just say "-encoding latin1".
Best regards,
Johannes Thanks for the summary. Concerning some specific points: | when "ghc --make" finds a source file that starts wrongly | (e. g. "modul Foo" instead of "module Foo") | (might occur from unobserved CVS merge conflicts) it just says | | <no location info>: file name does not match module name `Main' | | and it is quite impossible to find out which file is to blame That is terrible. I have fixed it. | In some places I found it convenient to write type decls like | | foo ( x :: a ) ( y :: [ b ] ) = ... | | because this gave me at least some kind of documentation | while I was too lazy to figure out all the type class requirements Yes, this whole scoped type variable thing is far from settled. | the "coverage condition not satisfied" error message | (with functional dependencies) should include a hint | that "-fallow-undecidable-instances" might help. Good idea. I've done that. | library changes: | | Network.CGI is new, but we have Network.CGI.Compat. | Which however refers to Text.XHtml, not Text.Html, | so I had to change these imports as well. Ian: should we update the release notes abou this? Simon
participants (3)
-
Johannes Waldmann -
Juan Carlos Arevalo Baeza -
Simon Peyton-Jones