Problem in load path in CVS repository version of Hugs
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? Is this a known bug? (I see no mention on the web pages) Is there a workaround? -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
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
Simply write
/home/reid/local/bin/runhugs -P/home/reid/local/gc-2.01/src: GreenCard
Thanks, that does the trick. Now let's see if I understand why it works. Using GreenCard (a module name) instead of GreenCard.lhs (a filename) meant that Hugs added the directory containing GreenCard.lhs (i.e., /home/reid/local/gc-2.01/src) to the list of directories to search in the future so that when it later looked for the module Parse, it (correctly) looked in /home/reid/local/gc-2.01/src Is that it? [Sorry if I seem a bit thick here - you kept me very well informed of the changes you were making to the search path but I was pretty distracted by my family, returning to Glasgow and starting a (computer consulting) company and didn't pay as much attention as I should have.] -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
Now let's see if I understand why it works.
Using GreenCard (a module name) instead of GreenCard.lhs (a filename) meant that Hugs added the directory containing GreenCard.lhs (i.e., /home/reid/local/gc-2.01/src) to the list of directories to search in the future so that when it later looked for the module Parse, it (correctly) looked in /home/reid/local/gc-2.01/src
Is that it?
Well, the directory /home/reid/local/gc-2.01/src is in the search path simply because of the -P option; it's just that the search path only plays a role when you demand the loading of a module name. On top of that, Hugs will always extend the search path with the current directory and the directory where the current module was found (which might not be in the serach path proper if the module was specified using an absolute filename). This is important when module A imports some private module B from the same directory, and module A was loaded using its absolute filename. Phew, I guess this is still quite complicated... :-)
[Sorry if I seem a bit thick here - you kept me very well informed of the changes you were making to the search path but I was pretty distracted by my family, returning to Glasgow and starting a (computer consulting) company and didn't pay as much attention as I should have.]
Not a problem at all! BTW, is your preferred email address still reid@cs.utah.edu? -- Johan
BTW, is your preferred email address still reid@cs.utah.edu?
For now, yes. I'll probably get a new email address once things settle down a bit. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
participants (2)
-
Alastair David Reid -
Johan Nordlander