[Hugs-users] Hugs98-plus-Sept2006

Mark Hills mhills at cs.uiuc.edu
Sat Dec 9 18:23:34 EST 2006


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 at mindspring.com wrote:
>> On Sat, Dec 09, 2006 at 09:38:37PM +0000, dfeustel at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/hugs-users
>   


More information about the Hugs-Users mailing list