April 2002 - Hugs-Bugs

OSX
by Michel Schellekens 25 Oct '02

25 Oct '02

After downloading the OSX version, and typing "hugs" to start up the language, I obtain the following error: [schellekens:~] mpcs% hugs dyld: hugs can't open library: /usr/lib/libncurses.5.dylib (No such file or directory, errno = 2) Any suggestions? Michel.

2 1

RE: module namespaces with "Prelude"
by Simon Marlow 10 May '02

10 May '02

> All in all, dropping all implicit directories from the search > path gets my vote. "me too". I wasn't aware that Hugs did this, and GHCi certainly doesn't. It's reasonable to leave "." in the default search path, but adding an implicit root for an imported module will certainly lead to trouble - after all, we use hierarchical module names because the modules at the leaves of the tree are expected to overlap. Cheers, Simon

3 2

set editor problem
by Ernest Paquet 07 May '02

07 May '02

Dear Sirs/Mesdames: I teach Computer Science here at Walsh University, and am planning to teach a new course using Haskell. My computer is a Dell Optiplex GXi with Windows NT version 4. I have Hugs 98, downloaded over a year ago. My download file is named "HUGS98-FEB2001.MSI" -- (I probably inserted the FEB2001 myself.) It installs without problems but at no time asks which editor to associate with HUGS. When I run HUGS and give the command :set, I read the following setting -EC:\WINNT\notepad.exe. Now I have Notetab light installed in C:\Program Files\Notetab Light\notetab.exe. So in Hugs I gave the command: :set -E"C:\\Program Files\\Notetab Light\\notetab.exe". When I then try :edit c:\temp\foo.hs, nothing happens that I can see. I restored the setting to its original form with notepad. Now :edit could no longer bring up notepad. I re-installed HUGS. Still the editor (with setting for notepad as installed) showed no effect when called. How can I set the editor to my preferred software notetab.exe? If I must manually edit the Registry -- something I have never dared to do until now, I would need to know where to navigate to! Many thanks ahead for your kind help! Ernest Paquet Computer Science Dept. Walsh University Canton, OHIO 44720.

2 1

Windows XP
by Andrew Robinson 02 May '02

02 May '02

I have just installed Windows XP on my system, however when I try to run WinHugs I get a fatal error message. saying prelude could not be loaded. Is it possible to fix this or is it not compatible with XP? Yours sincerely Andrew Robinson

3 2

newbug?
by Couteau 30 Apr '02

30 Apr '02

Hello, I just recently installed the December 2001 version of Hugs98, and on trying to activate and see the demos get this(Windows 98 version) error message: ERROR "C:\Program Files\Hugs98\demos\Stack.hs":5 - Haskell 98 does not support r estricted type synonyms It appears that all the demo files except for Eliza do not work. It's been so long since I did any programming I can't yet tell if it's just me or if it is a ligitimate bug. If I use the .lhs literal configuration the error message seems to go away, but I still don't seem to be able to see any demos. Sorry, I'm so clueless, Chris Couteau couteau(a)smithsys.net

2 1

RE: module namespaces with "Prelude"
by Simon Marlow 26 Apr '02

26 Apr '02

> On Thursday, April 25, 2002, at 03:00 , Alastair Reid wrote: > > >> Now, since there's nothing that prevents the directory hierarchies > >> starting at these roots from overlapping, we have a potential for > >> ambiguity when we want to map module names to filenames. > > > > This suggests that we might want to modify the search algorithm to > > find all matches and report and error if two or more candidate files > > are found. If this is a big performance hit, we could make > it a :set > > option. > > But wouldn't that just prohibit the use of module names that > also appear in the standard libraries? At least we need to stop > searching the directory of the importing module to make > something useful of this idea. I agree with Alastair - I think it should be an error if there are two modules with the same name on the search path. If it weren't for (a) the performance hit and (b) the difficulty in portably determining whether two pathnames refer to the same file, I'd have made GHCi do this already. Yes, it would prohibit the use of module names that also appear in the standard libraries. But after all we're moving to hierarchical libraries so there's no need to do that any more! Cheers, Simon

2 1

Re: module namespaces with "Prelude"
by Alastair Reid 26 Apr '02

26 Apr '02

[copied to original recipients along with the original bug report] On ghc-bugs, Hal Daume reported problems with Hugs (and ghci) where importing IO.hs causes a module called Bar.IO (i.e., Bar/IO.hs) to be loaded - leading to the load to fail. I've systematically tried every way of invoking Hugs (December 2001) that makes sense (and a few that don't) and didn't find any that worked. Here's what I tried: cd /tmp mkdir Bar cat > Bar/Foo.hs module Bar.Foo where import IO cat > Bar/IO.hs module Bar.IO where hugs Bar.Foo # unexpected failure: confuses Bar.IO for IO hugs -P.: Bar.Foo # unexpected failure: confuses Bar.IO for IO hugs Bar.Foo.hs # expected failure: Bar.Foo.hs doesn't exist hugs Bar/Foo.hs # unexpected failure: confuses Bar.IO for IO cd Bar hugs Bar.Foo # expected failure: Can't find Bar.Foo hugs Foo # unexpected failure: confuses Bar.IO for IO hugs -P..: Bar.Foo # unexpected failure: confuses Bar.IO for IO Did I do the wrong thing or do we need to tweak the loader? (I didn't test with import chasing turned off - could that be it?) -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/ It happens in Hugs, too, but somewhat differently. Here's a test case. Go to /foo and do mkdir Bar. In Bar, create IO.hs and make its contents: module Bar.IO where then also in Bar create Foo.hs module Bar.Foo where import IO Then when in directory Bar load ghci (using 5.02.1) and load Bar.Foo and you'll get: IO.hs: file name does not match module name `IO' Quit ghci, load hugs and load Bar.Foo and you'll get: ERROR "Foo.hs" - Module "IO" not previously loaded (worse things can happen in hugs -- if say Bar.IO imported Bar.Foo and plain Bar.Foo imported plain old IO hugs will complain about cyclic modules) if you are in /foo instead of /foo/Bar when you load ghci and set paths correctly it will work. I don't know that this is exactly a bug in the software as much as it's just somewhat underspecified what to do in these situations (I could be wrong though). IMO if you say in an import "import XXX" and it looks in XXX.(l)hs and the module names is "YYY.XXX" it should keep looking instead of just dying. I don't really know what repurcussions this will have, though. -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Mon, 22 Apr 2002, Simon Peyton-Jones wrote: > Hal, > > If your question is GHC-specific, send it to ghc-users not the haskell > list. > > And it would save time if you could be more specific. Say what > compiler > you are using, enclose a test case, etc. Otherwise we're all guessing. > > Simon > > | -----Original Message----- > | From: Hal Daume III [mailto:hdaume@ISI.EDU] > | Sent: 23 April 2002 03:21 > | To: Alastair Reid > | Cc: Haskell Mailing List > | Subject: Re: module namespaces with "Prelude" > | > | > | Ah, so the problem was that even though I had the superdir of > | NLP in my path, I was actually loading the modules in ghci > | from the NLP directory. Still, I find this behavior odd, > | since even if I were in the NLP directory I could not import > | "NLP.Foo" simply as "Foo", I don't see why I should be > | allowed to (try to) import "NLP.Prelude" simply as "Prelude", > | thus messing stuff up... > | > | -- > | Hal Daume III > | > | "Computer science is no more about computers | hdaume(a)isi.edu > | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume > | > | On 23 Apr 2002, Alastair Reid wrote: > | > | > > | > >>>>> "#Hal" == Hal Daume <hdaume(a)ISI.EDU> writes: > | > > | > > I'm developing my package "NLP" for supporting common NLP > | functions > | > > and have a set of functions/datatypes that are common to > | almost all > | > > of my modules and I wanted to separate them off into an > | > > "NLP.Prelude" file, but this seems not to work. One of > | my modules > | > > imports Prelude (the Haskell one) directly so I can hide a few > | > > definitions, but then it looks at NLP/Prelude.lhs and > | complains that > | > > the name of that module "NLP.Prelude" doesn't match "Prelude". > | > > SHould I simply name my module "NLP.NLPPrelude" or > | something (which > | > > is ugly, imo) or what? > | > > | > The only change that hierarchial module namespaces make is that the > | > dots become a legal part of the name and that compilers have a > | > sensible way of mapping them onto filenames such as > | replacing dots by > | > slashes. So, under the new scheme, these names are different and > | > unrelated > | > > | > Prelude NLP.Prelude User.Hal.Daume.NLP.Prelude > | > > | > in the same way that these names were different and > | unrelated in the > | > old scheme. > | > > | > Prelude NLP_Prelude User_Hal_Daume_NLP_Prelude > | > > | > If you are seeing something other than that, the problem is > | with your > | > compiler or the way you are using command line arguments to your > | > compiler (e.g., Hugs' import chasing mechanism has some interesting > | > interactions with hierarchial namespaces) and you should > | say which one > | > you're using and how you're using it. > | > > | > -- > | > Alastair Reid > | > > | > | _______________________________________________ > | Haskell mailing list > | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell > | >

3 7

RE: module namespaces with "Prelude"
by Simon Marlow 26 Apr '02

26 Apr '02

> On Thursday, April 25, 2002, at 11:30 , Simon Marlow wrote: > > >> All in all, dropping all implicit directories from the search > >> path gets my vote. > > > > "me too". > > > > I wasn't aware that Hugs did this, and GHCi certainly doesn't. It's > > reasonable to leave "." in the default search path, but adding an > > implicit root for an imported module will certainly lead to > trouble - > > after all, we use hierarchical module names because the > modules at the > > leaves of the tree are expected to overlap. > > But it is this "." in the default path that is the reason GHCi > gives unexpected results, isn't it? [See Hal Daume's original > bug report] Well, that depends what you mean by unexpected - IMHO the behaviour is entirely reasonable and is well documented. Let's recap: the directory structure is something like this (using $$ to represent an arbitrary path): $$/Bar/Foo.hs contains module Bar.Foo $$/Bar/IO.hs contains module Bar.IO now if the current directory is $$, then Bar.Foo and Bar.IO map to the correct filenames/modules. However, if the current directory is $$/Bar, as it was in Hal's example, then module IO maps to both ./IO.hs and the IO module in the standard library. Clearly there's an overlap, and the solutaion is not to sit in $$/Bar, or to explicitly remove "." from the default search path (which you can do in ghc by giving a -i option without any arguments). If one root is a subdirectory of another root, then you have an overlap. Clearly, the "implicit roots" mechanism will always lead to overlap, so it can't be the right thing to do. Unfortunately it isn't easy to detect whether the user-specified roots are overlapped and issue a warning, but I think the rule is fairly straightforward to understand. It would be possible to detect whether a module maps to more than one filename though - perhaps we should do that. Cheers, Simon

2 1

:s -u <CR> (<) 2
by Matt Fairtlough 23 Apr '02

23 Apr '02

Subject line says it all, just about: in hugs/winhugs98 (haskell98 mode), challenge the interpreter with the following 8 characters (not including blanks): Prelude> :s -u Prelude> (<) 2 and the result is not pretty...nor very useful. It has to be interrupted manually. :t (<) 2 is fine, as is \x -> (<) 2 x; the problem does not occur without the -u flag because there is no show function for (<) 2. Of course, you can define one eg. using a datatype, but that doesn't cause a problem either. Also, (< 2) is perfectly fine, but (2 <) has the same problem. the argument 2 is not special; any expression (<) e (with e an instance of Ord) seems to do it. Same problem if you wrap (<) e up in a datatype. Am I right or? And is there a prize for the shortest bug ? Matt Matt Fairtlough Department of Computer Science, University of Sheffield 0114 222 1826

2 1

RE: Derived Show and Read
by Simon Peyton-Jones 23 Apr '02

23 Apr '02

| However, the example you give in bullet 2 doesn't | make sense - I suspect you want to say | | infixr :$ | data T = Int :$ Int | T Int | | * "show (1 :$ 2 :$ T 3)" produces the string "1 :$ (2 :$ (T 3))" ... Indeed so. | Was there a good technical reason for dropping that portion | of the Report (1.3 onwards), btw? Preferable to bulleted text, IMHO. I have no idea; I wasn't editing for 1.3. But I'm nervous about adding it again...it's late in the day. Simon

1 0