September 2001 - 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

incomplete overloading resolution
by Ralf Laemmel 30 Sep '01

30 Sep '01

Dear Hugs-Bugsers, what a funny bug ... import Monad class Monad m => C1 m x class (Monad m, C1 m x) => C2 m x where c2 :: x -> m x instance Monad m => C1 m Bool instance C2 Maybe Bool where c2 = return test :: Maybe Bool test = c2 True 1. If you evaluate "test", then you get as expected "Just True". 2. Now remove the "Monad M" constraint in the class C2. This is of course legal and semantics-preserving since the monad constraints is implied by C1 anyway. 3. Now evaluate "test" again. Oops, it diverges. I did this Hugs Version February 2001 under Solaris and Linux. Command line option -98 is needed of course. Funny enough, if CTRL-C the evaluation of "test" and you try it the second time (without reloading anything etc.), then you see "Program error: {_Gc Black Hole}". Of course, there is no such black hole. I extracted the above fragment from a huge problem. The scheme is the following. It seems have to do with multi-parameter classes. It definitely has to do with multi-layered class hierarchies where one class has a class-wide superclass, as C2 has C1 in the example. It seems that the superclass is properly propagated during type-inference/checking but it is not properly propagated, as for as code determination in overloading resolution. Please, let me know if I can be of further assistance. I am actually amazed how general this scheme is (3 classes, 2 parameters). How does it come that it was not detected much earlier. Anyway, good luck, Ralf P.S.: I have more problems in a larger application. Certain overloaded expressions diverge. I can recover from that usually by using explicit function types for top-level functions, where again -- as in C1 above -- I repeat some constraints which are derivable. I was not able to extract a simple program for that problem. But I would be glad to help you by checking if the problem is gone after you did the bug fix. -- Dr.-Ing. Ralf Laemmel CWI & VU, Amsterdam, The Netherlands http://www.cwi.nl/~ralf/ http://www.cs.vu.nl/~ralf/

1 0

Working with MAC OSX
by Robin Harper 28 Sep '01

28 Sep '01

Hi, Just to let you know I have just finished compiling the feb distribution under the unix shell in MAC OSX. Brand new to Haskell so can only do a few tests, but it seems to work fine. The only problem I had was that configure seems to set the HAVE_LABELS_AS_VALUES wrong, changing it back to 0 allowed it to compile. Robin

1 0

bugs
by Guilherme Fernandes 24 Sep '01

24 Sep '01

the library not funcional of hugs98 i don´t import SOEGraphics ________________________________________________ Don't E-Mail, ZipMail! http://www.zipmail.com/

1 0

RE: Prelude and (:) and []((:), []) bugs?
by Simon Peyton-Jones 21 Sep '01

21 Sep '01

It's hard to distinguish a constructor from a class in an export list. S | -----Original Message----- | From: Alastair David Reid [mailto:reid@cs.utah.edu] | Sent: 20 September 2001 19:38 | To: Simon Marlow | Cc: Ian Lynagh; haskell(a)haskell.org; hugs-bugs(a)haskell.org | Subject: Re: Prelude and (:) and []((:), []) bugs? | | | | > Ah, I forgot that you can't export a constructor on its own. | | You can't? | | I probably knew this once but looking at it now, it seems | kinda surprising. Haskell's module system is supposed to be | just namespace control --nothing more-- so why is it | preventing me from doing something which is perfectly safe | and well-defined? | | I'll readily agree that there's no strong motivation for | exporting a constructor on its own (I think the only reason | Hugs allows it is just so we can export (:) from the Prelude) | but what is the motivation for disallowing it? | | -- | Alastair Reid reid(a)cs.utah.edu | http://www.cs.utah.edu/~reid/ | | | _______________________________________________ | Hugs-Bugs mailing list | Hugs-Bugs(a)haskell.org | http://www.haskell.org/mailman/listinfo/hugs-bugs |

1 0

RE: Prelude and (:) and []((:), []) bugs?
by Simon Marlow 20 Sep '01

20 Sep '01

Ian Lynagh writes: > On Thu, Sep 20, 2001 at 01:32:54PM +0100, Simon Marlow wrote: > > (:) is allowed in an export list; it is just a normal operator. > > An export is > > export -> qvar > | qtycon [(..) | ( qcname1 , ... , qcnamen )] (n>=0) > | qtycls [(..) | ( qvar1 , ... , qvarn )] (n>=0) > | module modid > > and we need to match (:). We can clearly reduce this to [ proof that this isn't possible deleted ] Ah, I forgot that you can't export a constructor on its own. In which case, I would like to submit a bug report for Hugs: Hugs allows constructors to be named in an export list, and it shouldn't (see Section 5.2 in The Report, point 2 in the enumerated list). Cheers, Simon

2 1

RE: Type-checker bug related to implicit parameters.
by Simon Peyton-Jones 20 Sep '01

20 Sep '01

GHC 5.02 works fine for this program. We're going to release it this week. Thanks for the test -- I've added it to our test suite! Simon | -----Original Message----- | From: John Hughes [mailto:rjmh@cs.chalmers.se] | Sent: 19 September 2001 18:00 | To: hugs-bugs(a)haskell.org | Subject: Type-checker bug related to implicit parameters. | | | | Hugs -98 (Feb 2001) rejects the following program (which | should be well-typed) | | > foo :: ((?x :: Int) => b) -> Int -> b | > foo s z = s with ?x = z | | with the message | | ERROR Bug.hs:2 - Inferred type is not general enough | *** Expression : foo | *** Expected type : ((?x :: Int) => a) -> Int -> a | *** Inferred type : ((?x :: Int) => a) -> Int -> Int | | It seems to unify the type of the implicit parameter with the | type of the result. | | GHC accepts this program (but generates wrong code). | | John Hughes | | _______________________________________________ | Hugs-Bugs mailing list | Hugs-Bugs(a)haskell.org | http://www.haskell.org/mailman/listinfo/hugs-bugs |

1 0

Re: Type-checker bug related to implicit parameters.
by John Hughes 19 Sep '01

19 Sep '01

I believe if you're (more) explicit about the scope of the scoped type variable, you'll be fine. i.e., foo :: (forall b.(?x :: Int) => b)) -> Int -> b foo s z = s with ?x = z Not at all, Sigbjörn! You didn't just make the scope of the type variable more explicit, you changed it. In my type signature foo :: ((?x :: Int) => b)) -> Int -> b both occurrences of b are the same, and the argument need not be polymorphic. Your type would rule out the call I want to make foo ?x 42 (which should evaluate to 42), and just about any other call also. i.e., 'foo' is running into the same issue as the bug reported in http://haskell.cs.yale.edu/pipermail/hugs-bugs/2001-January/000084.html, I don't think it is the same bug, although it may be related. The example you quote involves "rank 2 overloading", whereas mine involves "rank 2 implicit parameters". Moreover, it seems to be the *type of the implicit parameter* which is wrongly unified with the result type of foo, which suggests that this is something specific to implicit parameters. Another observation is that "rank 2 overloading", without polymorphism, is quite useless: there's no advantage in a signature such as f :: (Ord a => a -> a) -> a since a can be only one type in the body of f, and so the "overloaded" parameter might just as well be instantiated before it is passed. That's why you assumed there should be a "forall b" in my example: in this one, "forall a" must be inserted if the context is to be useful. With implicit parameters the situation is different, because the value is supplied *explicitly* in the body of f, so one can very well supply two different ones. E.g. f :: (?x :: Int => Int) -> (Int,Int) f z = (z with ?x=1, z with ?x=2) > f (?x*2) (2,4) > > Hugs -98 (Feb 2001) rejects the following program (which should be well-typed) > > > foo :: ((?x :: Int) => b) -> Int -> b > > foo s z = s with ?x = z > > with the message > > ERROR Bug.hs:2 - Inferred type is not general enough > *** Expression : foo > *** Expected type : ((?x :: Int) => a) -> Int -> a > *** Inferred type : ((?x :: Int) => a) -> Int -> Int > > It seems to unify the type of the implicit parameter with the type of > the result. > > GHC accepts this program (but generates wrong code). > > John Hughes > > _______________________________________________ > Hugs-Bugs mailing list > Hugs-Bugs(a)haskell.org > http://www.haskell.org/mailman/listinfo/hugs-bugs

1 0

Type-checker bug related to implicit parameters.
by John Hughes 19 Sep '01

19 Sep '01

Hugs -98 (Feb 2001) rejects the following program (which should be well-typed) > foo :: ((?x :: Int) => b) -> Int -> b > foo s z = s with ?x = z with the message ERROR Bug.hs:2 - Inferred type is not general enough *** Expression : foo *** Expected type : ((?x :: Int) => a) -> Int -> a *** Inferred type : ((?x :: Int) => a) -> Int -> Int It seems to unify the type of the implicit parameter with the type of the result. GHC accepts this program (but generates wrong code). John Hughes

2 1

Re: Tab "\t" character behaviour in (Win)hugs/ghc
by Sigbjorn Finne 18 Sep '01

18 Sep '01

Rijk-Jan van Haaftenrjchaaft(a)cs.uu.nl writes: > > Recently, Craig Delehanty discovered that there is > a difference in behaviour of putStr "a\tb" between > Hugs and WinHugs (see comp.lang.functional). > > Hugs interprets it as a alignment character: > >putStr "a\tb" > "a b" > > > (7 spaces) > but in WinHugs, it is always the same as 8 spaces: > >putStr "a\tb" > "a b" > > > (8 spaces) > > What does the language definition say about this? Nothing at all, I believe, but the convention is for tab characters to be interpreted by an output device as moving the cursor to the next tab stop/alignment column. In the absence of any custom set of tab stops, the convention is to space them evenly every 8 characters. So, WinHugs is being unnecessarily non-standard to interpret "\t" as being a shorthand for 8 spaces. I've changed this to have it fall into line with the conventional interpretation & checked in the tweak. Thanks for reporting this. --sigbjorn

4 4