On Sat, Dec 09, 2006 at 09:38:37PM +0000, dfeustel@mindspring.com wrote:
What I have discovered is that þugs, invoked with no arguments, initializes itself differently depending upon the presence or absence of Prelude.hs in the $HOME directory. With Prelude.hs *not* present in $HOME, I get the behavior described in the original post. When Prelude.hs *is* present in $HOME, then an error re loading Prelude.hs is reported, and primMinInt/primMaxInt/primMaxChar all work and the prompt is 'Hugs.Prelude>'.
You have a file called Prelude.hs containing a module Hugs.Prelude in your current directory. When Hugs starts, it loads Hugs.Prelude, which it finds in the default path,
the 'find' command does not find a file by the name of Hugs.Prelude anywhere in the Hugs98 tree or in /usr/local/lib/hugs, nor in the default path, as far as I can tell. There are, þowever, 5 different instances of Prelude.hs in the Hugs98 tree. Why is there more than 1 instance of Prelude.hs (with different contents to boot) in Hugs98 source?
and then attempts to load Prelude from Prelude.hs (because . is at the front of the search path). However this file contains a module Hugs.Prelude, not the Prelude it was expecting, and initialization fails.
Initialization does not fail. Hug terminates when initialization fails. Initialization takes a different path when it encounters Prelude.hs in either $HOME or . directories. The alternate initialization path makes hug work as the Haskell book describes on page 13. Where is the module Hugs.Prelude found during hugs initialization, if not in Prelude.hs?
The error message when Hugs finds a file to contain the wrong module could be better, though.
I agree. Perhaps some standardization of terminology would help too. Dave