moving to ghc-6.6
Johannes Waldmann
waldmann at imn.htwk-leipzig.de
Mon Oct 23 09:25:41 EDT 2006
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?rev=1.22
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/ -------
More information about the Glasgow-haskell-users
mailing list