Problem in load path in CVS repository version of Hugs

[Johan Nordlander]

> The current Debian package (the rather ancient Feb 2001) loads
> Greencard quite correctly:
>
>   /usr/bin/runhugs             -P/home/reid/local/gc-2.01/src: 
> GreenCard.lhs
>
> The version of Hugs in the current CVS repository has problems:
>
>   /home/reid/local/bin/runhugs -P/home/reid/local/gc-2.01/src: 
> GreenCard.lhs
>   runhugs: Unable to initialise Hugs
>
> Using hugs instead of runhugs doesn't help but lets me verify that the
> -P setting is being seen by Hugs.
>
>   /home/reid/local/bin/hugs -P/home/reid/local/gc-2.01/src: 
> GreenCard.lhs
>   __   __ __  __  ____   ___      
> _________________________________________
>   ||   || ||  || ||  || ||__      Hugs 98: Based on the Haskell 
> 98 standard
>   ||___|| ||__|| ||__||  __||     Copyright (c) 1994-2001
>   ||---||         ___||           World Wide Web: 
> http://haskell.org/hugs
>   ||   ||                         Report bugs to: hugs-bugs@haskell.org
>   ||   || Version: December 
> 2001  _________________________________________
>
>   Haskell 98 mode: Restart with command line option -98 to 
> enable extensions
>
>   Reading file "/home/reid/local/share/hugs/lib/Prelude.hs":
>   Reading file "GreenCard.lhs":
>   ERROR "GreenCard.lhs" - Unable to open file "GreenCard.lhs"
>   Prelude> :set
>   TOGGLES: groups begin with +/- to turn options on/off resp.
>   s    Print no. reductions/cells after eval
>   t    Print type after evaluation
>   f    Terminate evaluation on first error
>   g    Print no. cells recovered after gc
>   l    Literate modules as default
>   e    Warn about errors in literate modules
>   .    Print dots to show progress
>   q    Print nothing to show progress
>   Q    Qualify names when printing
>   w    Always show which modules are loaded
>   k    Show kind errors in full
>   u    Use "show" to display results
>   I    Display results of IO programs
>   i    Chase imports while loading modules
>   R    Enable root optimisation
>   T    print most general type
>
>   OTHER OPTIONS: (leading + or - makes no difference)
>   hnum Set heap size (cannot be changed within Hugs)
>   pstr Set prompt string to str
>   rstr Set repeat last expression string to str
>   Pstr Set search path for modules to str
>   Estr Use editor setting given by str
>   cnum Set constraint cutoff limit
>   Fstr Set preprocessor filter to str
>
>   Current settings: +fewuiRT -stgl.qQkI -h250000 -p"%s> " -r$$ -c40
>   Search path     : 
> -P/home/reid/local/gc-2.01/src:/home/reid/local/htmllib:{Hugs}/lib:{Hugs}
> /lib/hugs:{Hugs}/lib/exts
>   Editor setting  : -E"emacsclient +%d %s"
>   Preprocessor    : -F
>   Compatibility   : Haskell 98 (+98)
>
> Runhugs has no problems if I move to the directory containing the GC
> source code first - but this is obviously not a useful workaround.
>
>   cd /home/reid/local/gc-2.01/src
>   /home/reid/local/bin/runhugs GreenCard.lhs
>
> I'm assuming that this stems from that changes in the search path code
> but haven't tried to track it down.
>
> I haven't tried this on the current release of Hugs - only the current
> CVS snapshot.
>
> Is this the desired behaviour?

Hi Alastair,

Yes, I'd argue that it is.  The hierarchical module name 
extension accentuates the distinction between file names and 
module names.  For example, if I write

   hugs -P/A/B/ C.D.E

which of the files /A/B/C/D/E, /A/B/C/D/E.hs, /A/B/C/D.E, 
/A/B/C/D.E.hs, /A/B/C.D.E, /A/B/C.D.E.hs, /A/B/C.D/E, 
/A/B/C.D/E.hs, C/D/E, C/D/E.hs, C/D.E, C/D.E.hs, C.D/E, 
C.D/E.hs, etc, would I expect gets loaded?

Finding a simple principle for the general case has turned out 
to be quite hard.  So in order to reduce this complexity 
somewhat I decided to follow GHCi and only use the -P path for 
mapping module names to files.  While it's still possible to 
specify file names both on the command line and in import 
clauses, these names now have to be valid as they stand (or 
possibly after appending one of the Haskell file name 
extensions).

The view taken here is that Hugs basically supports just a 
module-to-file mapping mechanism based on a search path, plus a 
simple file name loading mechanism as an escape path for those 
cases where the search path hasn't been properly set up.

Formulated as a Haskell program, the name resolution mechanism 
would look like this (the result represents the order in which 
files are examined, and where "along" stands for the location of 
the importing module):

   find along nm hugspath
     | isModuleId nm = [ d++f++e | f <- files, d <- dirs, e <- exts ]
     | otherwise     = [ nm ++ e | e <- "" : exts ]
     where
       dirs          = along : "" : hugspath
       files         = [mod2dir nm, nm]
       exts          = [".hs",".lhs"]

       isModuleId s  = all isConid (splitAt '.' s)
       mod2dir s     = map (\c -> if c=='.' then slash else c) s

> Is this a known bug?  (I see no mention on the web pages)

It's a known feature.  But I agree that there should be some 
discussion on the hierarchical module extension in an appendix 
to the Hugs manual.

> Is there a workaround?

Simply write

   /home/reid/local/bin/runhugs -P/home/reid/local/gc-2.01/src: GreenCard

All the best,
Johan