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
Module names are built reflecting the directory structure, with separate starting directories for different products. If you start Hugs and type :set, you will see something like this for the search path: Search path : -P.:{Home}/lib/hugs/packages/*:/usr/local/lib/hugs/packages/*:{Hugs}/packages/* So, each directory under lib/hugs/packages is added to the path, including (for instance) base and hugsbase. The hugsbase directory contains a Hugs directory, which contains a Prelude.hs file. Looking at the file, you will see that it says it defines module Hugs.Prelude, which makes sense since the file name is Hugs/Prelude.hs. Similarly with Data.Map, which is under the base directory in file Data/Map.hs. I only have two files named Prelude.hs, the one under base and the one under hugsbase. The one under base simply wraps the one under hugsbase (it imports it at the end), I'm assuming to allow the definitions to be Hugs-specific (since they use primitives) while still providing a standard location for the Prelude, in case you want to run your programs using a different Haskell system like GHC. Mark dfeustel@mindspring.com wrote:
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 _______________________________________________ Hugs-Users mailing list Hugs-Users@haskell.org http://www.haskell.org/mailman/listinfo/hugs-users
On Sat, Dec 09, 2006 at 05:23:34PM -0600, Mark Hills wrote:
[patient explanation of how Hugs finds hierarchical modules]
I only have two files named Prelude.hs, the one under base and the one under hugsbase. The one under base simply wraps the one under hugsbase (it imports it at the end), I'm assuming to allow the definitions to be Hugs-specific (since they use primitives) while still providing a standard location for the Prelude, in case you want to run your programs using a different Haskell system like GHC.
Another reason for a separate Hugs.Prelude is that it exports some extra things. This is because Haskell 98 has the Prelude and some other library modules import each other, and Hugs does not support mutually recursive modules, so it simulates it by having the Prelude and the other modules import another module with the real definitions (Hugs.Prelude). Also, Prelude.hs is shared code with GHC, except for the imports (courtesy of cpp).
On Sat, Dec 09, 2006 at 11:11:21PM +0000, dfeustel@mindspring.com wrote:
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?
% find /usr/local/lib/hugs -name Prelude.hs | xargs grep ^module /usr/local/lib/hugs/packages/hugsbase/Hugs/Prelude.hs:module Hugs.Prelude ( /usr/local/lib/hugs/packages/base/Prelude.hs:module Prelude ( They are different modules, with the second (the Prelude, as defined in Haskell 98) importing the first (Hugs.Prelude, the internal Hugs implementation). The search path contains /usr/local/lib/hugs/packages/*, so when asked to load module A.B.C, Hugs looks for /usr/local/lib/hugs/packages/*/A/B/C.{hs,lhs} (section 2.2 of the Hugs User's Guide) The point is that if the file thus found does not describe itself as module A.B.C, the load will fail. Now plug Hugs.Prelude and Prelude into the above, and we get the behaviour you are seeing. The problem is that you have a file Prelude.hs in your search path that does not start with "module Prelude".
participants (3)
-
dfeustel＠mindspring.com -
Mark Hills -
Ross Paterson