Latest update Sep 6, 2006.
To avoid spam, all mail addresses on this page have the "@" replaced by "#".
This FAQ exemplifies some common problems, and indicates how they can be solved. It is expected to grow with time.
Q: Sometimes, the SOEGraphics package does not load correctly in the lab computers in room 023.
A: This problem should be gone by now. There was an error with the installation before: some versions og Hugs were available that did not work with SOEGraphics. This is fixed now so only the correct version of Hugs is visible under Start/Alla program. (You should ONLY use Hugs in Haskell 98 mode.)
If there are still problems with the installation on some computer(s), then please notify us ASAP: symptoms, and which computer.
Q: Which version of Hugs should I install when working in my own PC with Windows?
A: There is a new version of Hugs (Jan. 2005) that works fine with SOEGraphics. Go to
http://cvs.haskell.org/Hugs/pages/downloading.htm
and then click on "Windows installer for an earlier snapshot". Note that WinHugs does not work for this release, so use plain Hugs.
Q: How do I write the path to a file in Haskell?
A: Write the path as a string with DOUBLE back-slashes, like in "D:\\TEST.txt". The reason is that the file path is a string, i.e., a list of characters, and "\" is Haskell's escape character for non-printable character codes (e.g., `\n` for newline). Thus, the character "\" itself is written `\\` in Haskell syntax.
Q: Hugs cannot find the modules for the code in the different chapters in the book (Animation.hs, Picture.hs, Fal.hs etc.).
A: The version of Hugs + SOE, which we recommend to download (the pre-March-2005 version snapshot for Windows) has a problem to find the source files for these modules, which reside under C:\Program\Hugs98_SOE\lib\SOE\src for a standard Windows XP installation. A workaround, assuming a standard installation, is to start Hugs explicitly in a command window using the -P flag to extend its search path, viz.
C:\Documents and Settings\blr>C:\Program\Hugs98_SOE\hugs -P;{Hugs}\lib\SOE\src
A more brutal workaround is to copy the required source files from
C:\Program\Hugs98_SOE\lib\SOE\src to your working directory.
A third workaround is to resort to the old version of Hugs + SOE from
November 2002, which does not have this problem at all.
Note that the modules under C:\Program\Hugs98_SOE\lib\GraphicsLib which includes SOEGraphics, can be loaded without problems.
Q: Why do I get problems importing modules when running Haskell in Linux?
A: File names are case sensitive in Linux (as in any unix system), so you have to write the exact file name, with all characters in the right case, to have its module loaded. Thus, if you have a module called Max2 in a file max2.hs, then :load Max2 will fail on unix systems.
As a matter of fact, Hugs just loads the contents of the file with the name specified by the :load command. Thus, in the example above, :load max2 will work. The file name can even be totally unrelated to the module name! But it's good practice to have the same name for both.
Q: Why do I get the following problem when compiling this code?
insert x [] = [x]
insert x (y:ys) | y < x = y : insert x ys
| otherwise = x : y : ys
sort = foldr insert []
Prelude> :load Foldsort Reading file "Foldsort.hs": Type checking ERROR "Foldsort.hs":7 - Unresolved top-level overloading *** Binding : sort *** Outstanding context : Ord b
A: This type error depends on something called the "monomorphism restriction" in Haskell's type system. This is a restriction in the type inference that is due to Haskell's class system. Without it, the type system would be undecidable (that is, there would be programs where the type system wouldn't be able to decide whether they have valid types or not). Unfortunately, this restriction will cause some programs to be rejected by the type system although they really ought to be perfectly typable. Type errors due to the monomorphism restriction often manifest themselves as "Unresolved overloading", which means the type system has too little information to resolve certain class constraints. In the example, the type system will fail to deduce the type Ord a => [a] -> [a] for sort. A remedy that always works is to add an explicit type declaration for the failing identifier, in our case sort :: Ord a => [a] -> [a].
In this particular example it also works to rewrite the definition of sort, viz.
sort xs = foldr insert [] xs
(Why this declaration works, and not the terser sort = foldr insert [], is due to details in the type inference process.)
Q: What's the problem here?
Prelude> show [] ERROR - Unresolved overloading *** Type : Show a => [Char] *** Expression : show []
A: This is another example of unresolved class overloading. This time, it is a true problem. The cause is that [a] is a member of the Show class whenever a is. Thus, there is a show method defined for every "showable" list type. For all such list types but one, the show function will print the empty list as []. However, if the empty list has the type [Char] (i.e., String), it will be printed as "". In the example above, the empty list has the most general type [a], and the system does not have enough information to decide whether to print it as "" or [] (since a could be Char, but also something else).
Again, the remedy is to give some explicit typing to help the type system resolve the overloading. For instance, show ([] :: [Int]) will print [].
Here is a similar example, with the sort function defined above:
Foldsort> sort [] ERROR - Unresolved overloading *** Type : Ord a => [a] *** Expression : sort []
Here, the type system can only decide the type Ord a => [a] for sort []. This is not enough information to print the result, for similar reasons as above. As before, an explicit type declaration for [] solves the problem.